vim oder vim-classic?

vim oder vim-classic?

  • vim

    Stimmen: 9 52,9%

  • vim-classic

    Stimmen: 2 11,8%

  • beides

    Stimmen: 0 0,0%

  • keines

    Stimmen: 6 35,3%
  • Umfrageteilnehmer
    17
erst zögerte ich, "meine Stimme zu erheben", also an der Abstimmung teil zu nehmen, denn ich bin kein IT-ler und schon gar kein Programmierer. Weil ich mit diesen Themen nichts am Hut habe, erschließt sich dann womöglich auch, dass ich keinen Bedarf an entsprechenden Werkzeugen habe, deren Handhabung ja auch erlernt sein will.

Mal einen Vergleich:
würde hier eine Abstimmung erfolgen, wer eine Stihl-Kettensäge benutzt und wer eine Husquarna, würde sich kaum jemand wundern, wenn ich dazu schweige, weil ich mich mit Kettensägen nicht auskenne.

In einem IT-Forum könnte nun aber die Neigung bestehen, die Welt irgendwie reduziert wahr zu nehmen. Wenn doch alle in meinem Umfeld täglich Kettensägen benutzen, dann muss doch jeder eine Meinung dazu haben.
Deshalb entschloss ich mich schließlich, meine Stimme ab zu geben und zu bekennen, dass ich keines der beiden Werkzeuge benutze und mich auch mit dem VI sehr schwer tue und diesen nur in der Not benutze, was auch für andere spezielle Werkzeuge aus der IT-Welt gilt.

Das Wenige, was ich zu tun habe, kann ich mit dem ee in FreeBSD erledigen und unter Grafik mit bunten Editoren, wie inzwischen kwrite (editors/kate) und zuvor bevorzugt geany (devel/geany).
 
Ich muss zugeben, ich bin mit diesen ganzen vi-artigen Editoren (inkl. vim) nie so ganz warm geworden. Obwohl ich zugeben muss, der vim hat was.
Ich würde mich eher in der emacs-Ecke verorten. ;-)
 
Ich äh nutz für alles kleine nano und äh alles größere vs code fürchte ich, ich bin weder mit vi und derivaten noch mit emacs jemals warm geworden, obwohl ich in 23 Jahren das wirklich oft intensiv versucht hab
 
Obwohl ich ein vi-Nutzer bin, was ist denn da der Unterschied? Das ist irgendwie an mir vorbei gegangen.
 
Ich habe Mitte der 90er mit Linux angefangen und damals ein Linux-Buch von O'Reilly gekauft und VI(M) war ein Kapitel vor Emacs und daher bin ich dann bei VI(M) haengen geblieben und habe das Emacs-Kapitel nie gelesen. Inzwischen verwende ich aber beides. ;-)
 
Das besondere an emacs ist halt, das das ein vollprogrammierbarer Editor ist. Das ist heute nix mehr besonderes, war es aber damals.
Und da war ja auch nicht die Grundidee, das man einen Editor macht und da irgendwie eine Makrosprache dran pappt.

Im Grunde eher umgekehrt: emacs ist eigentlich eine Runtime die ihre eigene Entwicklungsumgebung gleich mitbringt. Und du hast auf jeden Aspekt Einflussmöglichkeiten und das ermöglichte ja dann auch Dinge über Editorfunktionalität hinaus zu machen, was insbesondere zu der Zeit spannend war, wo man noch keine grafischen Desktop-Umgebungen hatte mit denen man einfach mehrere Programme als Fenster parallel platzieren konnte.

Im Grunde genommen war emacs ja auch eine Art Desktop-Ersatz und nicht nur einfach ein Editor.
 
jmt schrieb:
Obwohl ich ein vi-Nutzer bin, was ist denn da der Unterschied? Das ist irgendwie an mir vorbei gegangen.
Zum Vergrößern anklicken....
vim Classic ist ein Fork von vim.

Der ist entstanden, weil bei vim bei der Entwicklung AI-Code erlaubt.

Ich persoenlich bin jahrzehntelanger vim Nutzer (man koennte sogar sagen, MONOGAM).
Aber bei den letzten paar Updates stieg fuer mich die Glitch-Dichte dann doch zu sehr an. Da glaubte mein Editor z.B. dass er das Syntaxhighlighting umfaerben muesste, weil angeblich ein Dark Mode erkannt wurde und man das andere ja viel viel besser lesen kann... Naja...

Das war mir dann irgendwann einfach zuviel. Vom Vim Classic verspreche ich mir gerade Feature-Stabilitaet.
 
Interessant. Das hatte ich so noch nicht auf dem Schirm. Da werden vermutlich einige plugins mit vim9 script nicht funktionieren. OpenBSD hat vim-classic auch schon geportet. Momentan spiele ich ein wenig mit dem neuen FreeBSD 15.1 und dort gibt es vim-classic noch nicht in den ports. Sonst haette ich das mal getestet. Mir ist im "normalen" vim aber noch nichts komisches aufgefallen.
 
