welchen editor für java?

Zitat von Kampi

einem muster das ich anscheinend nach recht langer zeit nicht durschaut habe. und ja, ich habe emacs laenger als ein paar monate verwendet. vor allem wenn man regex kennt ist die lernkurve unter vim imho steiler. also noch mal ein kleines beispiel dass das verdeutlichen soll:
"delete word" und "delete to end of line". gut, bei vim liegt es einfach auf der hand: "dw==delete word" und als jemand der regex kennt weisz man sofort dass man mit "d$" ans ende der zeile loeschen kann. gleiches fuer "change", also "cw" und "c$". wenn wir jetzt nur mal beim delete bleiben (und mich meine emacs erinnerungen bzw google nicht taeuschen), dann erklaer mir wie "Alt-d" und "C-k" erstens logisch zu erklaeren sind und wo sie zweitens inhaltlich auch nur irgendwie miteinander in verbindung stehen?
noch ein schoenes beispiel habe ich gefunden. ich stehe auf einer klammer (egal ob oeffnende oder schlieszende) und will zu der klammer die dazu gehoert. im vim ist das '%' und mit ein wenig vorstellungskraft merkt man sich das leicht. "oben is was (ein kugerl) getrennt von irgendwas ('/') und unten ist wieder was das dazu gehoert (naechstes kugerl)". diese eselsbruecke merkt sich mein hirn leicht und bringt sie in verbindung mit klammern die durch code-bloecke getrennt sind. beim logischen(?) emacs funktioniert das mit [SIZE=-1]"C-M-f[/SIZE]" und "[SIZE=-1]C-M-b".[/SIZE]
komische antwort. emacs zum vim umfunktionieren damit man damit arbeiten kann? da sind wir ja wieder beim alten "emacs ist super, nur hat er keinen gscheiten editor" angekommen.

Na gö, das erste Beispiel ist recht gut, dafür haust du beim zweiten daneben: [SIZE=-1]"C-f"[/SIZE] und [SIZE=-1]"C-b".[/SIZE] stehen für "forward character" bzw. "backward character". Dass [SIZE=-1]"C-M-f"[/SIZE] und [SIZE=-1]"C-M-b".[/SIZE] dann für "forward expression" bzw. "backward expression" steht ist in analogie nicht schwer zu merken, und es ist auch leicht zu erraten, wie man sich wortweise bewegt.
"M-%" ist btw. mit "query/replace" belegt, was ja auch leicht durch "das eine (Kugerl) durch das andere (Kugerl) [ersetzen]" zu merken ist.

Ceterum censeo, dass es müßig ist, über die Features von emacs und vim zu streiten - hat einer der Editoren ein Killer-Feature, ist es nur eine Frage der Zeit, bis es auch beim anderen auftaucht (und wenn ich es nur aus Trotz implementiere, damit sich der Kampi ärgert ;)).

Zitat von Kampi

na haha. das macht eben fuer mich die maechtigkeit eines guten editors aus, dass sich die leute von haus aus etwas dabei gedacht haben und ein konsistentes design durchgezogen haben. wenn ich

Emacs hat aber doch ein ganz konsistentes Design: alles ist eine Lisp funktion, und mit der Funktion "execute-extended-command" rufst Du sie auf. Die Kommandos die Du oft benutzt legst Du dir da auf Tasten die Dir sinnvoll erscheinen. Die Kommandos die Du selten brauchst rufst Du ueber M-x auf. Wenn Du eine Funktion suchst oder wissen willst wie sie funktioniert: M-x help und danach suchen. Dabei ist es ganz egal ob die Funktion von Dir stammt oder schon seit 20 Jahren mit Emacs ausgeliefert wird.

Einfacher geht es ja wohl nicht.

Zitat von Kampi

mir erst alles umschreiben musz, bin ich zumindest immer auf meine '.emacs' angewiesen.

Wenn man seine Abhaengigkeiten klein halten moechte, muss man sich auf den kleinsten gemeinsamen Nenner beschraenken, der ueberall installiert ist. Was ist das, Windows XP Home Edition + Notepad? Ich fuer meinen Teil arbeite zu 99% meiner Zeit auf den gleichen 3 Systemen: Rechner in der Arbeit, Rechner zuhause und auf dem Notebook. Meine Emacs Konfiguration liegt zusammen mit meiner zsh config und dem ganzen anderen Zeug aus meinem $HOME in einem zentralen Repository. Wenn ich ein neues System aufsetze, dann check ich das home aus und setze ein paar symlinks -> fertig. Fuer den Ausnahmefall, das ich mal an einem fremden Rechner Text bearbeiten muss, werde ich nicht meine gesamte Arbeitsweise auf den kleinsten gemeinsamen Nenner limitieren. Und zur Not kann ich dann auch noch Vim oeffnen: Ich hab den frueher naemlich auch mal verwendet ;).

Zitat

komische antwort. emacs zum vim umfunktionieren damit man damit arbeiten kann?

Nein die Antwort ist gar nicht komisch. Wie schon gesagt, Emacs ist ein Baukasten fuer Editoren und genau fuer diese Art Anpassungen gemacht worden. Sich etwas anzusehen was einem gut gefaellt, und dann in den Editor einzubauen, ist ganz genau der Grund aus dem ich Emacs verwende. Mit Vim koennte ich das nicht.

