Wie man den Helix-Editor als Editor für die Entwicklung auf Remote-Servern nutzt

 (rushter.com)
7 Punkte von GN⁺ 2025-10-14 | 2 Kommentare | Auf WhatsApp teilen
  • Der Grund, Helix zu wählen als Editor für die Entwicklung auf Remote-Servern, ist, dass er sich im Gegensatz zu Vim/Neovim auch ohne die Installation Dutzender Plugins verwenden lässt und so das Risiko von Supply-Chain-Angriffen reduziert
  • Durch die Einrichtung der tmux-Integration werden der fehlende Dateiexplorer und Git-TUI-Funktionen in Helix ergänzt, sodass sich der Dateimanager yazi, lazygit usw. als Pop-up starten lassen
  • Durch die Übernahme von Keybindings im Vim-Stil werden Aufgaben wie Zeilenauswahl, Cursorbewegung und Textlöschen ähnlich wie in Vim ausgeführt, außerdem wurde ESC so geändert, dass damit Multi-Cursor zurückgesetzt werden
  • Zur Statusleiste (statusline) wurden Informationen wie Git-Branch, Encoding und Position hinzugefügt, um die Produktivität zu steigern
  • Mithilfe von Tree-sitter-Injections werden SQL-Queries innerhalb von Python/Go sowie Code-Blöcke in Markdown syntaxhervorgehoben, was die Lesbarkeit verbessert
  • Mit fortgeschrittenen Einstellungen wie LSP, Auto-Save und Farbmodi lässt sich die Arbeitsproduktivität steigern und das Verhalten fein anpassen

Warum Helix

  • Wegen der jüngsten Zunahme von Supply-Chain-Angriffen und Problemen mit Plugin-Abhängigkeiten wurde Helix statt Vim/Neovim als Editor für die Entwicklung auf Remote-Servern eingeführt
  • Ein großer Vorteil ist, dass er auch ohne Dutzende Plugins in Neovim allein mit den Grundfunktionen nutzbar ist
  • Nach dem Umstieg auf Helix wurden Konfigurationsanpassungen vorgenommen, um die vertraute Neovim-Erfahrung möglichst weitgehend nachzubilden
  • Das Ziel der Veröffentlichung ist es, anderen Nutzern Zeit zu sparen

Tmux-Konfiguration

  • Als Terminal-Multiplexer wird Tmux verwendet; um das Fehlen eines Dateimanagers und einer Git-TUI zu kompensieren, wurden benutzerdefinierte Keybindings ergänzt
  • Helix unterstützt im Dateiexplorer kein Editieren von Dateien, was beim schnellen Wechsel zwischen mehreren Dateien unpraktisch war
  • In der Tmux-Konfigurationsdatei wurden folgende Bindings ergänzt
    • prefix - y: startet den Yazi-Dateimanager als Pop-up-Fenster (95 % der Bildschirmgröße)
    • prefix - g: startet Lazygit als Pop-up-Fenster
    • prefix - e: öffnet die Tmux-Ausgabehistorie im Helix-Editor, um darin zu suchen und Inhalte zu kopieren
  • Das Standard-Prefix ist Ctrl + b, wurde hier aber zu Ctrl + \ geändert
  • Nützlich für die Arbeit mit Terminal-Ausgaben, besonders beim Kopieren von ClickHouse-Client-Ausgaben (CSV/JSON) nach Slack
    • Statt in eine Datei auszugeben, kann direkt kopiert werden, was Arbeitsschritte spart
    • Per Maus wäre es ebenfalls möglich, aber das Scrollen im Tmux-Puffer ist unkomfortabel, daher ist die Bearbeitung im Editor effizienter
  • Yazi und Lazygit werden in der Regel als Overlay über dem Helix-Editor angezeigt

