das jemand noch solche vorsintflutliche Technik verwendet oder gar entwickelt?! VI war mir schon vor 15 Jahren waehrend des Studims ein Graus. Gleiches gilt fuer EMACS !!!!
die ihre lieblingseditoren/lizensen/betriebssysteme ueber die anderen stellen muessen und rumflamen muessen? irgendwie versteh ich das nicht. liegt aber sicher an sozialen defiziten auf seiten dieser trottel. olli
Hat nur bedingt mit der Meldung zu tun, aber eine der beliebtesten vi(m)-Alternativen, der Editor "joe", ist in der Zwischenzeit auch nicht stehengeblieben, und bietet in den neuesten Versionen ebenfalls Syntax-Highlighting sowie endlich auch Mausbedienung (wohlgemerkt: im Textmodus)...
Im Unterschied zu vi (und vim) verwaltet joe eine Editor-Datei intern nicht als verkettete Liste von Zeilen, sondern als Buffer (sog. "Buffer-Gap"-Editor, wie auch bei Emacs), und kommt daher deutlich besser mit sehr großen und "binären" Daten klar. Die Tastenkürzel orientieren sich standardmäßig an Wordstar (Emacs- oder Pico-Tastenbelegung ist aber auch möglich), daher ist "joe" insbesondere bei Leuten beliebt, die in den 1990ern mit den "Turbo"-Programmiersprachen der Firma Borland aufgewachsen sind, und sich an die "Wordstar"-Tastenbelegung gewöhnt haben.
Im Unterschied zu vi/vim ist joe "mode-less", d.h. es gibt keine separaten "Modi" fürs Texteingeben und sonstige Operationen wie bei vi/vim; die meisten Funktionen sind über CTRL-Tastenkombinationen zu erreichen. Ausserdem unterstützt "joe" immerhin gesplittete Fenster (wie gesagt, im Textmodus), (Listen-)Completion und History bei der Auswahl von Dateinamen, inkrementelle Suche (im Emacs-Modus), eine Online-Hilfe für alle Tastenkürzel (mit ^K-H), Blockmarkierungen mit der Maus, Mausräder, neun über Tastenkürzel erreichbare "Lesezeichen" pro Datei, Autoindent und Klammersuche, Wort-Completion im Text, Regexp-Suche, einen Rechner mit Hex-Unterstützung, hat ausserdem tadellose Undo-Unterstützung, und noch ein paar weitere Kleinigkeiten.
Das kann "vim" zwar alles auch, aber als modus-orientiertem Editor besteht bei vi/vim immer die latente Gefahr, dass man aus Versehen (oder durch einen einzelnen Vertipper im Kommandomodus) z.B. ein paar Zeilen zu viel löscht. Dafür hat allerdings "vim" eine mächtige Programmiersprache; "joe" hat lediglich eine sehr rudimentäre Makrosprache, aber immerhin sind alle Tastenkürzel konfigurierbar.
Was ich bei "joe" vermisse, ist der "cw"-Befehl (Change Word), bei dem man ein Wort ersetzen kann, aber während der Eingabe noch das alte Wort stehen bleibt; wegen der grundsätzlich anderen Bedienlogik wäre dieses Verhalten bei "joe" aber nur schwer zu realisieren.
Für jemanden, der nicht mit "Turbo Pascal" o.ä. aufgewachsen ist, ist der einzige nennenswerte Vorteil von "joe" vermutlich, dass das Binary (im Unterschied zu "vim") noch recht klein geblieben ist; unter Debian z.B. hat "joe" ca. 330KiB und linkt gegen 7 Libraries, darunter die "libc", "vim" ist 1,5MiB gross und linkt gegen 69 (!) Libraries, u.a. die Libraries von Perl, Python, Tcl, Ruby, GTK+/GNOME; das "joe"-Binary würde man (statisch kompiliert) noch auf eine Diskette bekommen, bei "vim" ist das fraglich - oder zumindest würden dabei wohl die meisten "vim"-Features auf der Strecke bleiben. (Insofern ist "vim" definitiv kein "kleiner schneller" Editor mehr, auch wenn er natürlich immer noch schneller startet als Emacs.)
nur damit man sein Maul aufgemacht. Danke an alle, die an der Diskussion über vim, joe, emacs, slick usw. teilgenommen haben. Ich persönlich gehe jetzt in die Kneipe und zieh' mir die Diskussionen am Nachbartisch rein: "Baaaah, Opel ist viel besser als VW... nö, Ford macht alle platt... also mit meinem Skoda bin ich wohl am besten dran!".
Jetzt paßt mal auf. Vim ist ein Editor, den viele für gut befinden, also ist er es wert, weiterentwickelt zu werden.
Wenn ein Editor vie Vim so schlecht sein soll und schwierig zu bedienen, vorsintflutlich (wie der lustige "Stiffler" meint) und kaum, was schrieb der komische Andi, "moderner Softwareergonomie" genügt, WARUM WIRD ER DANN SO OFT RUNTERGELADEN, INSTALLIERT UND BENUTZT?
Kruzifix noch einmal, VIM hat aus guten Gründen eine große Anhängerschaft, ergo dieser Editor hat eine VOLLE DASEINSBERECHTIGUNG!!!
Warum hat VIM ein so große Anhängerschaft? Wohl aufgrund seiner typischen Eigenschaften (und weniger aus Nostalgiegründen würde ich sagen).
dann verbraucht vim demnächst mehr ram als (x)emacs.
Dann hat es sich mit 'klein' - obwohl, das hat es sich ja schon, wenn man sich mal die riesigen source-Pakete anschaut.
Und mit dem orginalen, ach so kleinen vi hat es auch nicht mehr viel zu tun.
Wer es klein mag, kann ja jed mit vi-Bedienung benutzen oder nano oder noch irgendein editor-Zwerg.
Aber vim gehört da schon lange nicht mehr zu. Die sind auf dem besten Wege, sich zur Unkenntlichkeit aufzublähen. Wobei - schade drum wäre es nicht. Eine Bedienung wie in der Steinzeit. Da kann man ja gleich ed+grep+sed+cat+echo benutzen und wahrscheinlich sogar noch flotter ...
Naja, ich weiss ja nicht. VIM ist mir noch nie abgeschmiert. Noch stabiler geht wohl nicht.
Aber um ein wenig mitzutrollen. Als ich meine ersten tapsigen Versuche auf *nix basiernden Systemen machte, habe ich meinen damaligen Lehrmeister gefragt ob _DAS_ denn wirklich sein muss. Er sagte: "Ja, am besten Du gewoehnst Dich gleich von Anfang an dran. Ausserdem gibts bei mir nix anderes." Nun ja, ich muss sagen, der Anfang war leichter als ich im ersten Moment dachte. Und seit dem schaetze ich den vi. Und es ist nun mal so, in heterogenen Landschaften die ich betreue ist es der kleinste gemeinsame Nenner. Ohne ihn waere ich darauf angewiesen *x Editoren zu lernen. Nun brauche ich nur einen zu beherrschen, das aber richtig. Und, ich habe es nie bereut. Dank an alle Entwickler, die den guten alten 'vi' in Form von 'vim' nicht einschlafen lassen!
[..] die Unterstützung von Vim-Script, ähnlich Python, in Listen und Wörterbüchern dar [..]
Irgendwie ergibt das IMHO keinen Sinn. Sollte das nicht eher "die Unterstützung von Listen und Wörterbüchern, ähnlich Python, in Vim-Script dar" heissen? Und abgesehen davon, Arrays und Hashs gibt es auch in anderen Sprachen. Oder bezieht sich das auf Slicing?
Nachdem jetzt hier schon so viel geschrieben wurde, wie mächtig und schnell vim und (X)emacs doch sind würde ich doch jetzt gerne konkreteres erfahren. Also, was konkret macht die Mächtigkeit der beiden aus? Was genau macht die Arbeit mit den beiden effizienter als mit z.B. Kate? Wiso sollte ich auctex und nicht Kile verwenden? Was macht die beiden besser als KDevelop oder Eclipse? Ich weiß selbst, dass KDevelop eine IDE ist und vim / emacs nur editoren, aber alle haben die gleiche Zielgruppe: Softwareentwickler. Wenn ich für größere Projekte mit >20 Dateien, an denen mehr als 2 Mann arbeiten ne IDE nehmen soll, für wen sind denn dann vim und emacs so mächtig? Nur um Config-Dateien zu editieren? Was ist eigentlich aus dem guten altem UNIX Prinzip "eine Software für jede Aufgabe" geworden? Warum lassen sich also vim oder emacs nicht in KDevelop einbetten? Ich will jetzt hier kein blabla wie oben höhren, von wegen mächtiger, schneller, individuell anpassbar über LISP, etc., sondern ganz konkret mal ein paar Beispiele wie emacs oder vim euer Leben erleichtert. Ach übrigens, Syntax Highlighting und Code Completion können heutzutage fast alle, das zählt also nicht. Nachdem sich ja oben so viele Experten zu Wort gemeldet und sich über Stifflers Beitrag empört haben freue ich mich jetzt auf viele interesante Beiträge. Gruß, Thomas
Vieles was VI(M) und EMACS ausmacht ist - meiner bescheidenen Meinung nach - "Geek-Propaganda". Mittlerweile gibt es Editore die ebenfalls vollständig per Tastatur bedienbar sind (ob die die Kombination aus Tastatur + Maus nicht vielleicht doch unterm Strich produktiver ist? va wenn man die Maus bei weniggenützten und daher nicht geläufigen Kommandos zusätzlich einsetzen kann?), gleichen Funktionsumfang bieten, aber dabei leichter zu erlernen sind.
Auch die Meinung, daß man mit modernen IDEs nicht an die Produktivität von manchem VIM-Benutzer herankommt möchte ich stark anzweifeln. Oben wurde das Beispiel gebracht, daß man mit VIM besonders schnell zu Zeilen (per Zeilennummer) springen kann, wenn zB der Compiler/Interpreter die Fehlerzeile ausgibt. Ein Beispiel, das wohl nicht richtig durchdacht war, denn automatisch(!; ohne Eingabe der Zeilennummer) zur Fehlerzeile springen konnten schon die alten Borland-IDEs unter DOS Anfang der 90er Jahre.
Gruss Stiffler
irgendwie versteh ich das nicht. liegt aber sicher an sozialen defiziten auf seiten dieser trottel.
olli
Hat nur bedingt mit der Meldung zu tun, aber eine der beliebtesten vi(m)-Alternativen, der Editor "joe", ist in der Zwischenzeit auch nicht stehengeblieben, und bietet in den neuesten Versionen ebenfalls Syntax-Highlighting sowie endlich auch Mausbedienung (wohlgemerkt: im Textmodus)...
Im Unterschied zu vi (und vim) verwaltet joe eine Editor-Datei intern nicht als verkettete Liste von Zeilen, sondern als Buffer (sog. "Buffer-Gap"-Editor, wie auch bei Emacs), und kommt daher deutlich besser mit sehr großen und "binären" Daten klar. Die Tastenkürzel orientieren sich standardmäßig an Wordstar (Emacs- oder Pico-Tastenbelegung ist aber auch möglich), daher ist "joe" insbesondere bei Leuten beliebt, die in den 1990ern mit den "Turbo"-Programmiersprachen der Firma Borland aufgewachsen sind, und sich an die "Wordstar"-Tastenbelegung gewöhnt haben.
Im Unterschied zu vi/vim ist joe "mode-less", d.h. es gibt keine separaten "Modi" fürs Texteingeben und sonstige Operationen wie bei vi/vim; die meisten Funktionen sind über CTRL-Tastenkombinationen zu erreichen. Ausserdem unterstützt "joe" immerhin gesplittete Fenster (wie gesagt, im Textmodus), (Listen-)Completion und History bei der Auswahl von Dateinamen, inkrementelle Suche (im Emacs-Modus), eine Online-Hilfe für alle Tastenkürzel (mit ^K-H), Blockmarkierungen mit der Maus, Mausräder, neun über Tastenkürzel erreichbare "Lesezeichen" pro Datei, Autoindent und Klammersuche, Wort-Completion im Text, Regexp-Suche, einen Rechner mit Hex-Unterstützung, hat ausserdem tadellose Undo-Unterstützung, und noch ein paar weitere Kleinigkeiten.
Das kann "vim" zwar alles auch, aber als modus-orientiertem Editor besteht bei vi/vim immer die latente Gefahr, dass man aus Versehen (oder durch einen einzelnen Vertipper im Kommandomodus) z.B. ein paar Zeilen zu viel löscht. Dafür hat allerdings "vim" eine mächtige Programmiersprache; "joe" hat lediglich eine sehr rudimentäre Makrosprache, aber immerhin sind alle Tastenkürzel konfigurierbar.
Was ich bei "joe" vermisse, ist der "cw"-Befehl (Change Word), bei dem man ein Wort ersetzen kann, aber während der Eingabe noch das alte Wort stehen bleibt; wegen der grundsätzlich anderen Bedienlogik wäre dieses Verhalten bei "joe" aber nur schwer zu realisieren.
Für jemanden, der nicht mit "Turbo Pascal" o.ä. aufgewachsen ist, ist der einzige nennenswerte Vorteil von "joe" vermutlich, dass das Binary (im Unterschied zu "vim") noch recht klein geblieben ist; unter Debian z.B. hat "joe" ca. 330KiB und linkt gegen 7 Libraries, darunter die "libc", "vim" ist 1,5MiB gross und linkt gegen 69 (!) Libraries, u.a. die Libraries von Perl, Python, Tcl, Ruby, GTK+/GNOME; das "joe"-Binary würde man (statisch kompiliert) noch auf eine Diskette bekommen, bei "vim" ist das fraglich - oder zumindest würden dabei wohl die meisten "vim"-Features auf der Strecke bleiben. (Insofern ist "vim" definitiv kein "kleiner schneller" Editor mehr, auch wenn er natürlich immer noch schneller startet als Emacs.)
nur damit man sein Maul aufgemacht. Danke an alle, die an der Diskussion über vim, joe, emacs, slick usw. teilgenommen haben. Ich persönlich gehe jetzt in die Kneipe und zieh' mir die Diskussionen am Nachbartisch rein: "Baaaah, Opel ist viel besser als VW... nö, Ford macht alle platt... also mit meinem Skoda bin ich wohl am besten dran!".
Jetzt paßt mal auf. Vim ist ein Editor, den viele für gut befinden, also ist er es wert, weiterentwickelt zu werden.
Wenn ein Editor vie Vim so schlecht sein soll und schwierig zu bedienen, vorsintflutlich (wie der lustige "Stiffler" meint) und kaum, was schrieb der komische Andi, "moderner Softwareergonomie" genügt, WARUM WIRD ER DANN SO OFT RUNTERGELADEN, INSTALLIERT UND BENUTZT?
Kruzifix noch einmal, VIM hat aus guten Gründen eine große Anhängerschaft, ergo dieser Editor hat eine VOLLE DASEINSBERECHTIGUNG!!!
Warum hat VIM ein so große Anhängerschaft? Wohl aufgrund seiner typischen Eigenschaften (und weniger aus Nostalgiegründen würde ich sagen).
Das war mein Beitrag, schönen Tag noch,
mit freundlichen Grüßen
Tops
Dann hat es sich mit 'klein' - obwohl, das hat es sich ja schon, wenn man sich mal die riesigen source-Pakete anschaut.
Und mit dem orginalen, ach so kleinen vi hat es auch nicht mehr viel zu tun.
Wer es klein mag, kann ja jed mit vi-Bedienung benutzen oder nano oder noch irgendein editor-Zwerg.
Aber vim gehört da schon lange nicht mehr zu. Die sind auf dem besten Wege, sich zur Unkenntlichkeit aufzublähen. Wobei - schade drum wäre es nicht. Eine Bedienung wie in der Steinzeit. Da kann man ja gleich ed+grep+sed+cat+echo benutzen und wahrscheinlich sogar noch flotter ...
Aber um ein wenig mitzutrollen. Als ich meine ersten tapsigen Versuche auf *nix basiernden Systemen machte, habe ich meinen damaligen Lehrmeister gefragt ob _DAS_ denn wirklich sein muss. Er sagte: "Ja, am besten Du gewoehnst Dich gleich von Anfang an dran. Ausserdem gibts bei mir nix anderes." Nun ja, ich muss sagen, der Anfang war leichter als ich im ersten Moment dachte. Und seit dem schaetze ich den vi. Und es ist nun mal so, in heterogenen Landschaften die ich betreue ist es der kleinste gemeinsame Nenner. Ohne ihn waere ich darauf angewiesen *x Editoren zu lernen. Nun brauche ich nur einen zu beherrschen, das aber richtig. Und, ich habe es nie bereut. Dank an alle Entwickler, die den guten alten 'vi' in Form von 'vim' nicht einschlafen lassen!
Gruss, Ecaroh
Irgendwie ergibt das IMHO keinen Sinn. Sollte das nicht eher "die Unterstützung von Listen und Wörterbüchern, ähnlich Python, in Vim-Script dar" heissen? Und abgesehen davon, Arrays und Hashs gibt es auch in anderen Sprachen. Oder bezieht sich das auf Slicing?
Ich will jetzt hier kein blabla wie oben höhren, von wegen mächtiger, schneller, individuell anpassbar über LISP, etc., sondern ganz konkret mal ein paar Beispiele wie emacs oder vim euer Leben erleichtert. Ach übrigens, Syntax Highlighting und Code Completion können heutzutage fast alle, das zählt also nicht. Nachdem sich ja oben so viele Experten zu Wort gemeldet und sich über Stifflers Beitrag empört haben freue ich mich jetzt auf viele interesante Beiträge.
Gruß, Thomas
Auch die Meinung, daß man mit modernen IDEs nicht an die Produktivität von manchem VIM-Benutzer herankommt möchte ich stark anzweifeln. Oben wurde das Beispiel gebracht, daß man mit VIM besonders schnell zu Zeilen (per Zeilennummer) springen kann, wenn zB der Compiler/Interpreter die Fehlerzeile ausgibt. Ein Beispiel, das wohl nicht richtig durchdacht war, denn automatisch(!; ohne Eingabe der Zeilennummer) zur Fehlerzeile springen konnten schon die alten Borland-IDEs unter DOS Anfang der 90er Jahre.