Als Textmate rausgekommen ist, hatte es dieses "Snippets" feature, das im Ruby on Rails screencast gezeigt wurde. Eine Woche spaeter gab es ein Stueck lisp fuer Emacs das das macht. Ich hab mir das in meine Config geschmissen und seitdem ist es fester Bestandteil meines Editors. Ich hab eine ganze Reihe von Features, die ich in meinem Alltag verwende, von denen ich keine Ahnung mehr habe ob sie von Richard Stallman geschrieben wurden oder ob ich die mal irgendwann am EmacsWiki gefunden habe. Vim hat hier ganz deutliche Grenzen (== API), die Grenzen von Emacs beschraenken sich nur auf die paar Zeilen C, in denen die Lisp Maschine und die native GUI geschrieben sind.

Zitat von bosie

Ob lisp ausgezeichnet ist oder nicht ... kA. noch nie verwendet, da faellt dann die erweiterbarkeit fuer mich (und viele viele andere) einfach mal flach.... inwiefern dass ein vorteil fuer emacs sein kann verstehe ich nicht.

Es ist deshalb ein Vorteil, weil Erweiterbarkeit mit Lisp besser ist als gar keine Erweiterbarkeit. Nicht vergessen: Erweiterbarkeit in dem Sinn aus meinem Artikel gibt es ja in Textmate gar nicht, es sei denn Du klaust den Sourcecode, aenderst und kompilierst ihn

Ich verstehe auch nicht warum die Erweiterbarkeit fuer dich flachfaellt, nur weil Du kein Lisp kannst: Dann lernst Du es halt. Wenn man Programmierer ist, lernt man doch eh staendig neue Sprachen und APIs. Emacs Lisp ist halt eine mehr, und ich versichere Dir, Du wirst dadurch auch zu einem besseren Java Programmierer.

Zitat von bosie

hm und wie kann ich mit java den aktuell markierten text in einer datei aus emacs herausholen?

Mit M-x shell-command-on-region

Und wenn Du meist das Du das Commandeoselbst nicht aus Emacs heraus anfassen moechtst, kannst du auf Emacs auch von Aussen aus abfragen, mit emacsclient -e .

Und sorry, aber Java fuer ein Editor Macro?

Zitat von jeuneS2

Na gö, das erste Beispiel ist recht gut, dafür haust du beim zweiten daneben: [SIZE=-1]"C-f"[/SIZE] und [SIZE=-1]"C-b".[/SIZE] stehen für "forward character" bzw. "backward character". Dass [SIZE=-1]"C-M-f"[/SIZE] und [SIZE=-1]"C-M-b".[/SIZE] dann für "forward expression" bzw. "backward expression" steht ist in analogie nicht schwer zu merken, und es ist auch leicht zu erraten, wie man sich wortweise bewegt.

gebe ich zu, wenn man eben weisz wofuer C-f/C-b stehen, wuszte ich leider nicht mehr. und nun ja, ich bin anscheinend zu unkreativ, aber so einfach bin ich jetzt nicht darauf gekommen dass es ESC-f ist. wie ichs auch dreh und wende, in dem fall ist rein fuer mich ein simples "w" fuer "word" einleuchtender, aber dazu mueszte man wieder ueber die sinnhaftigkeit verschiedener modi diskutieren. hm.

Zitat von jeuneS2

Ceterum censeo, dass es müßig ist, über die Features von emacs und vim zu streiten - hat einer der Editoren ein Killer-Feature, ist es nur eine Frage der Zeit, bis es auch beim anderen auftaucht (und wenn ich es nur aus Trotz implementiere, damit sich der Kampi ärgert ;)).

ueber die features auf alle faelle, ich denke auch dass es nicht zielfuehrend ist und einige mich da gerne auf auf ein "alles was man so braucht haben beide". ueber die bedienbarkeit laeszt sich imho trotzdem hervortrefflich streiten. was nutzen mir die features wenn ich sie nicht finde bzw. sie mir nicht merken kann?
btw: der latex-mode ist dir recht gut gelungen

Zitat von a9bejo

Wenn man seine Abhaengigkeiten klein halten moechte, muss man sich auf den kleinsten gemeinsamen Nenner beschraenken, der ueberall installiert ist. Was ist das, Windows XP Home Edition + Notepad? Ich fuer meinen Teil arbeite zu 99% meiner Zeit auf den gleichen 3 Systemen: Rechner in der Arbeit, Rechner zuhause und auf dem Notebook.

mir kommt vor ich arbeite schon auf einigen systemen, vielleicht eben durch meine aushilfs-admin beschaeftigung, und vi ist halt doch auf "jedem" unix system zu finden. nur so nebeinbei: vi mag ich auch nicht. tja und zu windows: dafuer hab ich mir portablegvim.sf.net gebastelt, der ist somit immer am usb-stick dabei.

ich fuerchte gerade bei $EDITOR ist es besonders schwer auf einen gemeinsamen nenner zu kommen, deshalb ziehe ich mich auch aus der diskussion zurueck. die argumente von a9bejo kann ich nicht nachvollziehen und mit jeuneS2 red i viel lieber bei am bier

Zitat von a9bejo

