Quali vantaggi specifici in termini di produttività forniscono Vim / Emacs rispetto agli editor di testo con GUI?

Questo non è inteso come un troll o un flamebait o qualcosa del genere. Sto usando Vim come mio editor di console preferito da un paio di mesi (per modificare i file di configurazione mentre sono nel mio terminale), ma non penso di poterlo sopportare per il mio normale lavoro quotidiano di scrittura di applicazioni web , cosa che faccio con un editor di testo GUI (che non è importante).

Mi sento come se il mio editor di testo con interfaccia grafica potesse fare tutto ciò di cui ho bisogno per il mio lavoro. Ha una funzione di ricerca / sostituzione decente con cronologie di completamento automatico per entrambi. Ha l'evidenziazione della sintassi, la numerazione delle righe, un'interfaccia a schede, facile copia e incolla, ecc. L'unica cosa che manca al mio attuale editor è la corrispondenza delle espressioni regolari, ma ci sono molti editor di testo GUI che eseguiranno la ricerca / sostituzione delle espressioni regolari.

Dato quello che ho appena detto, quali vantaggi in termini di produttività ha Vim (o anche Emacs) su un editor di testo con interfaccia grafica a parte il fatto che è installato su ogni computer. Vorrei attività specifiche che siano migliori / più veloci su Vim / Emacs o che semplicemente non sono possibili con gli editor di testo GUI esistenti.

Per Vim:

• Vim ha una migliore integrazione con altri strumenti (comandi shell, script, compilatori, sistemi di controllo della versione, ctags, ecc.) Rispetto alla maggior parte degli editor. Anche qualcosa di semplice come :.!convogliare l'output di un comando in un buffer, è qualcosa che non troverai nella maggior parte degli editor di GUI.

• Un'interfaccia a schede non è così bella come l'interfaccia "a finestre" fornita da Vim / Emacs. Puoi vedere due o più file contemporaneamente uno accanto all'altro. Più puoi vedere sullo schermo, più liberi la tua mente di pensare al tuo problema piuttosto che fare la contabilità mentale dei nomi delle variabili e delle firme delle funzioni.

• Non sottovalutare il potere delle espressioni regolari di Vim. Esistono molte estensioni specifiche di Vim per abbinare una colonna specifica, un segno, la posizione del cursore, determinate classi di caratteri (parole chiave, identificatori) ecc.

• Integrato diffe grep(indipendente dalla piattaforma, quindi non è necessario scaricare e apprendere un nuovo strumento ogni volta che si cambia computer).

• La modalità blocco visivo (per modificare le colonne) è qualcosa che manca a molti editor, ma di cui non posso fare a meno. Ho scioccato e intimorito le persone al lavoro usando proprio questo, apportando alcune modifiche in poche pressioni di tasti che qualcuno avrebbe altrimenti impiegato dieci minuti a fare manualmente.

• Più registri copia / incolla. Quando ne hai solo uno, finisci per attraversare strane contorsioni per evitare di rovinare gli appunti. Non dovresti.

• Il sistema di annullamento / ripetizione di Vim è imbattibile. Digita qualcosa, annulla, digita qualcos'altro, e puoi ancora recuperare la prima cosa che hai digitato perché Vim usa un albero di annullamento piuttosto che uno stack. In quasi tutti gli altri programmi, la cronologia della prima cosa che hai digitato si perde in questa circostanza.

• Spostarsi, copiare, incollare ed eliminare il testo è incredibilmente veloce in Vim. I comandi sono semplici, singole pressioni di tasti e componibili. Somma tutte le volte che esegui un'attenta e laboriosa evidenziazione del mouse e Ctrl-X, quindi sostituiscili tutti con a da((elimina un insieme di parentesi corrispondenti e tutto ciò che contiene). Risparmia più tempo di quanto pensi

• Le piccole cose, come *cercare la parola sotto il cursore, o .ripetere un comando, o %rimbalzare tra una parentesi di apertura e chiusura. Troppi di questi per elencarli.

• Linguaggio di scripting integrato e potente mappatura dei tasti e capacità di macro in modo che l'editor possa essere esteso in qualsiasi modo tu abbia bisogno. Tonnellate di script già scritti e scaricabili.