Vim-Keybindings übernehmen

  • An die Helix-Keybindings hat man sich zwar gewöhnt, dennoch werden weiterhin einige Vim-Bindings übernommen
  • Bindings im Select-Modus
    • 0: an den Zeilenanfang springen
    • $: ans Zeilenende springen
    • ^: zum ersten nichtleeren Zeichen springen
    • G: ans Dateiende springen
    • D: bis zum Zeilenende auswählen, löschen und in den Normal-Modus wechseln
    • k/j: ganze Zeilen nach oben/unten auswählen (das Standardverhalten von Helix mit Teilselektion war unpraktisch)
  • Bindings im Normal-Modus
    • D: den gesamten Text rechts vom Cursor löschen (in Helix waren dafür zu viele Tasten nötig, daher übernommen)
    • V: in den Select-Modus wechseln und die ganze Zeile auswählen
    • ESC: Multi-Cursor zurücksetzen (Helix nutzt standardmäßig das Komma, was unpraktisch ist)
  • Da die Zeilenauswahl im visuellen Modus von Helix nicht gefiel, wurde sie auf den Vim-Stil umgestellt
    • Beim Bewegen nach oben/unten werden ganze Zeilen ausgewählt

Verbesserte Statusleiste

  • In der Standard-Statusleiste fehlen wichtige Informationen wie der aktuelle Git-Branch
  • Aufbau der Statusleiste
    • links: Modus, Spinner, Versionsverwaltung, Dateiname, Read-only-Anzeige, Änderungsanzeige
    • Mitte: leer
    • rechts: Diagnosen, Workspace-Diagnosen, Position, Gesamtzeilenzahl, Positionsprozentsatz, Dateikodierung, Zeilenendformat, Dateityp, Register, Anzahl der Auswahlen
    • Trennzeichen: das Zeichen │
  • So lässt sich der Arbeitsstatus auf einen Blick erfassen

Nützliche Keybindings

  • Mit benutzerdefinierten Keybindings wurde die Arbeitseffizienz stark verbessert, auch wenn das Auffinden Zeit gekostet hat
  • Die nützlichsten Funktionen: Datei neu laden, Soft-Wrap umschalten, Git undo, Git blame, Git diff
  • Vollständige Liste benutzerdefinierter Bindings
    • space - e - w: aktuellen Buffer in Datei speichern
    • space - e - c: aktuellen Buffer schließen
    • space - e - x: alle anderen Buffer schließen (nützlich, wenn Dutzende Buffer offen sind)
    • space - e - l: Inlay-Type-Hints umschalten (nützlich, aber dauerhaft eingeblendet zu unruhig)
    • + - f: aktuelle Datei formatieren
    • + - w: Whitespace-Zeichen rendern (um unsichtbare Zeichen im Dokument zu prüfen)
    • + - W: Rendering von Whitespace-Zeichen deaktivieren
    • space - f - .: im File-Picker von Git ignorierte Dateien ein-/ausblenden
    • space - f - r: alle Dateien neu laden (sehr nützlich, da Helix kein automatisches Reload unterstützt; für externe Änderungen oder zum Aktualisieren des Gutters nach Commits)
    • space - f - x: Git-Änderung an der aktuellen Cursorposition rückgängig machen
    • space - f - w: Git blame der aktuellen Zeile anzeigen
    • space - f - d: Git diff anzeigen