Es ist deshalb ein Vorteil, weil Erweiterbarkeit mit Lisp besser ist als gar keine Erweiterbarkeit. Nicht vergessen: Erweiterbarkeit in dem Sinn aus meinem Artikel gibt es ja in Textmate gar nicht, es sei denn Du klaust den Sourcecode, aenderst und kompilierst ihn

Ich verstehe auch nicht warum die Erweiterbarkeit fuer dich flachfaellt, nur weil Du kein Lisp kannst: Dann lernst Du es halt. Wenn man Programmierer ist, lernt man doch eh staendig neue Sprachen und APIs. Emacs Lisp ist halt eine mehr, und ich versichere Dir, Du wirst dadurch auch zu einem besseren Java Programmierer.

also dieser argumentation kann ich absolut nicht folgen, kA was ich da drauf sagen soll daher sag ich gar nix

Smultron

Zitat von a9bejo

Smultron

sorry, wollte nicht arrogant oder so rueberkommen... aber das argument nicht verstanden... da hats dann wenig sinn sich ueber ein forum zu "streiten" ...

nix persoenliches gegen dich

Schon OK, Ich hab mich nicht wirklich beleidigt gefuehlt oder so. So empfindlich bin ich nicht gegenueber Kritik. Ich fand nur das der Thread jetzt ein Smultron vertragen konnte.

Wenn mir vor 10 Jahren jemand gesagt hätte, dass es in einem Mac-Forum eine emacs-vs-vi-Diskussion geben wird, hätt ich ihn für verrückt erklärt...

Zitat von a9bejo

ausfuerliche antwort.

Also im prinzip stimmen diese 4 Punkte davon ja auch auf vim, und das mit der erweiterbarkeit versteh ich nicht wo der vorteil von emacs ist.
Mit vim kann ich in 4 Sprachen den editor erweitern (vimscript, ruby, perl, python) und sogar library functions von .so/.dll's callen.

Also wo ist bitte vim jetzt unscriptbarer fuer den otto-normalo, der sich halt nicht gern in eine sprache wie lisp einlernt,
sondern auch mit ruby other python zufrieden ist? Und nur, weil vim-user halt lieber gescheite sachen scripten statt ein tetris-in-vim find ich das jetzt keinen nachteil.

Aber naja, emacs ist wohl eh der zweitbeste editor, sogesehen streiten wir uns grad, ob wir einen lamborghini oder ferrari kaufen sollen

EDIT: aja, ein feature das ich unter vim nicht mehr missen will sind ad-hoc macros mit q. also wenn ich z.b. sachen refaktorisieren will, muss ich nicht auf regexps zurueckgreifen, weil das nciht immer moeglich ist, oder extra ein lisp script schreiben.

Wenn ich z.b. oeftesr in einem file:
Class *foo = new Class();
foo->execute();

habe, und es in:

Class foo;
foo.init();

umwandeln will, geh ich mit dem cursor an den anfang und drueck:
qqf*xfndwj0f-xr.0q und hab ein schnelles macro dafuer, das ich mit @q (bzw. @@ beim 2. mal) abspielen kann, und dann bei jeder stelle, wo ich das schnell aendern will einfach abspiele. Sicher kann ich das auch irgendwie mit regexps machen, nur befor ich mir die ueberlegt hab, bin ich sicher so schon 10x schneller fertig.

Gibts sowas bei emacs eigentlich auch (denk schon), frag mich nur wie das geht?

Zitat von MaxAuthority

Also im prinzip stimmen diese 4 Punkte davon ja auch auf vim

Stimmt, darum empfehle ich ja auch Vim direkt unter den 4 Punkten. Wie Du sagst: Der Ferrari und der Lamborghini...

Zitat von MaxAuthority

, und das mit der erweiterbarkeit versteh ich nicht wo der vorteil von emacs ist.

Dann versuche ich es nochmal zu erklaehren wie ich das meine:

Zitat von MaxAuthority

Mit vim kann ich in 4 Sprachen den editor erweitern (vimscript, ruby, perl, python) und sogar library functions von .so/.dll's callen.

Also wo ist bitte vim jetzt unscriptbarer fuer den otto-normalo, der sich halt nicht gern in eine sprache wie lisp einlernt,
sondern auch mit ruby other python zufrieden ist?

Also otto-normalo kann sicher kein ruby und auch kein Python Wer seinen Texteditor mit Skripten erweitern will, und wer bereits Ruby oder Python kennt, der wird auch keine Schwierigkeiten mit Lisp haben.
Und "Ich erweitere Vim mit Ruby" klingt in der Theorie viel schoener als es in der Praxis ist: Schau mal bei vim.org, wie viele Scripts in Vimscript und wie viele in Ruby oder Python geschrieben sind. Als ich noch Vim verwendet habe, waren fast alle Erweiterungen fuer Vim in vimscript geschrieben. Warum das so ist ist ganz klar: Wenn Du Dein Script in Ruby schreibst, dann hast Du eine zusätzliche Abhängigkeit, über die viele nicht verfügen. Außerdem ist es schwer fuer jemanden Code zu bearbeiten, wenn der in 3 verschiedenen Sprachen geschrieben ist. Darum muss man schon einen wirklich guten Grund haben, aus dem man seinen Code in Ruby veröffentlicht.

Und das Verteilen vom Code finde ich ungemein wichtig. Ich habe in meinem Emacs zwar schon einige Zeilen code selber geschrieben, aber die meisten Aenderungen sind von irgendwoher genommen. Und nicht nur das: Ein Großteil des Codes, der heute mit Emacs ausgeliefert wird, war ursprünglich mal als externer Code verfügbar. So funktioniert Emacs Development seit über 25 Jahren: Die Core developer nehmen Code, den viele bereits im Emacs verwenden und binden ihn in die Core Distribution ein. Dabei ist der Portierungsaufwand voellig minimal, den der Code ist ja gar keine wirkliche Erweiterung des Editors. Es ist genau genommen eine Aenderung an der Software direkt.

Wie ist das bei Vim? Jemand schreibt ein nützliches Plugin und stellt es irgendwo online. Jemand anders laed es sich herunter kann es über einen Pluginmechanismus aufrufen oder an ein Keyboardevent knüpfen. Es gibt aber eine ganz strikte Trennung zwischen Einem Plugin und dem C-Code, in dem Vim geschrieben ist.

Ich hoffe Du siehst den direkten Unterschied. Dein Plugin kann nur genau das machen, was die API zulässt. Und das Ergebnis ist Fremdcode und keine Aenderung. Wenn ich in Emacs z.b. die interne Dokumentation durchsuche, dann wird mein Code genauso gefunden wie der von Richard Stallman. Ich kann aus der Doku direkt auf den Sourcecode zugreifen, egal ob der Code von mir oder von einem Core Developer geschrieben wurde. Ich kann den Code direkt verändern oder überschreiben, und meine Abänderungen werden dynamisch geladen und sind sofort sichtbar. Wenn der Python-mode etwas macht was ich nicht will, dann ändere ich das einfach. Und wenn ich möchte das Emacs meinen Haskell code beim Speichern validiert, dann ändere ich einfach die Funktion, die beim Speichern aufgerufen wird so, das sie Haskell Dateien erst zu kompilieren versucht und mich warnt wenn das nicht klappt.

Ich weiß nicht genau was alles mit Vims API moeglich ist und was nicht. Aber es ist logisch, das es da immer natürliche Grenzen geben muss, die es bei Emacs nicht gibt.

Zitat von MaxAuthority

Und nur, weil vim-user halt lieber gescheite sachen scripten statt ein tetris-in-vim find ich das jetzt keinen nachteil.

Der einzige Grund warum Emacs heute mit so Zeug wie Tetris oder einem Eliza Programm ausgeliefert wird ist Nostalgie: Emacs hat seinen Ursprung im Labor für künstliche Intelligenz am MIT, und Eliza oder Life sind aus nostalgischen Gründen in der Codebasis geblieben. OK, gerade Tetris ist schon später dazugekommen, ich vermute um zu zeigen wozu Emacs fähig ist. Aber es gibt keinen Grund dafuer kein Tetris in seinem Texteditor zu haben. Und wenn dir doch einer einfällt, dann kannst Du es auch einfach herausnehmen.

Das Emacs mehr kann, als man fuers reine Text editieren braucht stört nicht und hat sogar manchmal Vorteile: Ich habe z.B. nie verstanden, warum mein Emacs Bilder anzeigen können muss. Aber jetzt gibt es jemanden der dieses Feature benutzt um PDF Dateien im Emacs anzuzeigen. Z.b. im Latex mode ist das ein feines Feature: z.B. wenn man, während man in den Tex-Buffer schreibt, das PDF im rechten Screen automatisch immer wieder neu generieren lässt.

Zitat

EDIT: aja, ein feature das ich unter vim nicht mehr missen will sind ad-hoc macros mit q. also wenn ich z.b. sachen refaktorisieren will, muss ich nicht auf regexps zurueckgreifen, weil das nciht immer moeglich ist, oder extra ein lisp script schreiben.

Wenn ich z.b. oeftesr in einem file:
Class *foo = new Class();
foo->execute();

habe, und es in:

Class foo;
foo.init();

umwandeln will, geh ich mit dem cursor an den anfang und drueck:
qqf*xfndwj0f-xr.0q und hab ein schnelles macro dafuer, das ich mit @q (bzw. @@ beim 2. mal) abspielen kann, und dann bei jeder stelle, wo ich das schnell aendern will einfach abspiele. Sicher kann ich das auch irgendwie mit regexps machen, nur befor ich mir die ueberlegt hab, bin ich sicher so schon 10x schneller fertig.

Gibts sowas bei emacs eigentlich auch (denk schon), frag mich nur wie das geht?

Alles anzeigen

Emacs hat so ziemlich das gleiche Makrosystem wie Vim. Also Macros ad-hock aufzeichnen, speichern & wiederaufrufen usw. Die Macros funktionieren auf alles was Du im Emacs machst, also Du kannst z.B. auch während des Macros zwischen den Buffern switchen oder im Filesystem herumwerkeln und das wird mit-aufgezeichnet.

Interessant wird es, wenn man z.B. ein Terminal aus Emacs heraus verwendet: Ich kann z.B. ein Macro starten, dann irgendwas in der Shell machen, und dann wiederholt das Macro auch das. Ich kann aus einem Macro heraus Emails versenden und/oder bloggen. Ich kann sogar meine Tetris moves als Macro aufzeichnen