Se guardi abbastanza da vicino, scoprirai che anche le funzionalità che hanno anche altri editor, Vim spesso fa meglio. Tutti gli editor hanno l'evidenziazione della sintassi, ma Vim ha un file di sintassi per quasi tutti i formati di file sotto il sole, spesso con molte opzioni di configurazione, ed è semplicissimo scrivere il proprio. Molti editor gestiscono diverse codifiche di file OK, ma Vim offre modi molto specifici e infallibili per impostare le codifiche dei file e convertirle tra di loro. La prima cosa che mi ha colpito di Vim è come gestisce perfettamente le opzioni di rientro di tabulazione / spazio e le interruzioni di riga Unix / DOS rispetto ad altri editor con cui ho avuto problemi in quel momento.

Molti di questi punti si applicano ugualmente bene a Emacs (in modi diversi ma di solito ugualmente potenti).

(vim è il mio veleno; sono sicuro che emacs offre guadagni simili)

Il vantaggio più grande: non è necessario toccare il mouse.

Per me, la cosa più comoda è saltare in avanti (o subito prima) una lettera specifica o una combinazione di lettere, oppure tornare indietro, premendo un paio di tasti. Saltare avanti per la stessa condizione due o dieci volte è semplicemente questione di prefissarlo con un numero.

Se devi ripetere una modifica, salti in avanti in quel punto (2-3 sequenze di tasti), quindi premi "." per ripetere l'ultima modifica. Saltare in avanti (o indietro) è più facile - premendo un tasto - se è la stessa condizione di ricerca.

Fondamentalmente, con un breve lasso di tempo, puoi imparare dieci o venti scorciatoie da tastiera che significa che non devi continuare a spostare la mano per afferrare il mouse. Questo ti dà tre o quattro volte più movimenti / comandi di modifica che faresti se dovessi continuare ad afferrare il mouse.

Dopo alcuni giorni, ti ritroverai a diventare scontroso ogni volta che devi raggiungere il mouse (o premere <Down>15 volte), quando sei in un editor della GUI.

Mi sono sempre chiesto perché poche persone fossero gaga su Vim. Guarda il video di Vim power user in azione:

https://www.youtube.com/watch?v=FcpQ7koECgk

Se il tuo attuale editore può fare quello che sta facendo, non è necessario cambiare! :)

Inoltre, leggi questo http://www.viemu.com/a-why-vi-vim.html

Dopo aver visto il video e letto quell'articolo, non ho avuto altra scelta che iniziare a imparare VIM. È passato quasi un anno da quando sono passato a VIM e non riesco a immaginare di usare nient'altro.

Penso che uno dei veri poteri di un editor di testo dedicato sia l'editing di macro. La ripetizione è dolorosa per molti programmatori e scrivere macro corrette può essere divertente al limite. Se non stai facendo tutto tramite la tastiera, la creazione di macro richiederà un set aggiuntivo di comandi piuttosto che utilizzare quelli che stai già utilizzando.

Sono semi-competente con le associazioni di tasti di vi, ma nel complesso preferisco Emacs. Il motivo per cui questi editor hanno aderenti così ferventi è perché il modello di editing che forniscono è più potente dei sistemi più recenti, motivo per cui fornire "combinazioni di tasti vi" o "associazioni di tasti emacs" non è sufficiente, anche se non stai utilizzando alcuna funzionalità di estensione o personalizzazioni per emacs o vi.

Parlerò del modello di Emacs solo perché lo capisco meglio. Il modello comune per l'editing di testo oggi prevede un buffer di testo, in cui il testo può essere inserito, eliminato, selezionato e tagliato / copiato / incollato negli appunti di sistema.

I buffer di Emacs, ovviamente, possono supportare queste operazioni. Insieme alla posizione del cursore di tracciamento per ogni finestra in cui sono visibili, tengono anche traccia dei "segni" creati in esse. Il testo tra il "punto" (posizione del cursore) e il "segno" è chiamato "regione" e corrisponde grosso modo alla selezione negli editor tradizionali.