Editor-Einstellungen

  • Nach 6 Monaten Nutzung wurde entdeckt, dass es eine Funktion zum automatischen Speichern beim Wechseln von Terminal-Tabs gibt
  • Einige neuere Funktionen von Helix sind standardmäßig deaktiviert, damit bestehende Nutzer nicht von unerwarteten Änderungen betroffen sind
  • Neue Funktionen lassen sich nur entdecken, wenn man die einzelnen Optionen selbst überprüft
  • Wichtige Konfigurationsoptionen
    • line-number = "relative": relative Zeilennummern anzeigen
    • rulers = [120]: visuellen vertikalen Linealstrich setzen (nützlich, wenn man die maximale Zeilenlänge ohne Autoformatierung begrenzen will)
    • true-color = true: True-Color-Unterstützung erzwingen
    • completion-replace = true: Autovervollständigung ersetzt das ganze Wort
    • trim-trailing-whitespace = true: nachgestellte Leerzeichen entfernen
    • color-modes = true: Modusanzeige farblich unterscheiden
    • rainbow-brackets = true: verschiedene Farben für geschachtelte Klammern verwenden (neue Funktion, noch nicht im offiziellen Release)
    • editor.file-picker.hidden = false: versteckte Dateien (Dotfiles) im File-Picker anzeigen
    • editor.indent-guides.render = true: visuelle Einrückungshilfen hinzufügen
    • editor.inline-diagnostics.cursor-line = "warning": Diagnoseanzeige verbessern (siehe Screenshot)
    • editor.auto-save.focus-lost = true: automatisch speichern, wenn der Fokus verloren geht (Terminal-Unterstützung erforderlich)
    • editor.auto-save.after-delay.enable = true: automatisch nach einer festgelegten Verzögerung speichern (auf 300 Sekunden gesetzt)

LSP-Anpassung

  • Für alle Sprachen wurde harper-ls LSP hinzugefügt, um Grammatikfehler in Kommentaren hervorzuheben

Benutzerdefinierte Tree-sitter-Injections

  • Helix erlaubt benutzerdefinierte Tree-sitter-Injections, sodass innerhalb einer Sprache eine andere Sprache hervorgehoben werden kann
  • Einsatzbeispiele
    • Syntaxhervorhebung für SQL-Queries innerhalb von Python und Go
    • Hervorhebung von YAML-Front-Matter und Code-Blöcken in Markdown
    • Kann auch für die Hervorhebung von HTML-Snippets genutzt werden
  • Die Konfigurationsdateien wurden auf GitHub hochgeladen, um benutzerdefinierte Injections und Einstellungen zu teilen
  • Helix ist ein Terminal-Editor der nächsten Generation, dessen Stärken vor allem in minimalen Plugins, Sicherheit und intuitiver Anpassbarkeit liegen

Verwandte Beiträge

2 Kommentare

 
xguru 2025-10-14

Ein Entwickler, der 20 Jahre lang Vim verwendet hat, berichtet über seinen Wechsel von Vim zu Helix
 