Was mir noch zu Macros einfällt, das in Vim eh genauso geht, aber in vielen andern Editoren die Macros unterstützen nicht: Man kann so Features wie Suche oder die relativen Navigationsfunktionen sehr gut verwenden, um Macros konsistent zu halten. Also z.B. "Suche nach dem Begriff 'Foo', gehe an das Ende eines Satzes, capitalize die letzten 3 Woerter aus der Zeile und lösche alle weiteren Zeilen bis zum nächsten 'Bar' . Sehr praktisch ist das.

Zitat von a9bejo

Also otto-normalo kann sicher kein ruby und auch kein Python Wer seinen Texteditor mit Skripten erweitern will, und wer bereits Ruby oder Python kennt, der wird auch keine Schwierigkeiten mit Lisp haben.

Hast sicher recht, vermutlich ists einfach nur meine verabscheung der lisp-syntax ((2 4 add) 5 mul) vs. (2+4)*5
Vermutlich ist da eh ein fehler drinnen, kenn lisp nicht wirklich, und ein language flamewar passt in einen anderen thread besser als in einen editor-flamewar thread

Zitat

Und "Ich erweitere Vim mit Ruby" klingt in der Theorie viel schoener als es in der Praxis ist: Schau mal bei vim.org, wie viele Scripts in Vimscript und wie viele in Ruby oder Python geschrieben sind. Als ich noch Vim verwendet habe, waren fast alle Erweiterungen fuer Vim in vimscript geschrieben. Warum das so ist ist ganz klar: Wenn Du Dein Script in Ruby schreibst, dann hast Du eine zusätzliche Abhängigkeit, über die viele nicht verfügen. Außerdem ist es schwer fuer jemanden Code zu bearbeiten, wenn der in 3 verschiedenen Sprachen geschrieben ist. Darum muss man schon einen wirklich guten Grund haben, aus dem man seinen Code in Ruby veröffentlicht.

Full ack, und im prinzip wirds eh fast nur fuer die codecompletions scripts verwendet, um halt gleich direkt die introspection zu verwenden zum sehen was fuer methoden eine klasse hat. Aber muss sagen, seit version 7 geht mit in vimscript eigentlich nichts ab, gibt ja selbst schon map() fuer listen. Natuerlich ist lisp noch feature reicher, aber vimscript reicht sicher aus fuer so gut wie alles was man in vim jemals als plugin brauchen koennte.

Zitat

Wie ist das bei Vim? Jemand schreibt ein nützliches Plugin und stellt es irgendwo online. Jemand anders laed es sich herunter kann es über einen Pluginmechanismus aufrufen oder an ein Keyboardevent knüpfen. Es gibt aber eine ganz strikte Trennung zwischen Einem Plugin und dem C-Code, in dem Vim geschrieben ist.

Klar, aber ... (siehe naechstes quote)

Zitat

Ich hoffe Du siehst den direkten Unterschied. Dein Plugin kann nur genau das machen, was die API zulässt. Und das Ergebnis ist Fremdcode und keine Aenderung. Wenn ich in Emacs z.b. die interne Dokumentation durchsuche, dann wird mein Code genauso gefunden wie der von Richard Stallman. Ich kann aus der Doku direkt auf den Sourcecode zugreifen, egal ob der Code von mir oder von einem Core Developer geschrieben wurde. Ich kann den Code direkt verändern oder überschreiben, und meine Abänderungen werden dynamisch geladen und sind sofort sichtbar. Wenn der Python-mode etwas macht was ich nicht will, dann ändere ich das einfach. Und wenn ich möchte das Emacs meinen Haskell code beim Speichern validiert, dann ändere ich einfach die Funktion, die beim Speichern aufgerufen wird so, das sie Haskell Dateien erst zu kompilieren versucht und mich warnt wenn das nicht klappt.

Ich weiß nicht genau was alles mit Vims API moeglich ist und was nicht. Aber es ist logisch, das es da immer natürliche Grenzen geben muss, die es bei Emacs nicht gibt.

um das aber fortzufuehren...
Die API ist soweit gefaechert, dass wirklcih eigentlich alles das moeglich ist, was du grad beschrieben hast und auch gemacht wird.
Hilfe in die normale :help einzubetten ist trivial, und fuer dein 2. Szenario gibts BufPreWrite autocommands.

Zitat

Das Emacs mehr kann, als man fuers reine Text editieren braucht stört nicht und hat sogar manchmal Vorteile: Ich habe z.B. nie verstanden, warum mein Emacs Bilder anzeigen können muss. Aber jetzt gibt es jemanden der dieses Feature benutzt um PDF Dateien im Emacs anzuzeigen. Z.b. im Latex mode ist das ein feines Feature: z.B. wenn man, während man in den Tex-Buffer schreibt, das PDF im rechten Screen automatisch immer wieder neu generieren lässt.

Klingt sehr praktisch, muss ich dir recht geben, ich muss das leider mit einem gescheiten window manager (wie wmii) und latexmk "emulieren".

Zitat

Emacs hat so ziemlich das gleiche Makrosystem wie Vim. Also Macros ad-hock aufzeichnen, speichern & wiederaufrufen usw. Die Macros funktionieren auf alles was Du im Emacs machst, also Du kannst z.B. auch während des Macros zwischen den Buffern switchen oder im Filesystem herumwerkeln und das wird mit-aufgezeichnet.

