this post was submitted on 04 Mar 2024
132 points (94.6% liked)
ich_iel
9097 readers
1 users here now
Die offizielle Zweigstelle von ich_iel im Fediversum.
Alle Pfosten müssen den Titel 'ich_iel' haben, der Unterstrich darf durch ein beliebiges Symbol oder Bildschriftzeichen ersetzt werden. Ihr dürft euch frei entfalten!
📱 Empfohlene Schlaufon-Applikationen für Lassmich
Befreundete Kommunen:
Regeln:
1. Seid nett zueinander
Diskriminierung anderer Benutzer, Beleidigungen und Provokationen sind verboten.
2. Pfosten müssen den Titel 'ich_iel' oder 'ich iel' haben
Nur Pfosten mit dem Titel 'ich_iel' oder 'ich iel' sind zugelassen. Alle anderen werden automatisch entfernt.
Unterstrich oder Abstand dürfen durch ein beliebiges Textsymbol oder bis zu drei beliebige Emojis ersetzt werden.
3. Keine Hochwähl-Maimais oder (Eigen)werbung
Alle Pfosten, die um Hochwählis bitten oder Werbung beinhalten werden entfernt. Hiermit ist auch Eigenwerbung gemeint, z.b. für andere Gemeinschaften.
4. Keine Bildschirmschüsse von Unterhaltungen
Alle Pfosten, die Bildschirmschüsse von Unterhaltungen, wie beispielsweise aus WasistApplikaton oder Zwietracht zeigen, sind nicht erlaubt. Hierzu zählen auch Unterhaltungen mit KIs.
5. Keine kantigen Beiträge oder Meta-Beiträge
ich_iel ist kein kantiges Maimai-Brett. Meta-Beiträge, insbesondere über gelöschte oder gesperrte Beiträge, sind nicht erlaubt.
6. Keine Überfälle
Wer einen Überfall auf eine andere Gemeinschaft plant, muss diesen zuerst mit den Mods abklären. Brigadieren ist strengstens verboten.
7. Keine Ü40-Maimais
Maimais, die es bereits in die WasistApplikation-Familienplauderei geschafft haben oder von Rüdiger beim letzten Stammtisch herumgezeigt wurden, sind besser auf /c/ichbin40undlustig aufgehoben.
8. ich_iel ist eine humoristische Plattform
Alle Pfosten auf ich_iel müssen humorvoll gestaltet sein. Humor ist subjektiv, aber ein Pfosten muss zumindest einen humoristischen Anspruch haben. Die Atmosphäre auf ich_iel soll humorvoll und locker gehalten werden.
9. Keine Polemik, keine Köderbeiträge, keine Falschmeldungen
Beiträge, die wegen Polemik negativ auffallen, sind nicht gestattet. Desweiteren sind Pfosten nicht gestattet, die primär Empörung, Aufregung, Wut o.Ä. über ein (insbesonders, aber nicht nur) politisches Thema hervorrufen sollen. Die Verbreitung von Falschmeldungen ist bei uns nicht erlaubt.
Bitte beachtet auch die Regeln von Feddit.de
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Welchen Texteditor nutzt du? Ich bin noch nicht von VSCode losgekommen aber electron apps waren zumindest mal problematisch unter BSDs zum laufen zu bekommen. (Hat sich das geändert?)
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.
Okay grober überblick über änderungen mach ich über magit. Spc-g-g und es zeigt mir alle änderungen an, ähnlich zu git status, aber auch aufklappbar usw. Das brauche ich halt auch nur, wenn ich es sehen will, deswegen meiner Meinung nach sinnvoll in einem anderen Buffer versteckt.
Also ich habe den treemacs-git-mode gefunden, der hebt änderungen farblich hervor. Dann gibt es noch einen lsp-treemacs-errors-list-mode, aber wie das funktioniert verstehe ich nicht. Progressbar zu fehlern hab ich durch LSP, indem unten rechts immer steht wie viele Fehler ich hab. Satisfying da keine Zahl stehen zu haben :D
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.