La differenza è che Emacs tiene traccia delle ultime diverse posizioni in cui è stato impostato il marker nell'anello del marker, e potete ritornarvi premendo un tasto (o due, a seconda della vostra configurazione). Lo trovo estremamente utile, soprattutto perché molti comandi di Emacs che cambiano la tua posizione nel buffer impostano il segno nella tua vecchia posizione. Un esempio è quando modifico un modulo Python e ho bisogno di aggiungere un'istruzione import all'inizio del file. La sequenza di tasti per andare all'inizio del buffer (Alt- <) imposta il contrassegno. Aggiungo la dichiarazione di importazione. Premo Ctrl-u Ctrl-Spazio e sono tornato al punto di partenza. Posso continuare a farlo anche per tornare alle posizioni precedenti. (Forse avevo bisogno di selezionare del testo mentre aggiungevo quella dichiarazione di importazione.)

L'altra (e più nota) differenza di Emacs è il kill ring. La maggior parte delle sequenze di tasti per rimuovere il testo dal buffer salva il testo nel kill ring, che può quindi essere richiamato con il comando "yank" (Ctrl-y). La caratteristica essenziale è che i successivi comandi di yank recuperano il testo ucciso più vecchio. Quindi puoi eliminare diverse sezioni di testo di seguito, quindi recuperarle in ordine. Puoi anche scorrere il kill ring con Alt-y dopo uno strattone, rimuovendo il testo recuperato e inserendo la voce successiva nel ring.

Emacs aveva queste caratteristiche nel 1978. L'unico altro grande sistema ad adottarle in qualche misura è NeXTStep (e ora ereditato da Cocoa). Altri strumenti forniscono più funzionalità per compiti specifici, possono essere estesi in linguaggi molto più facili da usare rispetto a Emacs Lisp, e hanno interfacce visive più belle ... ma Emacs rimane migliore nell'editing di testo. Ecco perché, una volta che sai come usarlo, è così difficile smettere.

Questo non è esattamente un compito specifico, ma per le persone che potrebbero anche soffrire di RSI, il fatto che le tue mani non lascino mai la tastiera in vim è quasi impagabile. In realtà ho finito per diventare mancino sul mio mouse al lavoro perché mi ha permesso di muovere meno la mano per raggiungere il mouse (la mia tastiera a casa non ha un tastierino numerico, quindi posso tenerlo sulla destra).

Un altro piccolo vantaggio era che, IIRC, l'originale vi era progettato per velocizzare la modifica dei file su una connessione remota terribilmente lenta. Certo, oggi non succede così tanto, ma se hai una connessione lenta, buona fortuna con un editor di testo con interfaccia grafica e che sia reattivo.

Per me le cose importanti sono la produttività

• Posso fare praticamente tutto dalla tastiera.
• Potenti macro.
• Nella mia carriera di 20 anni con 9 sistemi operativi le associazioni di base della tastiera non sono cambiate. Posso saltare praticamente su qualsiasi sistema e conosco già l'editor.
• Quasi tutte le funzionalità che potresti desiderare in un editor di testo sono già state aggiunte.

Una cosa che mi piace davvero di vim è il comando "repeater". Fondamentalmente, premendo .in modalità di comando, ripete l'ultima azione. Questo è solo un esempio di funzionalità davvero interessanti che gli "editor di testo per programmatori" hanno che spesso le GUI non hanno.

Nella mia esperienza, i principali guadagni di produttività forniti da vim ed emacs (io stesso sono una persona vim, ma emacs è sicuramente simile) sono:

