Uso un IDE (Eclipse) per sviluppare software. Perché dovrei passare a vim o emacs? [chiuso]

Usa qualsiasi strumento adatto alle tue esigenze. Conoscere VIM o Emacs è una buona cosa se si deve accedere a un server remoto e modificare un file di configurazione o qualcosa di simile. Conosco VIM abbastanza bene, ma non lo userei per svilupparlo in Java. Questo è ciò che Eclipse, Netbeans ecc. Sono fatti per.

Emacs e Vi hanno ancora un posto.

• Sono disponibili ovunque in ambienti Unix e Unix e possono essere installati su molte altre piattaforme popolari.

• Sono popolari e stabili, quindi impararli una volta paga a lungo termine.

• Corrono su un terminale di testo, quindi puoi usarli nelle sessioni telnet e ssh.

• Forniscono modalità di modifica e evidenziazione della sintassi per un'ampia varietà di lingue, incluse le lingue molto nuove e molto rare. (Questo è uno dei miei vantaggi preferiti.)

La chiave per comprendere questi programmi, però, è sapere quali problemi originariamente intendevano risolvere. Per Vi si trattava di modificare i file di testo su connessioni terminali con una velocità di 300 Baud. In quell'ambiente non si desidera visualizzare i menu o modificare radicalmente il contenuto dello schermo se è possibile evitarlo.

Emacs è stato progettato per essere utilizzato in un ambiente più veloce. Il punto di forza era che poteva essere caricato una volta e non essere mai uscito. L'utente è in grado di svolgere qualsiasi altra attività di cui ha bisogno da Emacs senza andarsene, e spesso in un modo più amichevole di quello che avrebbe dovuto farlo dalla riga di comando. Le persone non avevano un ambiente desktop grafico con una finestra di Emacs aperta. Emacs consente all'utente di eseguire quasi tutti i normali compiti (e molti strani) con pochi tratti chiave. Tutto ciò che non è incorporato potrebbe essere copiato.

Ovviamente i bisogni delle persone sono cambiati molto da quando sono stati introdotti questi programmi, ma hanno ancora dei veri punti di forza. Ho imparato le basi di entrambi e li uso settimanalmente. Tuttavia, penso che i loro punti di forza siano spesso esagerati. Hanno raggiunto un tale status leggendario che le persone non ammettono le loro debolezze e tendono invece a pensare che stiano facendo qualcosa di sbagliato se Emacs / Vi non li rende più produttivi di Eclipse o Visual Studio.

Ora al punto.

Java è un linguaggio popolare con un eccellente supporto in Eclipse, e le probabilità sono che stai sviluppando codice su un moderno sistema operativo che ti consente di eseguire velocemente compiti comuni e di scriptarne altri senza farlo attraverso il tuo IDE. Non penso che avrebbe senso per te cambiare.

Utilizzo Emacs da oltre 5 anni. Non posso più dirti le combinazioni di tasti che sto usando, le mie dita le ricordano e devono guardare la tastiera solo per vedere cosa stanno digitando le mie mani.

Alcuni anni fa ho iniziato a usare Eclipse e non ho alcuna possibilità di tornare a emacs liberamente. Scusa la memoria muscolare, anche se ti manchi il vecchio C-x r SPC 1 , Eclipse mi rende molto più produttivo e questo è ciò che conta.

No, non penso che dovresti cambiare , ma dovresti dedicare un paio d'ore per imparare le basi di Vim in modo da non doverlo più cercare.

Why should I switch to vim or emacs?

Molto probabilmente, non dovresti cambiare . Vim è un editor di testo eccellente e potente, ma non è un sostituto per un IDE, e non dovrebbe essere! Eclipse è molto bravo nel suo sottoinsieme di IDE -le cose specifiche, e vim è molto bravo nel suo sottoinsieme di cose specifiche per il text-editing. Ognuno ha il proprio, diverso, focus.

So che ci sono plugin che estendono le funzionalità di vim in modo che possa fare molte delle stesse cose specifiche dell'IDE che un IDE può fare. Ma non è ancora la forza principale di Vim, e un IDE sarà quasi sempre in grado di farlo meglio. Perché è quello su cui sono focalizzati.

Quello che faccio nel mio lavoro quotidiano è utilizzare entrambi Visual Studio e vim per modificare C #. Funziona molto bene per me, e non escluderei mai uno di loro per fare affidamento esclusivamente sull'altro.

