it-swarm.it

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

Il mio lavoro quotidiano è sviluppatore Java/Web. Uso Eclipse da circa 5 anni. Penso che sia eccellente e utilizzo anche Webstorm per javascript e html/jsp.

A volte ho bisogno di ssh nel server e pasticciare con i file di configurazione; per questo uso vi e mi fa male. Devo aprire una pagina web che elenca la sintassi/i comandi: premi Esc, quindi asterix, gira tre volte e il testo verrà inserito due righe sopra il cursore . È così non intuitivo per me, e immagino chiunque sia cresciuto alla fine degli anni Ottanta.

Ecco i motivi principali per cui penso che Eclipse sia geniale (e presumo altri IDE), e non passare a emacs e/o vim.

  • Errore durante l'evidenziazione senza necessità di ricompilare il progetto.
  • Codice assist.
  • Refactoring.
  • Chiamata di apertura hiearchy/Dichiarazione di apertura.
  • Completamente integrato con il controllo del codice sorgente.
  • Il debugger è incluso.
  • disponibilità di plugin di terze parti, ad esempio findbugs/checkstyle.

Uno degli argomenti che ho sentito è che con emacs/vim puoi creare i tuoi plugin - bene, ma puoi farlo anche in Eclipse. Ma non è necessario perché tutto è già lì! È come dire che compra questa macchina costruita a metà, puoi costruire tu stesso il resto.

Perché le persone usano emacs/vim? Le persone che lo usano lavorano effettivamente su progetti complessi orientati agli oggetti in grandi organizzazioni?

Quali sono i motivi per passare a vim/emacs. In che modo la mia produttività aumenterebbe se passassi da me a un'altra?

31
NimChimpsky

Usa qualsiasi strumento adatto alle tue esigenze. Conoscere VIM o Emacs è una buona cosa se devi mai accedere a un server remoto e modificare un file di configurazione o qualcosa di simile. Conosco VIM ragionevolmente bene , ma non lo userei per sviluppare in Java. Ecco per cosa sono fatti Eclipse, Netbeans ecc.

36
user281377

Emacs e Vi hanno ancora un posto.

  • Sono onnipresenti disponibili in ambienti Unix e Unix e possono essere installati sulla maggior parte delle altre piattaforme popolari.

  • Sono popolari e stabili, quindi impararli una volta paga nel lungo periodo.

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

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

La chiave per comprendere questi programmi, tuttavia, è sapere quali problemi dovevano originariamente risolvere. Per Vi questo stava modificando i file di testo su connessioni terminali lente quanto 300 Baud. In quell'ambiente non si desidera visualizzare menu o modificare radicalmente il contenuto dello schermo se è possibile evitarlo.

Emacs doveva essere utilizzato in un ambiente più veloce. Il suo punto di forza era che poteva essere caricato una volta e non era mai uscito. L'utente potrebbe svolgere qualsiasi altra attività di cui aveva bisogno da Emacs senza andarsene, e spesso in un modo più amichevole che se dovesse farlo dalla riga di comando. Le persone non avevano un ambiente desktop grafico con una finestra Emacs aperta. Emacs consente all'utente di svolgere quasi tutte le attività normali (e molte altre strane) con pochi tasti. Qualunque cosa non incorporata potrebbe essere scritta.

Ovviamente i bisogni delle persone sono cambiati molto da quando questi programmi sono stati introdotti, ma hanno ancora dei veri punti di forza. Ho imparato le basi di entrambi e li uso su base settimanale. Tuttavia, penso che i loro punti di forza siano spesso sopravvalutati. Hanno raggiunto uno status così leggendario che le persone non ammettono le loro debolezze e invece tendono a pensare di fare qualcosa di sbagliato se Emacs/Vi non le rende più produttive di Eclipse o Visual Studio.

Adesso al punto.

Java è un linguaggio popolare con un eccellente supporto in Eclipse e probabilmente stai sviluppando codice su un moderno sistema operativo che ti consente di eseguire rapidamente attività comuni e di eseguire lo script di altri senza farlo tramite il tuo IDE. Non penso che avrebbe senso cambiarti.