GN⁺ 2025-10-14
Hacker-News-Kommentare

  • Ich baue gerade meine Editor-Konfigurationen neu auf. Seit 20 Jahren nutze ich parallel Emacs und seit 15 Jahren Vim, und ich kann mich einfach nicht für eines von beiden entscheiden. Mein Ziel ist herauszufinden, wie schnell ich ein ausgereiftes Setup zusammenstellen kann, das sich sofort für Enterprise-Python-Software einsetzen lässt. Diesmal versuche ich besonders, die Abhängigkeit von Drittanbieter-Erweiterungen so weit wie möglich zu reduzieren und nur die nötigen Funktionen zu behalten. Mein aktuelles Neovim-Setup ist meiner Meinung nach das beste, das ich je hatte, aber ich benutze am Ende doch mehr Plugins als erwartet. Bei Emacs bin ich noch in einer frühen Phase, aber interessant ist, wie stark es sich weiterentwickelt hat, so dass man ab Version 30 deutlich weniger Drittanbieter-Plugins braucht. Früher habe ich lsp-mode genutzt, inzwischen bin ich mit Eglot zufrieden. Der Completion Preview Mode ersetzt corfu zwar nicht vollständig, ist aber ziemlich ordentlich. Meine unverzichtbaren Emacs-Plugins sind Magit, Expreg (teeesitter expand region), Multiple cursors und dape (Debugging in Verbindung mit Eglot). Wahrscheinlich kommen noch Consult und orderless dazu. Mein Neovim-Setup gibt es hier

    • Das neue nvim reduziert den Plugin-Bedarf ebenfalls immer weiter. Es bringt einen eingebauten Plugin-Manager, einen Diff-Viewer und LSP direkt mit

    • Du verwaltest ziemlich viele nvim-Plugins! Ich habe mein nvim-Setup letzte Woche mit vier Plugins inklusive mini.nvim neu geschrieben. Wenn man viele Plugins dranhängt, merkt man deutlich, wie Stabilität und Zuverlässigkeit von nvim leiden. Dass du bei Emacs nur zwei brauchst, darum beneide ich dich; das dürfte auf jeden Fall viel stabiler laufen. Mein Setup gibt es hier

    • Mich würde interessieren, ob du nach ein paar Monaten Nutzung immer noch meinst, dass du damit in die Nähe des mitgelieferten Setups von Pycharm+IdeaVIM kommst. Natürlich macht es Spaß, die Konfiguration selbst anzupassen, aber wenn man sich nur auf effizientes Arbeiten mit einer IDE konzentriert, ist es dann nicht etwas ineffizient, so viel Zeit in eine Neovim-Konfiguration zu stecken?

    • Expreg (teeesitter expand region) erinnert mich an combobulate (habe ich noch nicht benutzt, sieht aber cool aus). Expreg wirkt allerdings deutlich einfacher und leichtergewichtig

    • Mich interessieren die Erfahrungen langjähriger Emacs-Nutzer wirklich sehr. Ich würde gern wissen, wie es sich im Vergleich zu Helix/Vim anfühlt. Leute, die Helix/Vim zum ersten Mal ausprobiert haben, sagen oft, dass es gut sei, aber es wirkt auf mich, als würden sie den eigentlichen Wert von Emacs nach langer Nutzung gar nicht kennen. Es stimmt zwar, dass Vim-artige Tasten und Modi sich in modernen Editoren besser integrieren lassen, aber wenn ich es selbst benutze, fehlt mir die Geduld, durchzuhalten, bis sich meine Finger daran gewöhnt haben. Ich würde gern echte Berichte von hardcore Emacs-Nutzern hören, die umgestiegen sind

  • Ich bin nacheinander von Emacs zu VS Code und dann zu Helix gewechselt. Bisher habe ich versucht, die vorhandenen Tastenbelegungen so gut wie möglich zu lernen und möglichst effektiv zu arbeiten, ohne fast etwas an der Konfiguration zu ändern. Weil es schwer ist, sich alles zu merken, was Helix kann, habe ich sogar eine Schreibtischunterlage erstellt, auf der die Tasten direkt aufgedruckt sind. Wie hilfreich das wirklich ist, werde ich wohl erst merken, wenn ich sie ausdrucke und benutze. Meine Schreibtischunterlage gibt es hier

    • Mich würde interessieren, wie lange du Emacs benutzt hast

  • Seit zehn Jahren nutze ich Emacs als Haupteditor, davor war es Sublime Text. Für einfache Dateibearbeitung oder auf Remote-Servern nutze ich gelegentlich Vim, aber ich hatte nie das Bedürfnis, komplett nur Vim zu verwenden. In Emacs habe ich meine eigenen Module und Funktionen gebaut und damit eine Umgebung geschaffen, die genau zu mir passt. Letzten Monat habe ich Helix ausprobiert, und der Einstieg war überraschend simpel. An die grundlegende Nutzung — Navigation, Suche, Einfügen, Wechsel zwischen Buffern und Fenstern — habe ich mich schnell gewöhnt. Über die Geschichte von Helix weiß ich nicht viel, aber das Design ist hervorragend. Besonders die globale Suche ist großartig, die LSP-Integration sitzt genau richtig, und es ist wirklich schnell. Es ist sehr angenehm, dass die Standardwerte so konsistent und nützlich gewählt sind. Ich werde es weiter regelmäßig nutzen, um noch vertrauter damit zu werden. Mein Standardeditor bleibt zwar Emacs, aber Helix ist so schnell, dass es für das eigentliche Coding durchaus mein Haupteditor werden könnte

  • Ich probiere Helix gerade zum ersten Mal aus, und zwei Nachteile fallen mir besonders auf

    • Modales Editieren ist der Kern, aber bei Vim kann man seine vorhandene Muscle Memory fast überall direkt mitnehmen (Vim-Modi gibt es fast überall, viele Erweiterungen wie Vimium, und in einer ssh-Umgebung ist Vim fast immer vorhanden)
    • Helix setzt auf Einfachheit, hat keine Terminal-Integration und ist bei Plugins nicht besonders erweiterbar (auch Linting wird nur LSP-basiert unterstützt); diese Kombination wirkt für mich so, als müsse man oberhalb des Editors noch ein separates Setup bauen, was eine klare Grenze ist (also z. B. mit tmux) Ich will diese Nachteile nicht angreifen, sondern frage mich, welche Stärken sie ausreichend ausgleichen

    • Ich verstehe nicht ganz, warum LSP ein Nachteil sein soll. Es wirkt eher so, als liefe LSP als separater Prozess, und das halte ich eher für gut im Sinne einer Plugin-Sandbox. In der Praxis könnte das sogar besser funktionieren als klassische Editor-Plugins. Auch das fehlende tmux-Integrationsthema spüre ich nicht so sehr; obwohl ich hauptsächlich Emacs nutze, verwende ich interne Terminals fast nie. Wenn man nur die Muscle Memory umziehen muss, finde ich einen schnellen, in Rust geschriebenen Editor durchaus überzeugend

    • Es gibt die Behauptung, Vim-Bewegungen seien als Muscle Memory überall einsetzbar, aber tatsächlich gibt es kaum Entwickler, die die Standard-Vim-Umgebung ohne Plugins oder Konfiguration wirklich so verwenden wollen. Die meisten wollen einen Editor mit einem fein auf sie zugeschnittenen Setup und den passenden Funktionen. Die Ausnahme sind wohl Leute, die sich per ssh auf viele verschiedene Maschinen einloggen und dort unbedingt eine Standard-Editorumgebung brauchen. Du hast die Einfachheit von Helix und seine begrenzte Plugin-Erweiterbarkeit erwähnt; ursprünglich zielte Helix auf einen All-in-One-Editor, aber die Community wollte das nicht, daher wird gerade ein Plugin-System entwickelt. Im Hauptrelease ist es noch nicht enthalten, aber auf einem separaten Branch werden bereits verschiedene Plugins gebaut und genutzt. Ich halte es für die richtige Entscheidung, die Veröffentlichung zu verschieben, bis das Plugin-System stabil genug ist. Der größte Vorteil von Helix ist, dass es die unbequeme UX verbessert, die bei vi/vim/neovim geblieben ist. Anders gesagt: Es ändert die Arbeitsreihenfolge so, dass man geänderte Inhalte vor dem Commit leichter prüfen kann, was unbeabsichtigte Nebeneffekte reduziert

  • Bei so einer Konfiguration scheint es mir sinnvoller, einfach vim zu benutzen. Du versuchst innerhalb von Helix Vim-Funktionen nachzubauen, und auch Helix hat intern viele Abhängigkeiten — sie sind nur nicht so sichtbar wie bei nvim. Mein vim8-Setup halte ich seit über acht Jahren bewusst simpel. Ich benutze vim8, weil es die Version ist, die auf LTS-Distributionen mitgeliefert wird. Es gibt genau ein automatisch geladenes Plugin (vim-tmux-navigator, um einfach zwischen vim-Splits und tmux-Panes zu wechseln), ich habe den Code geprüft und aktualisiere es nicht. Zwei „optionale“ Plugins aktiviere ich bei Bedarf mit Vims eingebautem Paketmanager per :packadd!. Ich nutze nur ale (LSP, Diagnosen, Autoformat beim Speichern) und vim-fugitive (Git-Integration). ale hat keine Abhängigkeiten. vim-fugitive installiert man einmal und benutzt es dann einfach. Dass Plugins nicht automatisch geladen werden, hat den Grund, dass vim meist für schnelle Bearbeitungen da ist; nur bei langfristigen Projekten aktiviere ich Git/LSP. Unnötige Plugins muss man nicht zwanghaft nutzen

    • Ich mag modernes Neovim auch, deshalb arbeite ich an einem Python-Paket, das dieses Problem löst — besonders für Leute, die ohnehin schon im Python-Ökosystem unterwegs sind oder uv bzw. pipx nutzen. Mit uv tool install binwheels-neovim oder pipx install binwheels-neovim kann man das aktuelle Neovim installieren, und es funktioniert sofort auf Windows, macOS und Linux. Dieses Paket kapselt die offiziellen Neovim-Releases und nutzt uv oder pipx, um das passende Binary für Betriebssystem und Architektur zu holen. Unter Linux wird separat gebaut und ausgeliefert, weil dafür Unterstützung für ältere GLIBC-Versionen als in den offiziellen Releases nötig ist. Siehe dazu PyPI, das Github-Hauptrepo und die Build-Logs

    • Helix hat im Vergleich zu nvim+Plugins eine extrem kleine Angriffsfläche für Supply-Chain-Angriffe. Helix wird als Ganzes gepflegt und ist deutlich sicherer als nvim, wo jedes Plugin seinen eigenen Vendor mitbringt. Bei Helix erscheinen Releases langsam und vorsichtig, sodass selbst bei Schwachstellen keine größeren Probleme entstehen sollten

    • Das Editiermodell von Helix ist überlegen

  • Wenn ich bei Helix ohnehin ein TUI brauche, frage ich mich, warum ich dann Helix statt neovim verwenden sollte. Die Defaults gefallen mir, aber ab einem gewissen Punkt fühlt es sich immer mühsamer an, wenn man Dinge ändern will. Und wenn man mit Helix eine „vollständige IDE-Erfahrung“ möchte, verstehe ich auch nicht ganz, warum man dann nicht gleich Zed, VSC oder eine JetBrains-IDE verwendet. Wenn ich etwas Einfaches brauche, nutze ich nvim; wenn ich mehr Funktionen brauche, starte ich WebStorm oder schaue mit einem Kollegen gemeinsam nach etwas

    • Wenn man per ssh auf schwacher Hardware arbeitet, startet Helix fast sofort. Ein nvim mit vergleichbarer Funktionalität würde langsamer werden, und der Aufwand für Konfiguration sowie Plugin-Updates wäre größer. Außerdem kenne ich Rust und kann deshalb auch zu Bugfixes beitragen. C-artige Sprachen kann ich nicht, daher bevorzuge ich Open-Source-Projekte in Sprachen, die ich kenne. Ich bin Hobbyprogrammierer, habe zwölf Jahre lang nur n/vim benutzt und bin in den letzten zwei Jahren auf Helix umgestiegen. Ehrlich gesagt gibt es in nvim einiges, das ich vermisse oder das sich natürlicher anfühlt, aber Helix ist wirklich sofort einsatzbereit, und dieser Komfort sticht alles andere aus

    • Ich habe in den letzten Jahren jeweils längere Zeit neovim, helix, emacs und nano benutzt, und die Out-of-the-box-Erfahrung von Helix war mit Abstand die beste. Die Defaults sind wirklich hervorragend gesetzt, und die kontextbezogene Hilfe samt Hinweisen ist so gut, dass man häufig genutzte Befehle nicht unbedingt im Kopf behalten muss und selten genutzte trotzdem leicht findet. Außerdem fühlt sich in meinem Kopf die Reihenfolge, in der Helix-Befehle arbeiten, natürlicher an als bei vim. Bei modernen Editoren wie nvim oder spacemacs ist die Hürde durch Plugins und Konfiguration einfach zu hoch. Dank des Plugin-Ökosystems kann man zwar Dinge tun, die Helix aktuell nicht kann — zum Beispiel kann man emacs für praktisch jede Lisp-Sprache wie eine IDE nutzen, während Helix keine REPL laden kann —, aber dafür muss man nicht nur den Editor selbst, sondern auch zahllose Plugins lernen, und selbst bei der Suche bekommt man je nach Version und Kombination andere Antworten, was verwirrend ist. Wenn man neu anfängt, bleibt am Ende oft nur, Empfehlungen anderer zu vertrauen oder zusätzliche Zeit ins Ausprobieren und Lernen zu stecken. Helix ist ein junges Projekt und trägt nicht die Last alter Entscheidungen; dadurch konnte es Entscheidungen und Defaults wählen, die besser zu modernen Entwicklungsmustern passen. Es ist nicht perfekt, aber wenn ein TUI-Neuling etwas möchte, das sofort brauchbar ist und sich ohne Konfiguration leicht starten lässt, würde ich Helix empfehlen

    • hx startet schnell, läuft schnell und sieht sogar gut aus. Die Defaults gefallen mir ziemlich gut, ich habe nur wenig angepasst, und anders als bei emacs/neovim, wo ich ständig in einer Endlosschleife aus Verbesserungen festhing, fühlt sich hx endlich abschließbar an. Das TUI funktioniert auch auf Remote-Servern gut, sodass ich auf mac, Linux und Servern überall dieselbe Umgebung nutze (mit anderen Editoren geht das zwar auch, aber hx unterstützt es ebenfalls gut). Alle LSPs, die ich brauche, werden ordentlich unterstützt, und languages.toml war zwar etwas mühsam zu konfigurieren, aber bei anderen Editoren war das nicht anders

    • Ich mag die einfache Konfiguration und das Selection-first-Editiermodell. Als Referenz dazu siehe hier. Wenn ich mit Leuten spreche, die Schwierigkeiten hatten, sich an Vim zu gewöhnen, fällt mir auf, dass ich offenbar von Natur aus an ein Modell wie in Helix gewöhnt war: erst auswählen. Bei Vim fiel es mir schwer, mich an Operationen zu gewöhnen, bei denen der Zieltext nicht sichtbar ist und der Wirkungsbereich erst nach dem Befehl klar wird

    • Die Wahl des Editors ist weniger eine hochrationale Entscheidung als vielmehr stark von psychologischen Faktoren wie persönlichem Geschmack, Neuheit oder Spaß geprägt

  • Den Befehl :reset-diff-change kannte ich bisher nicht. Ich habe in Git immer nur checkout -p benutzt, aber direkt innerhalb von Helix ist das viel bequemer

  • Ich habe Helix benutzt, mich ernsthaft daran gewöhnt und kann inzwischen gut damit arbeiten. Trotzdem habe ich gemerkt, dass dieser „umgekehrte Arbeitsablauf“ zwar leicht zu lernen und leicht zu implementieren ist, einen in der Praxis aber eher langsamer macht. Deshalb bin ich am Ende wieder zu Vim und danach zu Zed (mit Vim-Modus) zurückgekehrt

  • Ich habe Helix heute zum ersten Mal ausprobiert, und es ist wirklich ein sehr gut gestalteter Editor. Trotzdem fand ich es schade, dass schnelle Vim-Kürzel wie y2$ oder dw fehlen

    • Eigentlich fehlen die Kürzel nicht, y2$ schreibt man einfach als 2xy, und dw wird zu wd

  • Ich habe in Helix noch nicht herausgefunden, wie man die aktuelle Zeile inklusive Leerzeilen löscht. xd löscht zwar eine Zeile, wenn sie nicht leer ist, aber bei einer Leerzeile werden gleich zwei Zeilen gelöscht

    • x wählt die aktuelle Zeile aus; wenn bereits etwas ausgewählt ist, erweitert es die Auswahl auf die nächste Zeile. X erweitert die Auswahl bis an die Zeilengrenzen (line-wise Auswahl). Du solltest also X verwenden

    • Bei einer Leerzeile nimm einfach d

    • Das ist tatsächlich etwas unpraktisch. Ich verwende selbst einen trivialen Fork, der das Verhalten von x bei Leerzeilen anders macht. Details dazu im PR hier