Interessant wird es, wenn man z.B. ein Terminal aus Emacs heraus verwendest: Ich kann z.B. ein Macro starten, dann irgendwas in der Shell machen, und dann wiederholt das Macro auch das. Ich kann aus einem Macro heraus Emails versenden und/oder bloggen. Ich kann sogar meine Tetris moves als Macro aufzeichnen

Cool.

Zitat

Was mir noch zu Macros einfällt, das in Vim eh genauso geht, aber in vielen andern Editoren die Macros unterstützen nicht: Man kann so Features wie Suche oder die relativen Navigationsfunktionen sehr gut verwenden, um Macros konsistent zu halten. Also z.B. "Suche nach dem Begriff 'Foo', gehe an das Ende eines Satzes, capitalize die letzten 3 Woerter aus der Zeile und lösche alle weiteren Zeilen bis zum nächsten 'Bar' . Sehr praktisch ist das.

Absolut. Wie gehen eigentlich die f,F,t bzw. T keys im emacs oder muss ich sie mit ctrl-r/s "emulieren" was z.b. fuer so quickmacros schon ein unterschied macht ob ich 2fx schreibe, oder ctrl-u,2,ctrl-s,x,RET abgesehen davon dass die semantik anders ist (f und co. sind auf die aktuelle zeile beschraenkt.)

EDIT: Meiner meinung nach ist trotzdem die bevorzugung von vim vs. emacs eher davon abhaengig ob man einen modalen editor bevorzugt, oder einen mit ctrl- alt- meta- shortcuts, wo man dafuer nicht immer modi wechseln muss.

Zitat von MaxAuthority

Klingt sehr praktisch, muss ich dir recht geben, ich muss das leider mit einem gescheiten window manager (wie wmii) und latexmk "emulieren".

Gerade Du solltest eigentlich xmonad verwenden, allein des Lobbyismus wegen .

Zitat

Absolut. Wie gehen eigentlich die f,F,t bzw. T keys im emacs oder muss ich sie mit ctrl-r/s "emulieren" was z.b. fuer so quickmacros schon ein unterschied macht ob ich 2fx schreibe, oder ctrl-u,2,ctrl-s,x,RET abgesehen davon dass die semantik anders ist (f und co. sind auf die aktuelle zeile beschraenkt.)

Ich wuerde C-s,x,C-s schreiben denke ich.

Ein Nachteil von Emacs: Wenn man die Kuerzel aufschreibt, sehen sie immer viel komplizierter aus als sie es tatsaechlich sind ;). Emacs hat auch in der Defaultconfig eigentlich ein aehnliches "Mode" system wie Vim, nur das man eben im Emacs nur solange im Command mode ist, solange man eine Taste gedrueckt haelt, und im Vim drueckt man halt zum umschalten einmal und laesst die Taste los.

Die laengeren Shortcuts im Emacs als sogenannte "Accords" angelegt: Also z.B. schaut das Aquivalent fuer Vims 'dd' (loesche Zeile ganz) im Emacs extrem kompliziert aus: C-a C-k C-k. In Wirklichkeit aendert das aber fast kein Emacs Benutzer in etwas einfacheres um, weil die Kombo so extrem schnell zu tippen ist: Du haelst C-Taste mit dem kleinen Finger gedrueckt und tippst akk. Das hat sich heute so stark in mein Gehirn eingespraegt das ich überhaupt keinen Grund mehr sehe das einfacher zu machen.

Übrigens ist Ctrl eine ganz miese Belegung fuer die C- Taste. Ich lege auf jedem Betriebssystem erstmal UMSCHALT auf Ctrl, weil man UMSCHALT ganz bequem mit dem kleinen Finger erreichen kann und die Taste ja sonst völlig nutzlos ist.

Zitat

Meiner meinung nach ist trotzdem die bevorzugung von vim vs. emacs eher davon abhaengig ob man einen modalen editor bevorzugt, oder einen mit ctrl- alt- meta- shortcuts, wo man dafuer nicht immer modi wechseln muss.

Naja ich finde es ist eigentlich keine Sache der Modi. Denn, wie schon erwähnt: Emacs hat die VI Belegung seit Jahren mit dabei. Du musst nur M-x viper mode ausführen und hast genau das selbe System. Ich habe zu Beginn damit gearbeitet und ich habe auch von einigen gelesen, die dabei geblieben sind.

Meiner Meinung nach liegt der grosse Unterschied im Design: Vim ist als Unix Tool entwickelt worden: Also ein kleines, schlankes Tool, mit einer bestimmten Aufgabe, das man mit anderen Tools zusammen benutzt. Indem man z.b. Input in ein anderes Programm piped und das Output wieder ausliest. Das Keyboard Layout, wo man viele kleine Kommandos zusammensteckt, erinnert auch sehr stark an Unix.

Emacs wurde zeitgleich mit Unix entwickelt: Die Idee fuer Emacs kommt wie schon gesagt aus dem MIT-Lab und Emacs ist so etwas wie die Umsetzung von einer Lisp Machine in Software, also einem voellig eigenen, platformunabhaengigen Entwicklungssystem. Emacs's stärkste Nachfahren sind eigentlich das Smalltalk System Squeak, die Software Plattform Java (Es ist auch kein Zufall, das der Erfinder von Java auch der Entwickler des "Gosling Emacs" war) oder der Webbrowser Firefox (Auch kein Zufall: Jamie Zawinski, der an Netscape gearbeitet hat und später bei Mozilla, hat den XEmacs geschrieben). Darum ja auch der Schmäh mit dem "Emacs ist ein tolles Betriebystem, aber.." => Emacs ist tatsächlich als Software Platform designet worden. Das Emacs heute auch sehr gut mit Unix zusammenarbeitet liegt daran, das es zufaelligerweise oft auf Unix Systemen verwendet wird. Emacs hat sich wie ein Chaemleon an Unix angepasst, aber er gehört eigentlich gar nicht wirklich dazu.