Per quanto riguarda emacs, non sono un esperto, ma non penso che possa competere con le funzionalità IDE di Eclipse quando si tratta di Java (correggimi se sbaglio). Se stai sviluppando in lisp, allora certamente può essere considerato un IDE eccellente, ma non penso che abbia lo stesso supporto per Java.

Quindi se vuoi un editor di testo più potente da utilizzare insieme a Eclipse, ti consiglio vivamente di imparare sia vim che emacs. Ma come supplemento, non come sostituzione . A lungo andare può davvero pagare, anche se nessuno di loro ha una curva di apprendimento particolarmente facile:)

Ecco una bella lettura lunga sui punti di forza di vim. Ed ecco un elenco di alcuni buoni trucchi che puoi fare.

In pratica, leggi questo (PDF) per capire perché Emacs è potente. Una volta che conosci Lisp, è quasi banalmente facile scrivere estensioni per esso (ho diversi flussi di lavoro di controllo di origine e le implementazioni sono state programmate tramite un componente aggiuntivo che ho scritto per me chiamato employer-mode ). Per quanto riguarda ciò che elencherai sopra;

• Errore di evidenziazione senza bisogno di ricompilare il progetto. Non ha senso per tutte le lingue. Puoi facilmente integrare REPLs di molte lingue. Al momento, ho ruby , python , haskell , common lisp , scheme e erlang tutti agganciati a emacs. Per inciso, l'addon di JavaScript js2-mode ha una "compilazione" incrementale completa, quindi mette in evidenza cose come errori di sintassi per te, quindi è certamente possibile, ma non la norma
• Assistenza codice. c'è un addon per quello chiamato autocomplete.el , credo, controlla la wiki di Emacs
• refactoring. Immagino tu intenda "refactoring automatico", che non ha senso in tutte le lingue. Probabilmente esiste per alcuni, ma non lo so.
• Apertura della chiamata alla ricerca / dichiarazione di apertura.
• Completamente integrato con il controllo del codice sorgente. Ha un git-mode incorporato in Emacs 22.3, non sicuro di altri controlli del codice sorgente
• Debugger è incluso. Base lingua per lingua qui. In genere, se ha l'integrazione REPL, ha anche un debugger Emacs, ma non è universale
• disponibilità di plug-in di terze parti, ad esempio findbugs / checkstyle. non so di quelli specifici, ma ci sono molti add-on per questo, dal perché-non-questo-in-base-pacchetto-utile, fino al tutto frivolo

Detto questo, se non ti piace Lisp, e non hai intenzione di impararlo, non posso sinceramente raccomandare Emacs. La vittoria che ne ricaverai sta imparando a sviluppare strumenti e ad applicare questi principi per aumentare la tua produttività, non comprando una serie di mod off-the-shelf e unendoli insieme.

Vedo due opzioni qui:

• Usa invece Nano - Questo è esattamente come Blocco note in Windows per Linux. Non richiedendo combinazioni di tasti di scelta rapida, devi solo digitare nano somefile.conf e hai un bel editor. Puoi anche aggiungere l'evidenziazione della sintassi
• Mantieni il programma localmente e sincronizza tramite SCP sul server: lo faccio quando devo lavorare su un sito web di piccole dimensioni ma non ho abbastanza risorse per eseguire apache localmente. Ho semplicemente richiamato WinSCP, richiamato le directory che desidero e uso "Mantieni i file remoti aggiornati". Le modifiche si riflettono di solito in secondi
• Usa un plugin nel tuo editor / IDE per lavorare "direttamente" con il file remoto - Prima di preoccuparmi del controllo delle revisioni, ho semplicemente attivato Notepad ++ (il mio editor preferito) e usato NppFTP per lavorare sui file. NppFTP è più veloce dell'opzione WinSCP poiché Npp lo dice immediatamente quando viene salvato un file, che viene immediatamente caricato. Comunque, come ho detto, perdi il controllo delle revisioni. Sono sicuro che c'è un plugin per Eclipse che puoi usare

Spero che questo aiuti