39
PeterAllenWebb

Uso emacs da oltre 5 anni. Non posso più dirti le combinazioni di tasti che sto usando, le mie dita le ricordano e devo guardare la tastiera solo per vedere cosa scrivono le mie mani.

Alcuni anni fa ho iniziato a utilizzare Eclipse e non c'è alcuna possibilità che torni a emacs liberamente. Mi dispiace memoria muscolare, anche se ti manca vecchio C-x r SPC 1, Eclipse mi rende molto più produttivo e questo è ciò che conta.

No, non credo che dovresti cambiare, ma dovresti dedicare un paio d'ore per imparare le basi di VIM, quindi non devi più cercarlo.

16
Martin Wickman

Perché dovrei passare a vim o 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 a il suo sottoinsieme di cose specifiche dell'IDE e vim è molto bravo nel suo sottoinsieme di cose specifiche della modifica del testo. Ognuno ha il suo, diverso, focus.

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

Quello che faccio nel mio lavoro quotidiano è usare sia Visual Studio che vim per la modifica di C #. Funziona molto bene per me e non taglierei mai uno di essi per fare affidamento esclusivamente sull'altro.

Per quanto riguarda emacs, non sono un esperto, ma non credo che possa competere con le funzionalità IDE di Eclipse quando si tratta di Java (per favore 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 usare insieme a Eclipse, ti consiglio vivamente di imparare sia Vim che Emacs. Ma come supplemento, non come sostituto . Può davvero ripagare a lungo termine, anche se nessuno dei due ha una curva di apprendimento particolarmente semplice:)

Ecco un bella lettura longeva sui punti di forza di vim. Ed ecco n elenco di alcuni trucchi che puoi fare.

7
Nick Knowlson

Fondamentalmente, leggi this (PDF) per vedere perché Emacs è potente. Una volta che conosci LISP, è quasi banalmente facile scrivere estensioni per questo (ho diversi flussi di lavoro e distribuzioni di controllo del codice sorgente tramite un componente aggiuntivo che ho scritto da solo chiamato employer-mode). Per quanto riguarda ciò che elenchi sopra;

  • Errore durante l'evidenziazione senza necessità di ricompilare il progetto. Non ha senso per tutte le lingue. Puoi facilmente integrare REPLs di molte lingue. In questo momento, ho Ruby, python, haskell, common LISP, scheme e erlang tutti collegati a emacs. Per inciso, il componente aggiuntivo JavaScript js2-mode ha una "compilazione" incrementale completa, quindi evidenzia cose come errori di sintassi per te, quindi è certamente possibile, ma non la norma
  • Codice assist. c'è un componente aggiuntivo per quello chiamato autocomplete.el, Credo, controlla Emacs wiki
  • Refactoring. Suppongo che intendi "refactoring automatizzato", il che non ha senso in tutte le lingue. Probabilmente esiste per alcuni, ma non lo so.
  • Chiamata di apertura hiearchy/Dichiarazione di apertura.
  • Completamente integrato con il controllo del codice sorgente. Ha un git-mode integrato in Emacs 22.3, non sicuro di altri controlli del codice sorgente
  • Il debugger è incluso. Base lingua per lingua qui. Generalmente, se ha REPL integrazione, ha anche un debugger Emacs, ma non è universale
  • disponibilità di plugin di terze parti, ad esempio findbugs/checkstyle. non conoscono quelli specifici, ma ci sono molti addon per questo, dal perché-non-questo-nel-pacchetto-base-utile, al completamente frivolo

Detto questo, se non ti piace LISP e non hai intenzione di impararlo, non posso sinceramente raccomandare Emacs. La vittoria che ne ottieni è imparare a creare strumenti e applicare quei principi per aumentare la tua produttività, non ottenere un sacco di mod standardizzati e metterli insieme.

6
Inaimathi