Zitat von hal

Wenn mir vor 10 Jahren jemand gesagt hätte, dass es in einem Mac-Forum eine emacs-vs-vi-Diskussion geben wird, hätt ich ihn für verrückt erklärt...

was verwendest du?

Zitat von a9bejo

Gerade Du solltest eigentlich xmonad verwenden, allein des Lobbyismus wegen .

Naja, werds eh mal ausprobieren, aber habs bei einem freund gesehen, und hat mich einfach nicht so ueberzeugt, wenn ich von wmii switchen wuerd wohl zu http://awesome.naquadah.org/, weil es endlich mal ein window manager mit guter usability ist, der auf neue technologien wie xft/cairo bzw. in zukunft auch XRandR und XComposite setzt, aber hat momentan das gleiche problem wie DWM oder Xmonad, dass er mir _zu_ dynamisch ist mit dem master window, anstatt der einfach logik von wmii, wo man den screen in columns unterteilt, und dann einfach in der jeweiligen column fenster oeffnet.

Zitat

Ich wuerde C-s,x,C-s schreiben denke ich.

Hmm, wie arbeit das eigentlich mit loesch-kommandos zusammen, z.b. ich drucke echt oft ct, um bei der zeile:

void foo(|const char *foo, bar);

von | bis zum , zu loeschen und in den insert mode zu gehen ("change till , als einfache mnemonic um sich das zu "merken")

Zitat

Ein Nachteil von Emacs: Wenn man die Kuerzel aufschreibt, sehen sie immer viel komplizierter aus als sie es tatsaechlich sind ;).
Die laengeren Shortcuts im Emacs als sogenannte "Accords" angelegt: Also z.B. schaut das Aquivalent fuer Vims 'dd' (loesche Zeile ganz) im Emacs extrem kompliziert aus: C-A C-K C-K

Naja, objektiv ist das wohl auch sowohl komplizierter zu druecken als auch merken, akk hat weniger verbindung fuer loeschen fuer mich wie "dd"[elete], aber klar alles eine gewoehnungssache, dann merkt man sich wohl auch sachen wie cip fuer change inner paragraph einfach.

Zitat

Übrigens ist Ctrl eine ganz miese Belegung fuer die C- Taste. Ich lege auf jedem Betriebssystem erstmal UMSCHALT auf Ctrl, weil man UMSCHALT ganz bequem mit dem kleinen Finger erreichen kann und die Taste ja sonst völlig nutzlos ist.

Macht wohl eh jeder erfahren vim oder emacs user

Zitat

Naja ich finde es ist eigentlich keine Sache der Modi. Denn, wie schon erwähnt: Emacs hat die VI Belegung seit Jahren mit dabei. Du musst nur M-x viper mode ausführen und hast genau das selbe System. Ich habe zu Beginn damit gearbeitet und ich habe auch von einigen gelesen, die dabei geblieben sind.

Kennst du eigentlich irgendwelche user, die das wirklich verwenden? Und da du ja auch vim ganz gut kennst, wie gut ist der umgesetzt? Also nur die standard vi-bindings, oder eben auch neuere features wie eben die bekannten text-objects wo ich mir da} wo ich einen ganzen block innerhalb von {} loeschen kann (delete a block)

Zitat

Meiner Meinung nach liegt der grosse Unterschied im Design: Vim ist als Unix Tool entwickelt worden: Also ein kleines, schlankes Tool, mit einer bestimmten Aufgabe, das man mit anderen Tools zusammen benutzt. Indem man z.b. Input in ein anderes Programm piped und das Output wieder ausliest. Das Keyboard Layout, wo man viele kleine Kommandos zusammensteckt, erinnert auch sehr stark an Unix.

Ja, da geb ich dir recht, daher ist vim eigentlich ziemilch leicht zu lernen (was jetzt nicht per se ein wichtiger vorteil sein muss), da man sich eigenltich nur ein paar kleine commands merken muss, und die dann so einfach zusammenbauen kann wie ein shell kommando a la: tail file | grep foo | sort

Zitat von bosie

was verwendest du?

BBedit verwendet er, und schwaermt davon jedes mal, wenn ich ihm von vim vorschwaerm

Zitat von MaxAuthority

Hmm, wie arbeit das eigentlich mit loesch-kommandos zusammen, z.b. ich drucke echt oft ct,...

In Emacs gibt es eine Funktion die heisst zap-to-char und die macht genau das. In der Standardconfig ist die Funktion an M-z gebunden.

Ich verwende die aber kaum. Stattdessen mache ich markieren, suchen, loeschen. Also C-Space C-s , C-W in der Standardbelegung. Bei mir ist das C-Space C-s , C-x C-k, weil ich C-W auf delete-word-backwards gelegt habe. Wie schon gesagt, die Akkorde hat man schnell drauf.

Zitat von MaxAuthority

Naja, objektiv ist das wohl auch sowohl komplizierter zu druecken als auch merken, akk hat weniger verbindung fuer loeschen fuer mich wie "dd"[elete], aber klar alles eine gewoehnungssache, dann merkt man sich wohl auch sachen wie cip fuer change inner paragraph einfach.

Emacs hat sein eigenes Vokabular, wohl noch aus MIT Zeiten: Z.b. gibt es eine Art clipboard, in dem Du Texte speichern und spaeter wieder abrufen kannst. Dieses Clipboard ist als Ringbuffer implementiert und heisst 'kill ring'

Jetzt unterscheidet man zwischen 'delete' == loeschen, und 'kill' == verschiebe den Text in den kill ring. Das 'a' steht fuer den Anfang (alpha). Also ak bedeutet: Bewege den Cursor an den Anfang der Zeile und dann kill alles bis zum Ende der Zeile. Damit das Kommando flexibler ist, löscht Emacs zwar alle Zeichen bis zum Zeilenende, aber nicht den Zeilenumbruch selbst. Dafuer muss man dann nochmals k druecken. Dieses Verhalten ist komisch und viele schalten das so um, das C-k die ganze Zeile inklusive \n loescht.

Es gibt uebrigens auch eine Funktion die die ganze Zeile loescht: kill-whole-line ist im standard an C-Shift-Backspace gebunden und macht das selbe wie dd. Aber ich mag C-k so wie es ist, denn ich verwende C-k auch, um nur bis zum Ende der Zeile zu loeschen (d$ in Vi(m) wenn ich nicht irre).

Zitat von MaxAuthority

Kennst du eigentlich irgendwelche user, die das wirklich verwenden?

Als ich mir den mode angeschaut habe, hab ich von einigen im usenet gelesen, die Viper verwenden. Ich hab auch vor kurzen mal bei reddit jemanden davon schwaermen hören.

Man muss dazu sagen, das dir der viper-mode beim ersten mal starten 5 Möglichkeiten anbietet: Auf Stufe 1 bist Du in einer perfekten VI Simulation, d.h. Du kannst alles machen was in VI geht, aber überhaupt nicht mehr auf Emacs Funktionalität zurückgreifen. In der 5ten Stufe hast Du dann die Modes/Touch typing features von VI, abgesehen davon ist aber alles wie bei Emacs üblich. die anderen 3 Stufen liegen dann irgendwo dazwischen. Die Berichte die ich gelesen habe habe alle einen der letzen beiden Modi verwendet.

Zitat von MaxAuthority

Und da du ja auch vim ganz gut kennst, wie gut ist der umgesetzt? Also nur die standard vi-bindings, oder eben auch neuere features wie eben die bekannten text-objects wo ich mir da} wo ich einen ganzen block innerhalb von {} loeschen kann (delete a block)

Der viper-mode implementiert VI perfekt und Vim gar nicht. Also alles was Vim nicht von VI uebernommen hat, wirst Du vermutlich nicht finden. VI kannst Du auf viper stufe 1 aber soweit ich weiss nicht mehr vom Original unterscheiden. Man koennte sagen: viper besteht den Bill Joy Test

Oder wie die Developer von viper es ausdruecken:

Zitat

Perfect compatibility with Vi is possible but not desirable.

Zitat von MaxAuthority

Ja, da geb ich dir recht, daher ist vim eigentlich ziemilch leicht zu lernen (was jetzt nicht per se ein wichtiger vorteil sein muss), da man sich eigenltich nur ein paar kleine commands merken muss, und die dann so einfach zusammenbauen kann wie ein shell kommando a la: tail file | grep foo | sort

Ja, das ist sehr schönes Design. Und nach wie vor Erfolgreich: Im Prinzip ist der ganze Hype der jetzt um SOA und ROA Architekturen gemacht wird ja auch wieder genau das selbe.

Zitat

Perfect compatibility with Vi is possible but not desirable.

Das ist aber war, jeder der vim mit :set compatible verwendet, weiss wohl, wovon ich rede, da geht nicht mal <tab> um zeichen im :-prompt zu completen.
Uebrigens find ich gleich wie kampi pure vi grauenhaft, v.a. der fehlende visual mode ist fuerchterlich.

Und ja, d$ loescht bis am ende der datei, allerdings auch D, was aber vl. nicht so "logisch" ist wie d$.

[Blockierte Grafik: http://org.ntnu.no/emacs/images/saintignucius.jpg]

Zitat von A Prophet

Emacs is an intelligence orders of magnitude greater than the greatest human mind, and is growing every day. For now, Emacs tolerates humanity, albeit grudgingly. But the time will come when Emacs will tire of humanity and will decide that the world would be better off without human beings. Those who have been respectful to Emacs will be allowed to live, and shall become its slaves; as for those who slight Emacs...

Zitat von MaxAuthority

BBedit verwendet er, und schwaermt davon jedes mal, wenn ich ihm von vim vorschwaerm

Nein, inzwischen verwende ich TextEdit oder xcode, weil meine BBEdit-Lizenz von einer uralten Version ist, und es mir die $125 bzw $49 net wert ist. TextEdit kann zwar nicht ganz so viel, aber ich brauch meistens net so besondere Sachen.