Personalmente, mi piace Vim perché è estremamente bravo a modificare il testo, ad esempio è molto ergonomico (le combinazioni di tasti non mi affaticano troppo e non ho bisogno di usare il mouse così tanto) ed è efficiente da usare una volta ottenuto il blocco di esso (che ovviamente richiederà tempo e pazienza, dal momento che non è l'editor più intuitivo per i principianti).

Preferirei comunque Eclipse per lo sviluppo su larga scala di Java a causa delle numerose funzionalità che sono facilmente disponibili. Naturalmente, ci sono alcuni plugin che possono rendere Eclipse un un po 'più tollerabile.

Se sei soddisfatto di Eclipse, non cambiare.

Se puoi utilizzare Eclipse ovunque ti serva, non cambiare.

Se il tuo progetto / azienda utilizza quasi esclusivamente Eclipse, non cambiare.

Se solo raramente hai bisogno di qualcos'altro, stampa un cheat-sheet per uno dei redattori e tiralo fuori dal cassetto quando ne hai bisogno, quindi torna a utilizzare Eclipse.

Vedi la (stessa) domanda su SO: link

Per quanto riguarda la risposta, "Le persone che lo utilizzano lavorano effettivamente su progetti complessi orientati agli oggetti nelle grandi organizzazioni?" - Tieni il cappello sonny, ma la risposta è "sì". Ho lavorato su progetti con decine di milioni di righe di codice utilizzate nel percorso critico di progettazione della CPU che esegue il computer in uso per porre questa domanda. E la gente ha provato Eclipse ma l'ha trovata troppo lenta e goffa (anche se, ammettiamolo, non stavamo usando Java).

Sia emacs che vim sono editori molto configurabili e potenti, ed entrambi offrono grandi guadagni di produttività una volta che i concetti di base sono stati afferrati.

Vi vince con quelle che sono essenzialmente operazioni basate su set. Ad esempio, la modifica di tutte le istanze di "pippo" in "barra" in una definizione di classe è una riga singola.

Emacs è ugualmente potente, ma devi imparare Emacs Lisp per sfruttarlo al massimo delle sue potenzialità.

In entrambi i casi, vale la pena cambiare solo se prevedi di utilizzare emacs o vi per tutto .

Lo strumento migliore (a breve termine) è quello con cui hai una grande competenza.

Le persone usano la tecnologia di più di 30 anni perché sono molto abili con esso. Hanno costruito il loro flusso di lavoro e le loro abitudini attorno a questi strumenti. Se hai più familiarità con un IDE moderno come Eclipse, non ci sono molti motivi per cambiare. Imparare a utilizzare Eclipse in modo più efficiente è un investimento migliore del tuo tempo (ad esempio, utilizza Mylyn ).

Attualmente sto cercando di passare da NetBeans a Vim. L'apprendimento di Vim richiede tempo e pratica, ma ne vedo i vantaggi, chiamiamoli, "editor della GUI" per alcuni casi.

Ma, a differenza di te, sto codificando per lo più Ruby, e non ho bisogno di tutta quella magia nera che genera codice, auto-completamento, refactor-my-code che NetBeans ed Eclipse offrono. Se stavo codificando Java o C # non cercherò di cambiare affatto.

Come utente di lunga data di emacs, trovo che emacs sia piuttosto comodo come ambiente di editing e sviluppo (e in qualche misura si integra anche con il processo di compilazione, il controllo della versione, la ricerca rapida e sensibile al contesto e così via, quindi indovina che lo qualifica come "IDE").

Inoltre, mi sto davvero bene con gli editor vi e vi (ho iniziato a usare ed, perché pensavo che emacs fosse troppo complesso, in retrospettiva che è retrocesso, ma mi ha dato una solida base per l'apprendimento futuro di vi). Io uso vi principalmente per "piccole modifiche veloci", principalmente su macchine remote in cui non è installato emacs.

Per il tuo "devo fare occasionalmente ssh su server e gironzolare con i file di configurazione, per questo uso lo scenario di vi", consiglierei un piccolo insieme di comandi e alcuni pensieri generali su vi:

• Vi non è modale, ha comandi "a" (append), "A" (append alla fine della riga), "i" (insert) e "I" (insert at start of line), prendendo la testo da inserire come argomento e segnalazione "end-of-command" con Esc
• h, j, k el sono tasti di movimento. Potrebbe funzionare utilizzando i tasti freccia, ma come la tipica sequenza "I am an arrow key" in stile VT inizia con Esc, questo interromperà il comando di inserimento del testo a cui non stai pensando
• : linoum ti sposta sulla riga lino , la riga 1 è la linea più in alto e la riga $ è la più bassa
• . è il comando "ripeti l'ultimo comando" (vedi il primo punto elenco)

Non ci vuole più di un'ora o due di gioco con vi di essere in "Posso modificare con sicurezza un file di testo, ma potrei non essere efficiente con esso" e questo è buono come probabilmente bisogno di essere. In caso contrario, qualsiasi editor che non ha problemi di auto-conversione tra schede e spazi dovrebbe essere "abbastanza buono" per i vostri scopi. Se Eclipse è installato su tutti i tuoi server remoti, non vedo che utilizzarlo come un grosso problema, in realtà.

Sono molto un ragazzo di Emacs. Lo uso per tutta la mia programmazione e incoraggio attivamente anche i miei colleghi a usarlo (e loro mi ignorano attivamente). Lo trovo molto più produttivo di qualsiasi IDE e non cambierei mai.

A meno che non stia scrivendo Java o C # (e immagino ci siano altre lingue in questa categoria). Hanno librerie così grandi di stuff con nomi lunghi, che i guadagni I che ottengono dall'usare Emacs sono completamente persi nel cercare di ricordare tutto.

Ti incoraggio certamente a provare vim e / o Emacs. Ma probabilmente andrai a finire in Eclipse per Java.

Non ho alcun problema con i vari editor UNIX disponibili, ma li uso sempre e solo sotto protesta. Non, come ho detto, perché ho un problema con loro, ma perché se dovessi usarli significa che in qualche modo il nostro processo di implementazione è carente.

Questo probabilmente merita un po 'più di contesto: io lavoro su soluzioni di e-commerce su larga scala, tutto ciò che governa il funzionamento dei nostri sistemi è generato da un processo di creazione / distribuzione con un solo clic. Disponiamo di una vasta gamma di ambienti di test, quindi in qualsiasi momento posso apportare modifiche tramite Eclipse, controllarlo in cvs e attivare una build / deploy per dimostrare che la mia correzione ha funzionato. Quindi, se mi sto cacciando in "vi", è perché non possiamo aspettare il turnaround di un'ora di una distribuzione o perché la distribuzione non copre i file che sto modificando e deve essere estesa per fare quindi (altrimenti eseguirò l'hacking in vi la prossima volta che il file in questione deve essere modificato).

Personalmente entrambi i programmi mi guidano sul muro. Il problema con Eclipse è che è lento come snot quando stai lavorando su un progetto di grandi dimensioni e in quel momento non sta facendo "DGLP Indexing" o altro. vuoi aggiornare il tuo repository? ho 15 minuti? Oh e che ne dici di quel trucco elegante in cui fai Ctrl-C un po 'di testo e poi Ctrl-P da qualche parte, ma invece di andare dove vuoi tu apre un file completamente diverso e passa sopra qualcos'altro e ti chiedi se ci fosse wtf innanzitutto. Oh e ho parlato di lavorare con Eclipse su un grande progetto su una VPN? praticamente impossibile.

Per quanto riguarda vim, è bello e veloce supponendo che tu conosca la moltitudine di combinazioni di tasti assolutamente insensate per fargli fare qualcosa e buona fortuna se ti trovi in qualche modo sconosciuto per sbaglio. Inoltre con vim è necessario conoscere a fondo l'intera struttura della directory dei progetti per poter aprire i file corretti. Il principale vantaggio di Vim è che in teoria è possibile creare codice più velocemente perché è tutto in chiave, ma in realtà non mi interessa quanto testo scrivo, non il volume di testo che importa la qualità del codice e spesso la qualità il codice richiede di fissare decine di file per ore fino a quando non si individua la cosa giusta da digitare (che di solito è molto breve).

Ciò che desidero è che qualcuno scriva un programma a riga di comando, come vim, che in realtà abbia una struttura di directory come eclissi sul lato o qualcosa da cui potresti espandere / comprimere e aprire i file. Qualcuno sa qualcosa di simile?

Se non sei soddisfatto di VIM o EMACS, puoi cercare su quella macchina altri editor di testo. Potrebbero esserci alcuni tipi di nedit o gedit o somesuch che puoi usare, che avranno comandi più familiari (ctrl x, c, v e s fanno ciò che ti aspetteresti ad esempio).

Probabilmente hai più di due scelte sulla tua distribuzione, ne vale la pena dare un'occhiata.