Vedo due opzioni qui:

  • Usa invece Nano: è esattamente come Blocco note in Windows per Linux. Non richiede combinazioni di tasti di scelta rapida, basta digitare nano somefile.conf e hai un editor piacevole. Puoi anche aggiungere l'evidenziazione della sintassi
  • Mantenere il programma localmente e sincronizzare SCP con il server: lo faccio quando devo lavorare su un piccolo sito Web ma non ho risorse sufficienti per eseguire Apache localmente. Apro semplicemente WinSCP, apro le directory che desidero e utilizzo "Mantieni aggiornati i file remoti". Le modifiche si riflettono generalmente in pochi secondi
  • Usa un plugin nel tuo editor/IDE per lavorare "direttamente" con il file remoto. Prima di occuparmi del controllo di revisione, ho semplicemente avviato Notepad ++ (il mio editor preferito) e usato NppFTP per lavorare sui file. NppFTP è più veloce dell'opzione WinSCP poiché Npp lo comunica immediatamente quando viene salvato un file, che viene immediatamente caricato. Tuttavia, come ho detto, perdi il controllo delle revisioni. Sono sicuro che c'è un plugin per Eclipse che puoi usare

Spero che sia di aiuto

3
TheLQ

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

Preferirei tuttavia Eclipse per la grande scala Java a causa delle molte funzionalità che sono prontamente disponibili. Naturalmente, ci sono alcuni plugin che possono rendere un po 'Eclipse più tollerabile.

2
user7908

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

Ma, a differenza di te, sto programmando principalmente Ruby, e non ho bisogno di tutta quella magia nera generatrice di codice, completamento automatico, refactor-my-code che NetBeans ed Eclipse offrono. Se stavo codificando Java o C #, certamente non proverei affatto a cambiare.

1

Come utente di lunga data di emacs, trovo emacs abbastanza comodo come ambiente di editing e sviluppo (e in una certa misura, si integra anche con il processo di compilazione, il controllo della versione, la ricerca rapida sensibile al contesto e simili, quindi immagino che si qualifichi come "IDE").

Sono anche molto a mio agio con l'uso di editor simili a vi e vi (ho iniziato a utilizzare ed, perché pensavo che emacs fosse troppo complesso; a posteriori, è un passo indietro, ma mi ha dato una solida base per l'apprendimento futuro di vi). Uso vi principalmente per "piccole modifiche rapide", principalmente su macchine remote in cui emacs non è installato.