Solange die Luddites genug Lebenszeit zu haben jedes einzelne Projekt zu forken in das ein böser, böser Coding-Assistent committet hat... Vim ist da ja bei Weitem nicht das erste Projekt und wird ganz sicher auch nicht das letzte sein. Außerdem, muss man auch Projekte forken, wo Claude nicht als Co-Autor in Commits steht oder ist es wie bei Firmware, wo sie nur unfrei und böse ist, solange sie nicht in ROMs gebrannt wurde? Warum nur Vim oder rsync? Wenn dann bitte auch den Linux-Kernel. Oder ist der einfach zu groß?

Aber im Ernst: Vim hat in den inzwischen gut drei Jahren seit Brams Tod deutlich gewonnen. Am Anfang war der Verlust von Bram ein ziemlicher Schlag, auch weil er das unangefochtene Zentrum des Projekts war und viele Dinge schlicht nicht dokumentiert hatte, bzw. nie wirklich kommuniziert hatte, wo die Reise hingehen soll. Inzwischen gibt es aber eine neue Projektführung und es ist eine ganze Reihe regelmäßiger beitragender Entwickler dazugekommen. Übrigens mit einer großen Schnittmenge zu neovim. Man wird eher nicht mit neovim mergen, aber zumindest arbeitet man wieder zusammen. Vim Classic mag für die Puristen ausreichend sein, aber ich nehme dann doch lieber vim9script, statt mich mit vimscript rumzuschlagen. Das eingebaute Autocompletion Frameork, was es mir erlaubt hat Plugins in der Größe von zehntausenden Zeilen vimscript aus der Config zu werfen, will ich auch nicht mehr vermissen. Und all die unzähligen Kleinigkeiten, die hinzugekommen sind. Highlight on Yank fällt mir spontan ein.

Überhaupt, warum als Purist Vim Classic nehmen? Vim ist ein über fast 40 Jahre gewachsenes Projekt und der Code ist in weiten Teilen ... sagen wir mal alt. Will man mit dem Vim-Ökosystem komaptibel zu bleiben, sind die Möglichkeiten Dinge größer zu refactoren auch eher begrenzt, denn auch Bugs sind Features. Nicht umsonst ist neovim, einst mit Ziel Vim zu refactoren gestartet, auch ganz schnell davon abgekommen, allzu tief im Kerneditor rumzühren und Vim (und damit indirekt auch neovim) hat nicht ohne Grund echt viel Manpower in den Aufbau einer belastbaren Testumgebung mit tausendens Tests und umfangreichen CI-Pipelines gesteckt.

Das Problem zeigt sicht auch gut im Bereich Sicherheit. Vim hat alleine im Mai 10 Sicherheitslücken gepatcht. Einige davon, Gott bewahre, von einem LLM gefunden. Das meiste die üblichen Fehler altem Codes. Speicherprobleme, Codeinjection, man kennt es. In der Changelog von Vim Classic findet man dazu übrigens nichts. Besser keine Dateien aus unbekannter Quelle, zum Beispiel git Checkout, damit öffnen. Außer man mag es am Limit zu leben.

Nein, wenn ich ein Problem mit dem Weg, den Vim nimmt, hätte und etwas Einfacheres bzw. Statischeres wollen würde, würde ich eher in Richtung Helix schauen. Klar, ich würde umlernen müssen, aber das ist eine Sache von Tagen bis höchsten Wochen. Dafür habe ich saubereres, in sich konsistenteres da gezielt designed und nicht seit Anfängen von ed ca. 1969 hysterisch gewachsenes Bedienkonzept. Features, die sauber ineinandergreifen und die Nutzung und Pflege von Plugins weitestgehend überflüssig machen. Und nicht zuletzt eine moderne, von Beginn an test-driven entwickelte Codebase, die in einer moderen Sprache geschrieben wurde.
 
Eigentlich hätte ich auch "keines" antworten können: Zu 99% nutze ich das Standard-vi aus dem FreeBSD-Basissystem - einfach für das Ändern von Config-Dateien, kleine Anpassungen von Skripten usw. Ich habe dann doch "vim" geklickt, weil ich es auf fast jedem Host, jeder Jail installiere - um Vim-Diff zu nutzen. Meist, um zwei Versionen einer Config-Datei miteinander abzugleichen.
 
Ich verwende im Terminal Neovim und zum Programmieren VS Code. Bisher habe ich mich noch nicht dazu durchgerungen, alle Vim-Shortcuts zu lernen.

Für Neovim gibt es mit LazyVim ein fertiges Setup, bei dem bereits vieles vorkonfiguriert ist:
https://www.lazyvim.org/

Mit Emacs bin ich nie wirklich warm geworden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben