Editor di testo con codice a dominio [chiuso]

Ho sviluppato un editor di testo che era "a conoscenza del dominio" ma probabilmente è meglio descritto come "dominio specifico" in quanto è stato scritto specificamente per XSLT.

E 'stato costruito in particolare per questioni di spazio bianco. In XSLT, lo spazio bianco nel codice sorgente richiede particolare attenzione perché molto probabilmente finirà nella struttura dei risultati.

La maggior parte degli editori si basa sull'inserimento di elementi XML aggiuntivi per separare gli spazi bianchi di formattazione del codice da spazi vuoti destinati all'output: ciò si aggiunge alla prolissità del codice e riduce la leggibilità. Questo nuovo editor utilizza la formattazione virtuale che evita questo problema semplicemente utilizzando i margini dinamici per indentare automaticamente XSLT.

Il problema è che gli utenti non possono trarre il massimo vantaggio dalla formattazione virtuale a meno che anche altri editor non offrano questa opzione. In caso contrario, non appena un file XSLT di formato virtuale viene aperto da un normale editor XSLT, viene aggiunto un intero carico di caratteri indesiderati di spazi bianchi, per mantenere la formattazione.

Non sono riuscito a convincere altri venditori a prendere in considerazione questo approccio alla formattazione. Quello che ho imparato da questo è che gli editor di testo non possono davvero cambiare perché ogni cambiamento sarebbe dirompente. La maggior parte degli sviluppatori desidera utilizzare editor di testo generici in grado di funzionare adeguatamente con qualsiasi grammatica / sintassi piuttosto che utilizzare quelli dedicati a un'attività specifica.

I soliti editor di testo UNIX (emacs, vi e i suoi vari cloni) sono altamente estensibili e possono probabilmente essere configurati per eseguire la maggior parte o tutte le funzionalità elencate.

ad esempio, vim fornisce una gamma di funzionalità pronte per l'uso che consentirebbero ciò che descrivete o raggiungere lo stesso obiettivo su un percorso diverso. Ad esempio, i movimenti it e at ('inner tag' / 'a tag') possono essere utilizzati per applicare tutti i tipi di operazioni di modifica generali a un tag XML o ai suoi contenuti. Scrivere una macro che chiude automaticamente un tag è banale. Il salto può essere ottenuto utilizzando movimenti basati su tag in combinazione con i comandi di movimento generali. vim ha anche il piegamento sintattico e configurabile, e immagino che ottenerlo per piegare correttamente XML non dovrebbe essere troppo difficile. Se ciò non è sufficiente, puoi reindirizzare qualsiasi parte del documento corrente tramite un comando esterno utilizzando la famiglia di comandi ! . Infine, vim ha una certa integrazione con gli strumenti di compilazione e può essere configurato per analizzare il loro output per posizionare il cursore su qualsiasi errore.

Sono tutt'altro che un esperto di emacs, ma sono abbastanza positivo che emacs possa fare le stesse cose, o i loro equivalenti nel paradigma emacs.

Il controllo di sola lettura è una caratteristica che odio - è il mio testo, è lì, non c'è motivo di negarmi di modificarlo se lo scelgo. Segnalare che il documento è sbagliato attraverso l'evidenziazione aggressiva della sintassi e fornire macro comode per manipolare il testo in un modo specifico del dominio, è una scelta molto migliore.

Ma il motivo più importante per usare un editor di testi generico su uno strumento specifico del dominio è che devi solo imparare uno strumento - questo significa che puoi (e probabilmente lo farai) imparare questo strumento dentro e fuori, e questo a sua volta significa che uno strumento con una curva di apprendimento pazzesca è perfettamente OK, a patto che ripaga in termini di produttività. L'editor di testo di un tale esperto non ha bisogno di un'interfaccia grafica, non ha bisogno di spendere risorse di sistema e screen per la scoperta, e può presumere che io sappia cosa sto facendo invece di cercare di indovinare dove sono andando e suggerendo soluzioni.

Un editor a mio modesto parere un bell'esempio di modifica sensibile al contesto è GNU TeXmacs . Provalo, è open-source e mostra esattamente i pro e i contro del montaggio in base al contesto.

Sto lavorando su un editor con tali caratteristiche. È un editor di testo semplice progettato per modificare dati che assomigliano a tabelle, in cui le colonne sono delimitate da pipe (in realtà, space-pipe-space). Premendo il tasto si passa a un'altra "cella" come un foglio di calcolo e ci sono comandi che gestiscono "celle" e "righe" anziché "parole" e "righe di testo". Ha caratteristiche per allineare colonne e per rilevare righe contigue con un numero uguale di colonne (ogni riga potenzialmente può avere un diverso numero di colonne). Conosce anche la sintassi della variabile, le intestazioni delle tabelle e così via.

La giuria è ancora fuori da quanto successo abbia questo tipo di editor, ma penso che abbia un potenziale. Mentre gli utenti esperti possono ancora configurare il loro editor di forza industriale (ad esempio: vim, emacs) per fare le stesse cose, c'è una parte molto ampia della popolazione che non utilizza tali strumenti. Quindi, mentre, sì, puoi farlo con emacs, la maggior parte degli utenti (che ho scelto come target) vogliono qualcosa di meno complesso.