• È possibile avere quelle caratteristiche che IDE moderno disposizione (come i cicli di uno-di pressione dei tasti-run edit-accumulo e la documentazione in linea e il completamento scheda e quant'altro), ma non si deve . Il guadagno di produttività? Vedi solo quanto vuoi vedere. Nella mia esperienza, gli IDE non rendevano le persone più produttive, anche perché mostravano troppe informazioni (tutti i tipi di browser). Questo "po 'di potenza in più, quando ne hai bisogno, ma non prima" è un bel guadagno di produttività IMHO.

• Gli editor sono molto popolari tra i programmatori, il che significa che sono disponibili enormi archivi di script, libri e gruppi di utenti.

• Nella mia esperienza (posso solo parlare per vim qui) l'utente medio di vim è un ingegnere del software abbastanza bravo. Non so perché sia ​​(o forse sono solo fortunato), ma forse le persone che hanno superato la barriera di abituarsi a uno strumento 'vecchio' come emacs o vim hanno la giusta dedizione (e il contatto con altre persone del genere ). Forse è un effetto indiretto di questi editor, ma uscire con altre persone vim (o emacs) ad esempio su IRC si è rivelato piuttosto interessante, poiché le stesse persone erano anche piuttosto interessate a tutti i tipi di problemi di ingegneria del software (o informatica) . Questi editori sembrano attrarre un certo tipo di personalità. :-)

Il "guadagno di produttività" che ottengo usando un clone di emacs leggero per piccoli programmi è che si avvia come un fulmine unto. Di solito riesco a eseguire un rapido programma di test in C # prima che Visual Studio abbia terminato il caricamento di una soluzione "sandbox".

Ovviamente, potrei semplicemente lasciare Visual Studio aperto (o un altro VS aperto se ci sto lavorando in quel momento) ma poi verrebbe sostituito se lo lasciassi inattivo per un po ', ecc.

Per qualsiasi cosa di qualsiasi dimensione significativa - o se non conosco l'API che sto usando abbastanza bene - un IDE è la via da seguire, IMO.

Uso gvim per Windows, quindi tecnicamente è un editor di testo GUI, ma è vim ..

Per i miglioramenti della produttività, trovo:

1. Non devo mai usare il mouse, quindi sono più veloce.
2. ricerca, sostituzione, copia / incolla ecc. sono tutti più veloci con le combinazioni di tasti vim rispetto ai movimenti del mouse (una volta superata la curva di apprendimento)
3. Come accennato nei commenti precedenti, gli RSI sono ridotti in modo significativo. I miei polsi mi hanno ringraziato da quando sono passato a vim.
4. è leggero e veloce

Sai, per vi penso che si tratti di avere una modalità di inserimento e comando. Anche se può sembrare un ritorno a un tempo in cui non si poteva dipendere dal cursore o dai tasti speciali, ciò che significa veramente è che molti potenti comandi di movimento e di manipolazione del testo sono un numero minimo di sequenze di tasti. La codifica produttiva non riguarda l'immissione di testo in blocco (l'impostazione predefinita negli editor "moderni") ma un'esplosione di testo in blocco seguito da piccole modifiche considerevoli e periodi di navigazione ancora più lunghi.

Questo è venuto alla ribalta per me personalmente utilizzando vi su una rete di campus ad alta latenza. Potresti facilmente ottenere 10 o 15 caratteri prima della risposta. Con vi potevo prevedere comodamente dove mi avrebbero lasciato quei comandi ed essere in grado di lavorare a velocità quasi normali. Questa esperienza contorta è un vantaggio continuo in condizioni normali: meno capacità intellettuali visive dedicate a un feedback grafico costante.

Gli acceleratori di ricerca di parole comuni * e # sono ottimi per sfogliare il codice. E% per la corrispondenza delle parentesi è estremamente utile. Certo, non sembra molto in confronto a ctl-] ma metà delle sequenze di tasti si somma.

Personalmente, uso winvi che aggiunge un paio di cose importanti che sono sicuro che anche vim abbia. Un rapido salto in modalità esadecimale risolve molti problemi di testo "che diavolo sta succedendo". E la gestione completamente flessibile delle terminazioni di riga è una manna dal cielo che è diventata una caratteristica prevista per un editor di testo. Infine, può aprire qualsiasi file indipendentemente dal contenuto. Ciò equivale a un'abilità di hacking d'élite del primo ordine.

In Unix è possibile acquisire rapidamente l'output del programma o persino filtrare sezioni del file tramite comandi esterni. Una funzione estremamente potente ma credo sottoutilizzata.