Per il tuo "Ho bisogno in alcune occasioni di ssh nel server e pasticciare con i file di configurazione; per questo uso lo scenario vi", consiglierei un piccolo set di comandi e alcuni pensieri generali intorno a vi:

  • Vi non è modale, ha i comandi "a" (append), "A" (append alla fine della riga), "i" (insert) e "I" (inserire all'inizio della riga), prendendo il testo da inserire come argomento e segnalazione "end-of-command" con Esc
  • h, j, kel sono tasti di movimento. Può funzionare usando i tasti freccia, ma poiché la tipica sequenza "Io sono un tasto freccia" in stile VT inizia con Esc, questo interromperà il comando di inserimento del testo a cui non stai pensando
  • : lino ti porta alla linea lino , la linea 1 è in cima- la maggior parte della riga $ $ è la più in basso
  • . è il comando "ripeti ultimo comando" (vedi il primo punto)

Non ci vorrà più di un'ora o due a giocare con vi per essere al "Posso modificare con sicurezza un file di testo, ma potrei non essere efficiente con esso" ed è buono come probabilmente dovresti essere . In caso contrario, qualsiasi editor che non si preoccupa della conversione automatica tra schede e spazi dovrebbe essere "abbastanza buono" per i tuoi scopi. Se Eclipse è installato su tutti i tuoi server remoti, non vedo che usarlo come un grosso problema, davvero.

1
Vatine

Se sei soddisfatto di Eclipse, non passare.

Se è possibile utilizzare Eclipse ovunque sia necessario, non cambiare.

Se il tuo progetto/azienda utilizza praticamente esclusivamente Eclipse, non passare.

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

Vedi la (stessa) domanda su SO: https://stackoverflow.com/questions/1346820/what-are-the-efficiencies-afforded-by-emacs-or-vim-vs-Eclipse

Per quanto riguarda la risposta, "Le persone che lo usano lavorano effettivamente su progetti complessi orientati agli oggetti in grandi organizzazioni?" - Tieni il cappello, figliolo, ma la risposta è "sì". Ho lavorato su progetti con decine di milioni di righe di codice utilizzate nel percorso critico della progettazione della stessa CPU che esegue il computer che stai utilizzando per porre questa domanda. E le persone hanno provato Eclipse ma l'hanno trovato troppo lento e goffo (anche se, certamente, non stavamo usando Java).

1
Trey Jackson

Sono un ragazzo Emacs. Lo uso per tutta la mia programmazione e incoraggio attivamente anche i miei collaboratori (e 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 roba con nomi lunghi, che guadagna - I ottenuto dall'uso di Emacs si perde completamente nel tentativo di ricordare tutto.

Vi incoraggio certamente a provare vim e/o Emacs. Ma probabilmente finirai di nuovo in Eclipse per Java.

1
MattBelanger

Sia emacs che vim sono editor molto configurabili e potenti, ed entrambi forniscono grandi guadagni in termini di produttività una volta acquisiti i concetti di base.

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

Emacs è ugualmente potente, ma devi imparare Emacs LISP per sfruttarlo al massimo.

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

1
Larry Coleman

Lo strumento migliore (a breve termine) è quello con cui sei altamente competente.

Le persone usano una tecnologia di oltre 30 anni perché sono altamente competenti. Hanno costruito il flusso di lavoro e le abitudini attorno a questi strumenti. Se hai più familiarità con un moderno IDE come Eclipse, non ci sono molte ragioni per cambiare. Imparare a usare Eclipse in modo più efficiente è un investimento migliore del tuo tempo (es. Uso - Mylyn ).

1
dbkk

Personalmente entrambi i programmi mi portano su per il muro. Il problema con Eclipse è che è lento quando si lavora su un grande progetto ed è allora che non sta eseguendo "indicizzazione DGLP" o altro. vuoi aggiornare il tuo repository? hai 15 minuti? Oh e che ne dici di quel trucco ingegnoso in cui Ctrl-C del testo poi Ctrl-P da qualche parte ma invece di andare dove lo volevi, apre un file completamente diverso e passa sopra qualcos'altro e ti rimane chiedendo wtf era lì innanzitutto. Oh, e ho già parlato di lavorare con Eclipse su un grande progetto su un VPN? praticamente impossibile.

Per quanto riguarda vim, è bello e veloce supponendo che tu conosca la moltitudine di combinazioni di tasti completamente insensate per fargli fare qualcosa e buona fortuna se ti trovi in ​​una modalità sconosciuta per caso. Inoltre, con vim devi praticamente conoscere l'intera struttura della directory dei progetti nella tua testa per poter aprire i file corretti. Il vantaggio principale di Vim è che in teoria puoi creare codice più velocemente perché sono tutte le chiavi, ma in realtà non mi importa di quanto testo sto scrivendo, non è il volume di testo che conta sia la qualità del codice e spesso la qualità il codice richiede di fissare dozzine di file per ore e ore fino a quando non si capisce la cosa giusta da digitare (che di solito è molto breve).

Ciò che desidero è che qualcuno scriva un programma da riga di comando, come VIM, che in realtà ha una struttura di directory come Eclipse sul lato o qualcosa da cui potresti espandere/comprimere e aprire i file. Qualcuno sa qualcosa del genere?

0
Dallas Caley

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

Questo probabilmente merita un po 'più di contesto: 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 clic. Disponiamo di una serie di ambienti di test, quindi in qualsiasi momento posso apportare una modifica tramite Eclipse, controllarlo in cvs e attivare una build/deploy per dimostrare che la mia correzione ha funzionato. Quindi, se sto hackerando in 'vi', è perché non possiamo aspettare il turnaround di 1 ora di una distribuzione o perché la distribuzione non copre i file che sto modificando e deve essere estesa per fare quindi (altrimenti la prossima volta che cambierò il file in questione, dovrò hackerare vi).

0
DanW