Electron ist ein nicht notwendiges Übel und es ist ziemlich ok, dass es nicht auf allen Plattformen funktioniert.
Dies vorweggeschickt: Ich war lange zufrieden mit Sublime Text (damals unter Windows), aber auf der Suche nach einer freien Alternative hat es mich zu GNU Emacs verschlagen. (Ich weiß: BSD und GNU - na, so puritanisch bin ich nicht.) Visual Studio Code hatte ich mir (auch unter Windows) mal kurz angesehen, aber ich empfand es eher als lästig mit den zahllosen Popups, der miesen Performance und dem Electron-Unterbau. Als “kleiner” Texteditor für Dinge, für die ich nicht unbedingt ein komplettes IDE hochfahren will (mein Emacs ist doch schon recht vollgepackt mittlerweile), kommt bei mir meist sam zum Einsatz; Sonderfall: auf den Servern, also ohne GUI, nehme ich meist das, was gerade da ist (nvi, mg, ed, TECO… in der Regel sind das nur einzeilige Konfigurationsänderungen, da ist mir das eingesetzte Werkzeug fast völlig egal).
(Oje. Gibt es auf diese Frage eigentlich eine mögliche Antwort, die nicht Folgediskussionen nach sich zieht?)
Ich bin auch eher genervt von VSCode, insbesondere die Integration mit LSP Clients ist gefühlt schlechter statt besser geworden in letzter Zeit. Ich sehe Electron auch eigentlich als eine blödsinnige (oder mindestens blödsinnig umgesetzte) Idee an. Trotzdem war ich mit keinem anderen Editor bis jetzt mehr zufrieden.
Was für mich persönlich das beste Feature von VSCode ist, ist sein Dateistruktur View. Also das was in Vim z.B. NerdTree ist. VSCode integriert die verschiedenen Status der Dateien in diese View (ist die Datei geändert im Sinne von git, hat die Datei warnungen/errors im Sinne von LSP, …). Das finde ich persönlich unglaublich convenient. Vielleicht muss ich mich aber doch nochmal in Emacs reinfuchsen und das mal selber implementieren. Lisp steht sowieso noch auf meiner TODO-Liste.
(Oje. Gibt es auf diese Frage eigentlich eine mögliche Antwort, die nicht Folgediskussionen nach sich zieht?)
Ich hatte aus dem Grund auch kurz gezögert auf den Absenden Knopf zu drücken. Ich hab aber immernoch die Hoffnung, dass da draußen irgendwo ein VSCode in besser rumfliegt das ich einfach nur nicht sehe
Ziemlich sicher, dass es so einen Filetree gibt (teemacs & neotree). Ob die geänderte Dateien anzeigen keine Ahnung. Aber wenn man sich an den Workflow gewöhnt hat, braucht man eh keinen Filetree.
Wie behältst du die Übersicht über geänderte Dateien und noch offene errors/warnings ohne einen Filetree? Hast du dafür eine jeweils eigene View? Oder brauchst du so eine Übersicht in deinem Workflow einfach nicht?
Wofür musst du wissen, ob eine Datei geändert ist? Das sehe ich meistens dann in magit (bestes Git-UI ever), wenn ich entscheide was in den commit kommt.
Ich mach fast nur Python, die Errors und Warnings sehe ich entweder mit LSP direkt für die aktuelle Datei oder in der Python Konsole die ich im unteren Drittel offen hab, wahrscheinlich so wie du auch in VS Code. Mir ist aber eigentlich noch nie passiert, dass ich einen Fehler in einer anderen Datei verursacht habe, die ich gar nicht offen hab? Brauche ich also eigentlich nicht.
Wenn das so ein gängiges Ding ist von VS Code, dann gibt es dazu garantiert auch ein package für Emacs. Oder ist sogar in neotree/treemacs mit drin. Nutze ich wie gesagt auch nie. Für sowas nutze ich immer projectile.
Protip: nutz evil-mode. Wenn schon neue keybindings, dann lern gleich die von vim, die sind eh besser.
Wofür musst du wissen, ob eine Datei geändert ist? Das sehe ich meistens dann in magit (bestes Git-UI ever), wenn ich entscheide was in den commit kommt.
Naja ich nutze keine git-ui und einen groben überblick über die Änderungen zu haben finde ich ganz nützlich um einzuschätzen ob ich jetzt vielleicht mal zwischendurch einen commit machen sollte. Es geht mir dabei nicht um eine Datei sondern um eine Übersicht über das gesamte Projekt.
Mir ist aber eigentlich noch nie passiert, dass ich einen Fehler in einer anderen Datei verursacht habe, die ich gar nicht offen hab? Brauche ich also eigentlich nicht.
Ich maintaine ein paar meiner Projekte schon ein bisschen länger und da kommen manchmal neue Ideen auf wie man etwas besser machen könnte. Wenn man ein Grundkonzept ändert ändert sich eben in vielen Dateien was. Mir hilft es zu sehen wie viel sich ändern müsste um das Konzept so abzuändern wie ich es mir vorgestellt habe. Außerdem gibt es einem eine Art Progressbar wenn man sieht wie langsam aber sicher die Fehler weniger werden.
Wenn das so ein gängiges Ding ist von VS Code, dann gibt es dazu garantiert auch ein package für Emacs. Oder ist sogar in neotree/treemacs mit drin.
Ich habe ein paar Referenzen gefunden, dass man sich zumindest die Git Funktionalität aus ein paar Packages zusammenstückeln kann. Das klingt aber ziemlich fragil ehrlich gesagt und ich weiß nicht ob das dann auch durch die Ordner nach oben propagieren würde. Es ist ja anscheinend nicht so ganz offensichtlich für andere dass das nützlich ist. Bei LSP sind die meisten Editoren dabei stehen geblieben die Errors und Warnings in einer Liste anzuzeigen und das gut genug zu nennen, keine Ahnung ob und wie das dann mit dem gefrickel zum Gitstatus anzeigen zusammenspielen würde.
Wissenswert: Emacs Lisp ist älter als Common Lisp und hat manche Eigenheit, die in späteren Lisps “besser” gelöst sind. Um ein Gefühl für Lisps zu bekommen, ist es aber sicherlich ein guter Anfang; und GNU Emacs ist in der Lispwelt allgemein ein beliebtes IDE für die meisten Dialekte. Das hat gute Gründe.
Electron ist ein nicht notwendiges Übel und es ist ziemlich ok, dass es nicht auf allen Plattformen funktioniert.
Dies vorweggeschickt: Ich war lange zufrieden mit Sublime Text (damals unter Windows), aber auf der Suche nach einer freien Alternative hat es mich zu GNU Emacs verschlagen. (Ich weiß: BSD und GNU - na, so puritanisch bin ich nicht.) Visual Studio Code hatte ich mir (auch unter Windows) mal kurz angesehen, aber ich empfand es eher als lästig mit den zahllosen Popups, der miesen Performance und dem Electron-Unterbau. Als “kleiner” Texteditor für Dinge, für die ich nicht unbedingt ein komplettes IDE hochfahren will (mein Emacs ist doch schon recht vollgepackt mittlerweile), kommt bei mir meist sam zum Einsatz; Sonderfall: auf den Servern, also ohne GUI, nehme ich meist das, was gerade da ist (
nvi,mg,ed, TECO… in der Regel sind das nur einzeilige Konfigurationsänderungen, da ist mir das eingesetzte Werkzeug fast völlig egal).(Oje. Gibt es auf diese Frage eigentlich eine mögliche Antwort, die nicht Folgediskussionen nach sich zieht?)
Ich bin auch eher genervt von VSCode, insbesondere die Integration mit LSP Clients ist gefühlt schlechter statt besser geworden in letzter Zeit. Ich sehe Electron auch eigentlich als eine blödsinnige (oder mindestens blödsinnig umgesetzte) Idee an. Trotzdem war ich mit keinem anderen Editor bis jetzt mehr zufrieden.
Was für mich persönlich das beste Feature von VSCode ist, ist sein Dateistruktur View. Also das was in Vim z.B. NerdTree ist. VSCode integriert die verschiedenen Status der Dateien in diese View (ist die Datei geändert im Sinne von git, hat die Datei warnungen/errors im Sinne von LSP, …). Das finde ich persönlich unglaublich convenient. Vielleicht muss ich mich aber doch nochmal in Emacs reinfuchsen und das mal selber implementieren. Lisp steht sowieso noch auf meiner TODO-Liste.
Ich hatte aus dem Grund auch kurz gezögert auf den Absenden Knopf zu drücken. Ich hab aber immernoch die Hoffnung, dass da draußen irgendwo ein VSCode in besser rumfliegt das ich einfach nur nicht sehe
Ziemlich sicher, dass es so einen Filetree gibt (teemacs & neotree). Ob die geänderte Dateien anzeigen keine Ahnung. Aber wenn man sich an den Workflow gewöhnt hat, braucht man eh keinen Filetree.
Wie behältst du die Übersicht über geänderte Dateien und noch offene errors/warnings ohne einen Filetree? Hast du dafür eine jeweils eigene View? Oder brauchst du so eine Übersicht in deinem Workflow einfach nicht?
Wofür musst du wissen, ob eine Datei geändert ist? Das sehe ich meistens dann in magit (bestes Git-UI ever), wenn ich entscheide was in den commit kommt.
Ich mach fast nur Python, die Errors und Warnings sehe ich entweder mit LSP direkt für die aktuelle Datei oder in der Python Konsole die ich im unteren Drittel offen hab, wahrscheinlich so wie du auch in VS Code. Mir ist aber eigentlich noch nie passiert, dass ich einen Fehler in einer anderen Datei verursacht habe, die ich gar nicht offen hab? Brauche ich also eigentlich nicht.
Wenn das so ein gängiges Ding ist von VS Code, dann gibt es dazu garantiert auch ein package für Emacs. Oder ist sogar in neotree/treemacs mit drin. Nutze ich wie gesagt auch nie. Für sowas nutze ich immer projectile.
Protip: nutz evil-mode. Wenn schon neue keybindings, dann lern gleich die von vim, die sind eh besser.
Naja ich nutze keine git-ui und einen groben überblick über die Änderungen zu haben finde ich ganz nützlich um einzuschätzen ob ich jetzt vielleicht mal zwischendurch einen commit machen sollte. Es geht mir dabei nicht um eine Datei sondern um eine Übersicht über das gesamte Projekt.
Ich maintaine ein paar meiner Projekte schon ein bisschen länger und da kommen manchmal neue Ideen auf wie man etwas besser machen könnte. Wenn man ein Grundkonzept ändert ändert sich eben in vielen Dateien was. Mir hilft es zu sehen wie viel sich ändern müsste um das Konzept so abzuändern wie ich es mir vorgestellt habe. Außerdem gibt es einem eine Art Progressbar wenn man sieht wie langsam aber sicher die Fehler weniger werden.
Ich habe ein paar Referenzen gefunden, dass man sich zumindest die Git Funktionalität aus ein paar Packages zusammenstückeln kann. Das klingt aber ziemlich fragil ehrlich gesagt und ich weiß nicht ob das dann auch durch die Ordner nach oben propagieren würde. Es ist ja anscheinend nicht so ganz offensichtlich für andere dass das nützlich ist. Bei LSP sind die meisten Editoren dabei stehen geblieben die Errors und Warnings in einer Liste anzuzeigen und das gut genug zu nennen, keine Ahnung ob und wie das dann mit dem gefrickel zum Gitstatus anzeigen zusammenspielen würde.
GNU Emacs hat mittlerweile auch ein ziemlich gutes LSP-Paket eingebaut bekommen. :-)
Das ist in GNU Emacs auch schon vorhanden. Es gibt aber natürlich Alternativen.
Wissenswert: Emacs Lisp ist älter als Common Lisp und hat manche Eigenheit, die in späteren Lisps “besser” gelöst sind. Um ein Gefühl für Lisps zu bekommen, ist es aber sicherlich ein guter Anfang; und GNU Emacs ist in der Lispwelt allgemein ein beliebtes IDE für die meisten Dialekte. Das hat gute Gründe.