Uso Vim abbastanza spesso. Tuttavia, non sostituisce UltraEdit per me. Dato che sono stati elencati molti aspetti positivi, immagino che andrò controcorrente ed elencherò alcuni fastidi con Vim.

• Debole gestione FTP. "Ordino" molti siti e non essere in grado di sfogliare e modificare facilmente i file su un server FTP remoto è una grande carenza per me. NWRead non è abbastanza buono.
• Le stranezze della console ereditate dai problemi generali del terminale che sembrano affliggere Linux. Di solito uso PuTTY per connettermi alla mia macchina Linux (con Ubuntu in esecuzione) e, per qualche motivo, i tasti freccia vengono mappati su A / B / C / D in modalità di inserimento (e tutti i problemi di supporto del colore). In gVim, ctrl-tab può essere mappato su "bn" easy, ma non in modalità console, tali problemi abbondano.
• Le opzioni di ricerca / sostituzione sono molto deboli, dal punto di vista dell'interfaccia. Dover digitare l'intera cosa in una singola riga, semplicemente non è abbastanza buono. Sento che il dialogo molto più elaborato in UltraEdit mi dà molto più potere alla fine, anche se il supporto effettivo delle espressioni regolari può essere molto più debole.
• Una dipendenza troppo forte dai layout di tastiera statunitensi. Molti tasti usati per le funzioni primarie, come `, non sono stampabili sul mio layout di tastiera danese (e si trovano arkwardly, lo stesso di $ e molti altri). Rende abbastanza scomodo l'utilizzo di alcune funzioni.

Desktop remoto mostra rapidamente solo l'applicazione Windows nativa. Abbiamo provato a utilizzare Eclipse per sviluppare sotto Unix. E tu sai cosa? Non era nemmeno possibile.

La seconda ragione è che potremmo estendere i nostri Vims ed Emacs per eseguire tutte le attività specifiche del progetto dalla navigazione nel DB in un modo speciale per evidenziare e completare automaticamente il nostro meta linguaggio.

Direi che uno dei grandi vantaggi è l'estensibilità dell'editor vim. Se voglio che qualcosa funzioni con CVS, posso prendere il plugin CVSMenu e aggiungerlo al mio editor per ottenere quella funzionalità.

Lo stesso vale per l'evidenziazione della sintassi, il comportamento con file specifici, ecc. Ogni genere di cose può essere adattato in vim.

Non sono così sicuro se puoi farlo facilmente negli editor di tipo GUI.

Registra e riproduci in VIM è incredibilmente fantastico, cosa che difficilmente troverai negli strumenti basati su GUI.

Anche l'incremento / decremento automatico offre capacità di generazione dei dati senza scrivere programmi per esso.

Sono stato un utente occasionale di Emacs per anni. Ma non ci sono mai entrato davvero. Poi ho iniziato a imparare Clojure (il mio primo Lisp) e ho scoperto ParEdit.

E questo mi ha sbalordito.

(Vedi qui per alcuni esempi: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit è l'esperienza di editing più incredibile che abbia mai avuto. Nient'altro si avvicina. Il lisp non è più un linguaggio scomodo da scrivere, costringendomi a preoccuparmi di bilanciare molte e sciocche parentesi irritanti. Con ParEdit, la struttura Lisp coerente diventa un enorme vantaggio con cui lavorare, poiché le stesse trasformazioni ad albero - slurping, barfing, splitting e join - funzionano ovunque, sia nelle strutture di controllo che nelle strutture dati. E ParEdit mi impedisce di fare errori stupidi. Diventa quasi impossibile fare errori di sintassi.

E a differenza di Eclipse, questo non è un laborioso controllo in tempo reale che è sempre in esecuzione in background, bruciando il mio processore. Non costa nulla ... ParEdit esegue semplicemente il cambiamento strutturale corretto quando lo chiedo.

(In generale Emacs è veloce quanto deve essere. A differenza di Eclipse che è come digitare colla.)

La prossima cosa che ho scoperto è stata Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Ancora una volta, non avevo usato nulla di simile prima. Non semplicemente una macro per aggiungere boilerplate, ma una forma dinamica e navigabile.

Il piacere finale è la consapevolezza che se voglio estendere questa cosa da solo, per avere più di questi strumenti di produttività di alto livello, ho il potere del Lisp stesso con cui lavorare.

(Il mio background è di alcuni anni con Visual Studio e altri IDE, poi 15 anni di Vim e gli ultimi 6 mesi con Emacs.)

Longevità - Vim / Emacs sono FOSS e esistono da decenni. Il loro utilizzo non diminuirà, né le loro funzionalità si interromperanno / scompariranno / cambieranno molto, quindi puoi fare affidamento sulla costruzione del tuo intero pacchetto di strumenti per la carriera attorno alla padronanza di un solo editor.

Accesso remoto / onnipresente nei terminali - Sebbene entrambi abbiano ottimi sistemi per la modifica dei file remoti, puoi anche averli installati su qualsiasi sistema a cui accedi.

Sviluppo basato su REPL - Entrambi hanno modalità "SLIME" in varie forme che integrano qualsiasi tipo di REPL con cui stai lavorando. Ad esempio, non ho mai riscontrato uno sviluppo iterativo potente come quello fornito da CIDER .

Linting - Qualunque sia la lingua che stai utilizzando probabilmente ha alcuni strumenti di linting , sia incorporati nel compilatore che uno strumento esterno. Questi si integrano perfettamente con Emacs / Vim, mostrando i tuoi errori di codifica quasi in tempo reale.

Grammatica dei comandi mnemonici : sebbene sia necessario del tempo per imparare, questi editor dispongono di sistemi notoriamente intelligenti per accedere - e persino ricordare - migliaia di comandi con pochi tasti e combinazioni di tasti. Questi possono eliminare completamente qualsiasi necessità di utilizzare un mouse se sei così incline.

Sistemi di guida incorporati : la documentazione offline di molte lingue e delle relative API è comune da trovare incorporata in questi editor ed è accessibile in modo altrettanto semplice ai sistemi di guida vasti e completi che presentano. È stato aggiunto il completamento automatico per le lingue più comuni. Inoltre, sono disponibili numerosi aiuti per la discussione su praticamente qualsiasi argomento della guida.

Navigazione : tag, paredit-likes, mark, windowing, tabs, vim-rails ' jumping e molti altri built-in.

Gestori di pacchetti / archivi - Emacs ne ha alcuni (elpa, melpa, marmellata) e anche quelli di Vim (vundle, patogeno, ecc .). Non conosco alcuna comunità intorno agli IDE che offra qualcosa di paragonabile a questi. Vedo più di 5.000 pacchetti con package-list-packages.

Oltre la semplice modifica : Emacs si spinge oltre qui con la possibilità di leggere notizie, navigare sul Web, gestire la posta elettronica, modificare fogli di calcolo, creare presentazioni e organizzare qualsiasi cosa.

Tutto il resto integrato : debugger, sincronizzazione del browser, compilazione, shell, esecuzione di test.

Infinitamente personalizzabile - Elisp è un linguaggio molto potente per estendere / modificare Emacs. VimL è l'equivalente di Vim. Ci sono libri scritti su entrambi. Modifica i temi dei colori e i comportamenti per il tuo piacere!

Un vantaggio che tutti gli editor basati su console hanno rispetto agli editor GUI è che possono essere eseguiti in un multiplexor terminale come screen o tmux . Perché va bene?

• È più veloce passare da una console multiplexor terminale a un'altra piuttosto che passare da una console GUI a un'altra utilizzando il mouse o anche utilizzando alt-tab. Questo perché è possibile assegnare un nome alle console e accedervi digitando alcuni caratteri del nome.
• Se le sessioni dell'editor si trovano nelle console di un multiplexor terminale, puoi accedervi da qualsiasi macchina. Se ho bisogno di fare un po 'di lavoro da casa, posso ssh nella mia scatola, collegare il multiplexor terminale già in esecuzione alla mia sessione ssh ed essere esattamente dove avevo interrotto quando ho lasciato il lavoro.

Poiché vim / emacs sono spesso usati dai programmatori e come utente C # dal 2003, da questo bias pov è giusto fare questo confronto altrimenti ingiusto (un altro potrebbe essere VS C ++ con Visual Assist X vs C ++ in vim / emacs):

Per C # e Visual Studio:

1. Ho appena contato la quantità di sequenze di tasti per questa riga:

       public List<string> Names = new List<string>();
   //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
   //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
   // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete

2. Ho letto della funzionalità di emacs per saltare nel codice. Non penso che abbia caratteristiche esattamente come quella. Tuttavia ha una caratteristica simile. Ecco lo svantaggio di VS. Ci sono molte piccole funzionalità ma col tempo smettono di funzionare. L'ultima volta che ho controllato la funzione di salto non funzionava, ma è stato un paio di anni fa. VS ha introdotto una nuova funzionalità di salto grafico che ho usato invece. Richiede mouse o tocco.

3. Ecco dove vincono emacs / vi. Se devi saltare molto nel codice, le funzionalità di VS per questo non esistono o non sono state testate abbastanza.

Il problema con la navigazione GUI basata sul mouse è questo

a) proprio come stare seduti in una posizione molto statica forse male, se è così, i mouse tendono a far stare anche le dita in una posizione statica. Il mio dolore al polso è andato via con il passaggio alla trackball. Ho provato per la prima volta il mouse verticale ma non ha risolto il problema.

b) La mia tastiera ideale avrebbe 2 file di tasti funzione, nessun tastierino numerico, quindi potrei posizionare la trackball più vicino, rendendo la distanza di salto più sopportabile.

In definitiva, tuttavia, se vuoi saltare tra pochi punti specifici, è chiaro che il "mark ring" è più efficace. VS ha qualcosa del genere ... l'ultima volta che l'ho usato, semplicemente non funzionava in modo affidabile ...

c) e probabilmente ci sono un sacco di piccole funzionalità che si rompono con ogni versione, quindi questo è il lato negativo di VS.

Soluzione a questo problema "closed source": scrivere l'intero VS in C # e quindi consentire la modifica / modifica del codice compilato (in fase di esecuzione, salvando le modifiche come patch che viene facoltativamente caricata all'avvio successivo) senza rilasciare il sorgente. Questo può essere fatto facendo in modo che il decompilatore emetta il codice come era quando si entrava. 180 gradi rispetto a come funzionano i compilatori nativi. Il binario diventa quindi il codice sorgente e l'eseguibile invece questo pasticcio di file .cs e .exe ecc. Esistono strumenti di terze parti che possono quasi farlo già, quindi "modding" C # exe è piuttosto banale ma propongo di portarlo a la conclusione logica: includere anche i commenti in .exe e .dll. I file saranno ancora piccoli rispetto alle app C / C ++ compilate. Ottimizzazione? Potresti anche includere codice pre-ottimizzato. Quando il modder modifica l'exe mentre l'app è in esecuzione, "AST" non modificato e il binario ottimizzato associato vengono ricollegati. Stessa idea del compilatore C # ma portata oltre. Passaggio successivo: scrivi l'intero sistema operativo in questa lingua, in modo che anche quando Windows è closed source, può essere banalmente modificato poiché il codice sorgente viene fornito con ogni binario. Nessuna impostazione di ambienti, compilazione, collegamento. Basta modificare il sistema operativo mentre è in esecuzione. Stretta analogia: se hai scritto il browser web in Common Lisp, potresti modificare il browser web senza interromperlo e creare pagine web nella stessa lingua del browser. può essere banalmente modificato poiché il codice sorgente viene fornito con ogni binario. Nessuna impostazione di ambienti, compilazione, collegamento. Basta modificare il sistema operativo mentre è in esecuzione. Stretta analogia: se hai scritto il browser web in Common Lisp, potresti modificare il browser web senza interromperlo e creare pagine web nella stessa lingua del browser. può essere banalmente modificato poiché il codice sorgente viene fornito con ogni binario. Nessuna impostazione di ambienti, compilazione, collegamento. Basta modificare il sistema operativo mentre è in esecuzione. Stretta analogia: se hai scritto il browser web in Common Lisp, potresti modificare il browser web senza interromperlo e creare pagine web nella stessa lingua del browser.