Sheeva P. schrieb: > Nano schrieb: >> Sheeva P. schrieb: >>> Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal >>> eine Dokumentation oder eine Präsentation erstellen, also mit Markdown, >>> HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch >>> schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder >>> womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für >>> Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine >>> klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein >>> Python-, Ruby-, Perl- oder PHP-Skript... >> >> Eclipse kann auch gewöhnliche Textdateien bearbeiten. > > Inklusive Syntax-Highlighting, Codeeinrückung, Autovervollständigung und > all den netten Features, die das Entwicklerleben vereinfachen? > Verzeihung, ich wollte darauf hinaus, daß es die große Stärke von > Editoren wie n?vim? und Emacs ist, eben viel mehr nur eine Sprache zu > beherrschen. Wenn Du all das in Deiner IDE konfigurieren willst, was ich > mit meinem Emacs und meine Kollegen mit ihren vims täglich machen, dann > hast Du mindestens denselben Konfigurationsaufwand -- also: sofern das > überhaupt geht, ohne Dir eigene Plugins und Erweiterungen zu schreiben. Wenn eine Programmiersprache oder Aussschreibungssprache für eine IDE Relevanz hat, dann wird es bei einer vielfach genutzten IDE, die nicht nur für eine Sprache geschrieben wurde, über kurz oder lang dafür auch Support geben. Der Schwerpunkt einer IDE ist nunmal das Programmieren und mehr braucht es auch nicht. Will ich einen Editor, dann nehme ich auch einen Editor. > Was wäre Deine Empfehlung für diesen Fall? Eine IDE für den Code, dann > eines für HTML, CSS und JS und noch eins für SQL, JSON, YAML, > Dockerfiles, Konfigdateien? Ich schreibe keine Webapps. Ich brauche eine gute Integration des Debuggers und da hat eine IDE ihre stärken. > Und wnen ich eine Erweiterung mit > Boost::Python, also C++, oder ein Plugin zur Integration unserer > Java-Software schreibe, dann muß ich mir wieder eine neue IDE aneignen? Eclipse kann C++ und Java. > Sei mir nicht böse, aber ich habe schon drölfundölfzig Programme, die > ich beherrschen muß. Und wenn ich bei einer so zentralen Kernsoftware > wie meinem Editor die Möglichkeit habe, fünf bis zehn spezialisierte > Programme einzusparen... yay! ;-) Ich halte dich davon nicht ab. Du kannst vim auch in die IDE integrieren. Wurde oben ja schon erwähnt. Ich will eine gute Debuggerintegration und da hat mich vim noch nicht überzeugen können. Die meisten Artikel machen an dem Punkt zu dem noch stopp und zeigen nichts. > oder meine Werkzeuge als "falsch" oder Ähnliches > abzuqualifizieren. (Das ist im Übrigen auch hochgradig unprofessionell > und dumm, IMHO.) Das habe ich nirgendwo getan. Ich sagte nur, das vim die Spezialisierung fehlt, die eine IDE hat und das stimmt auch. Gibst du ja mit deinem Qt Beispiel und GUI zusammenklicken selbst zu. >> Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den >> auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist >> deutlich umständlicher, als die Buttons und Tastaturkombinationen in der >> IDE. > > Deswegen benutze ich den GDB einfach auf der Kommandozeile Und das ist nicht besser. Wie ich bereits sagte, ich habe einfach keinen Bock, jedes mal nach jedem n(ext) den Variablenzustand abzufragen. Ich will den Zustand von ausgewählten Varibalen in nem extra Kasten bei jedem Schritt sehen ohne dem Debugger extra sagen zu müssen, aktualisiere nen Kasten bzw. spuck die Liste aus. Und das auch dann, wenn sich die Variablen nicht verändert haben. gdb war mir deswegen zu viel Tipparbeit. Und in vim war's nicht wesentlich besser gelöst, schon gar nicht mit den Defaulteinstellungen. Eine IDE hat eine Debuggeransicht und zeigt das alles auf einen Blick. >> Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt >> sehen können möchte. Bei gdb muss man erst den step eingeben und dann >> sagen, welche Variablen man anschauen will. Bei der IDE sieht man die >> Variablenzustände immer und man drückt einfach seine Taste oder den >> Button. > > Sorry, aber das kann ich nicht gelten lassen, schließlich kann man den > GDB ganz wunderbar konfigurieren und steuern -- und zwar sogar > individuell und perfekt an das jeweilige Projekt angepaßt, genau wie man > es gerade braucht. Warum soll das nicht gelten? Das Problem hatte ich, als ich mich vor Jahren mit gdb gründlich auseinandergesetzt habe. Kann sein, dass ich die Details nicht mehr so genau wiedergeben kann, aber danach bin ich zu ner IDE gewechselt und die Welt war wieder in Ordnung. > Warum der in ein GUI-Programm eingebettet sein muß? Der soll mir ne Sicht zu jeder Zeit geben. So arbeitet er aber nicht, er schiebt die Zeilen von unten nach oben und wenn man nen Überblick will, muss man den wieder abfragen oder macht es so, dass man nur dann was mitgeteilt kriegt, wenn sich der Wert einer variable verändert hat, das reicht mir aber nicht.
Sheeva P. schrieb: > Nano schrieb: >> Wie sieht's eigentlich mit der Integration von UML in vim inkl >> Codegenerierung und Darstellung von UML Diagrammen aus? :) > > UML-Diagramm mit dia [1] bauen, Das letzte mal, als ich dia zum UML Diagramm bauen getestet habe, war 2004. Und das war damals Murks, weil der Workflow grottig war und dia zwar Vektordiagramme erstellen konnte, aber die Integration der Semantik im Bezug auf UML einfach nicht gut von der Hand ging. Da gab es schon damals weitaus bessere UML Editoren mit Spezialisierung auf UML und gibt es heute erst Recht. Dia ist mehr so nen Allrounder für allgemeine Diagramme, vergleichbar mit Viso, aber nichts für UML (damals). Wie es heute ist, keine Ahnung, ist mir aber auch Wurst.
Jörg W. schrieb: > Sheeva P. schrieb: >> Entschuldige, Jörg, aber Du läßt Dich dabei gerade auf sein "Argument" >> ein, daß alle Entwicklungswerkzeuge in einem einzigen Programm >> integriert sein müßten. > > Psst, auch bei anderen IDEs sind die Debugger üblicherweise als > separates Tool, das halt dann mit dem Framework kommuniziert. ;-) Erzähl > ihm jetzt nicht, dass der GDB das auch kann … Das ist mir bekannt, keine Sorge. Und ja, mir geht es um die Debug Sitzung an sich.
Sheeva P. schrieb: > Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil > zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte Man muss fairerweise sagen, dass die grundsätzliche Lernzeit beim Vi (beim Emacs ganz ähnlich) schon etwas länger ist. So grob geschätzt in etwa so lange wie akustische Morsecodes verarbeiten lernen. Die passen deswegen so gut als Analogie, weil man auch hier die Geschwindigkeit steigern kann.. Beim nano braucht man wohl nicht so lange, aber ein Readme braucht man schon, so richtig intuitiv wie vielleicht Notepad ist der noch lange nicht. Dann finde ich noch so interessant, dass oben nach den herausragenden Stärken des Vi gefragt wurde, und sich hier die Emacs et al-Freunde begeistert an der Diskussion beteiligen. Aber um den Emacs überholen zu können, da müssten die Vi-Clones schon auch langsam mal an einem Konzept als Ersatz-Desktop arbeiten. Ich denke mal, so weit sind die Vis noch lange nicht ;) Letztlich geht es mir eher so..in Fedora schreibe ich auch in gedit. Aber das ist eben kein Notepad (und Notepad++ schon mal gar nicht) und auch nicht so interessant wie vi. Früher hätte ich noch Assemlercode mit Notepad++ zusammengestöpselt. Mittlerweile hat aber u.a. die Freude über den Watcom-vi (den man ganz ähnlich wie den blöden EDLIN mit der Maus bedienen kann! - aber EDLIN..*lach*) und auch die Editorerfahrung generell eher dazu geführt, dass ich Vi (mehr und mehr) vorziehe und die Alternativen verblassen.. Assemblerprojekte würde ich in Kombination mit Papier und Bleistift und dem Vi machen. Bei Java bleib ich auch lieber beim Vi, dann kann ich mich einfach besser auf meinen eigenen Kram konzentrieren. Macht irgendwie auch mehr Spaß.
rbx schrieb: > Beim nano braucht man wohl nicht so lange, aber ein Readme braucht man > schon, so richtig intuitiv wie vielleicht Notepad ist der noch lange > nicht. Beim nano muss man nur 6 Sachen wissen. STRG+W = Suchen STRG+O = In Datei speichern STRG+X = beenden STRG+C = Cursorposition oder Abbruch (z.b. wenn man doch nichts speichern will) STRG+K = Zeile oder markierte Zeilen ausschneiden und in Zwischenablage ablegen STRG+U = Zeile oder Zeilen aus Zwischenablage einfügen Und alle diese Befehle werden direkt unten eingeblendet und können jederzeit abgerufen werden, solange man nur weiß, dass das Zeichen ^ für die STRG Taste steht und der darauf folgende Buchstabe für die Buchstabentaste. Der Rest ergibt sich von selbst bzw. findet man nach und nach raus. In dem Zustand ist er aber für Laien schon gut benutzbar um alle Arten von Configdateien zu bearbeiten. Er ist damit vielleicht nicht so intuitiv wie edit.exe unter MS-DOS >= 5.x, aber mehr als intuitiv genug um ohne lange Einarbeitungszeit seinen kleinen Job erledigt zu bekommen.
Sheeva P. schrieb: > daß mein Debugfenster winzig klein ist und mit den Blick aufs > Wesentliche verstellt, so daß ich ständig hin- und herscrollen müßte > oder gar meine Bereiche in der IDE verstellen müßte Eclipse hat extra dafür zwei separat konfigurierbare Ansichten, startest Du eine Debugsitzung schaltet es die Ansicht um.
Sheeva P. schrieb: > einen neuen Rechner bekommen. > Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil > zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte. Das wäre mit vim nicht viel anders gelaufen, bis er da alle 42 Plugins wieder drin hat und alles wieder so konfiguriert ist daß es als IDE-Ersatz taugt wird auch nicht weniger Zeit vergehen. Und Eclipse ist in weniger als 10 Minuten wieder frisch eingerichtet wenn die Toolchain und alles schon installiert sind, das geht ratzfatz wenn man es lang genug benutzt hat und schon gut genug kennt. Hab das erst neulich gesehen als wir nen Kollegen von Windows auf Linux umgestellt haben, die ganze Aktion ging an einem Tag (mit nur ganz leichten und schnell abklingenden Nebenwirkungen danach) und die Eclipse-Installation hat noch vor der Mittagspause schon wieder vollumfänglich funktioniert, mit J-Link, Debuggen und allem. Das war also sowieso ein Anfänger wenn der 3 Tage gebraucht hat, mit vim wäre er demzufolge bis heute noch nicht fertig.
:
Bearbeitet durch User
Bernd K. schrieb: > Sheeva P. schrieb: >> einen neuen Rechner bekommen. >> Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil >> zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte. > > Das wäre mit vim nicht viel anders gelaufen, bis er da alle 42 Plugins > wieder drin hat und alles wieder so konfiguriert ist daß es als > IDE-Ersatz taugt wird auch nicht weniger Zeit vergehen. Das ist kein Problem. Man kopiert die .vimrc und das Verzeichnis .vim rüber, und schon tut alles wie gewohnt. Dauert keine 2 Minuten.
Ja, und bei Eclipse habe ich schon viele Plug-ins gesehen, die sich in einer neuen Version nicht mehr installieren lassen. Werden sie nicht angepasst, dann sind nicht kompatibel. Bei Vim scheint aber alles zu laufen. Auch wenn plug-ins mehrere Jahre alt sind.
Ein paar kleine Worte zum Thema Debugger: Auch ich benutze Debugger, aber immer seltener. Das liegt nicht primär daran, dass ich kaum noch Fehler mache (das natürlich auch ;-)) oder weil es keine perfekte Debugger-Integration in Vim gibt, sondern weil ich andere Software auf eine andere Weise als früher schreibe. Während des Studiums war ein Debugger für mich das Größte, weil man damit seinen Bubble-Sort-Code wunderschön dabei beobachten konnte, wie das zu sortierende Array langsam immer mehr an Ordnung gewinnt. Auch später habe ich bei der Programmierung unter Windows mit Visual Studio den integrierten Debugger gerne eingesetzt. Mit der Zeit wurden die Softwareprojekte immer komplexer und die zu verarbeitende Datenmenge immer größer, wodurch es immer schwieriger wurde, dem Debugger die zur Auffinden eines Fehlers benötigten Informationen zu entlocken, denn: - Ein Debugger kann immer nur eine relativ geringe Anzahl von Variablen sinnvoll darstellen. - Oft kennt man zwar die zu erwartenden Endergebnisse eines Algorithmus, nicht aber die dorthin führenden korrekten Zwischenergebnisse. - Bei Echtzeitanwendungen (bspw. Regelungen) kommt noch erschwerend hinzu, dass ein Programm nicht ohne weiteres unterbrochen und wieder fortgesetzt werden kann. Beim Bubble-Sort, den man zu Testzwecken auf ein Array mit 10 Elementen anwendet war das alles kein Problem. Man setzte einfach einen Breakpoint auf das Ende der Swap-Operation und konnte dann nach jedem Schritt die Korrektheit verifizieren. Einen Kontrast dazu stellen bspw. Bildverarbeitungsanwendungen dar, wo dieses Vorgehen nicht einmal ansatzweise funktioniert. Wer möchte sich schon die numerischen RGB-Werte von ein paar Millionen Pixel anschauen und entscheiden, ob diese korrekt sind oder nicht? Entsprechendes gilt für praktisch alle Anwendungen, die mit großen Datenmengen arbeiten und die zu Testzwecken nicht herunterskaliert werden können. Das Hauptproblem besteht IMHO darin, dass sich die Debugger-Technik in den letzten 30 Jahren bei Weitem nicht so schnell weiterentwickelt hat wie die Komplexität von Softwareprojekten gestiegen ist. Deswegen sind zusätzliche Debugging-Tools gefragt, bspw. - Tools zur grafischen Aufbereitung von Daten - Logging-Tools - Tools für Analyse der geloggten Daten - u.v.m. Hinzu kommen noch einige nicht anwendungsspezifische Tools bspw. zum Auffinden von Memory-Leaks, Buffer-Overflows und dergleichen (Valgrind) und noch vieles mehr. Es wäre völlig unsinnig, all diese Tools in eine IDE packen zu wollen, zumal es sich dabei oft um anwendungsspezifische Entwicklungen handelt, die man deswegen auch selber in die IDE integrieren müsste. Das würde viel Zeitaufwand mit wenig resultierendem Nutzen bedeuten. So gesehen ist klassische Debugger nicht das zentrale Debugging-Tool, sondern nur eines von vielen, die gleichberechtigt nebeneinander stehen. Genauso wie alle anderen wird der Debugger bei Bedarf für eine ganz bestimmte Klasse von Fehlern herangezogen. Hat er seine Aufgabe erfüllt, liegt er vielleicht wieder eine Woche lang ungenutzt herum. Ich verwende Debugger nach wie vor, aber nicht integriert in einen Editor oder eine IDE, sondern als Stand-Alone-Anwendung, die erst dann gestartet wird, wenn sie wirklich gebraucht wird. Die Auswahl reicht vom nackten GDB über einfache GUI-Frontends (kdbg, nemiver) bis hin zum Stand-Alone-Debugger von Eclipse. Für die paar Male pro Monat, wo ich tatsächlich einen Debugger benötige, ist GDB-TUI völlig ausreichend. Ich habe dabei Zugriff auf sämtliche GDB-Features (auch die ganz neuen, die noch in keine IDE Einzug gehalten haben), und das bei durchaus akzeptabler Ergonomie. Das allerwichtigste Debugging-Tool ist aber immer noch der eigene Kopf. Er kann in mehreren unterschiedlichen Modi betrieben werden, die beiden wichtigsten sind: - Man liest den Quellcode in der Umgebung, wo der Fehler vermutet wird, durch und fragt sich bei jedem Abschnitt, warum man das so gemacht hat. Wenn man für diese Überlegung länger als eine Minute braucht, schreibt man das Ergebnis am Besten gleich als Kommentar in den Code. Des Weiteren überlegt man sich, mit welchen fiesen Daten man den Algorithmus am ehesten zum Versagen bringen könnte, und ob diese Daten tatsächlich in dieser Form auftreten können. Die Chancen stehen gut, dabei auch Fehler zu finden, die bisher gar nicht aufgetreten sind. - Man schaltet den PC aus und tut etwas Entspannendes (bspw. spazieren gehen, duschen oder auf dem Sofa liegen). Dann lässt man den Programmablauf im Geiste vorüberziehen. Aber nicht im Single-Step und mit detaillierten Datentypen wie im Debugger, sondern mathematisch/ logisch auf hoher Abstraktionsebene. Irgendwann macht es dann Klick, also ob man gerade in eine Breakpoint hineingelaufen wäre, und man hat den Fehler (oder zumindest einen Kandidaten dafür) gefunden. Auf diese Weise habe ich tatsächlich schon des Öfteren extrem hartnäckige Fehler gefunden, die sich zuvor trotz größter Anstrengung mit keinem Software-Tool lokalisieren ließen. Vielleicht gibt es für so etwas ja irgendwann einen KI-Debugger, aber derzeit muss dafür noch die NI herhalten, und das wird sicher noch viele Jahre so bleiben. Während ich dies schrieb, habe ich mich gefragt, ob ich mit meiner Arbeitsweise alleine dastehe, und deswegen mal gegoogelt, was andere über dieses Thema denken. Dabei bin ich u.a. auf zwei interessante Artikel gestoßen: https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/ https://blog.jgc.org/2007/01/tao-of-debugging.html Im ersten werden einige prominenter Softwareentwickler genannt, die dem klassischen Debugger ebenfalls skeptisch und teilweise sogar ablehnend gegenüberstehen. Sie heißen Linus Torvalds (Linux), Guido van Rossum (Python), Brian W. Kernighan (Unix), Rob Pike (Unix, Go) und Robert C. Martin (Agile Programming). Wenn man länger suchen würde, würde man sicher noch weitere finden. Aber zurück zum Thema: Ich habe gerade entdeckt, dass bei Vim seit gut eineinhalb Jahren ein Frontend (Termdebug) für GDB im Lieferumfang enthalten ist. Mal sollte vielleicht öfter mal die Release-Notes lesen ;-) Hier ist ein Screenshot von Bram: https://www.vim.org/images/terminal_debugger.png Mein erster Eindruck: Spartanisch, Vim-typisch nicht als Eye-Catcher ausgelegt, aber funktionell und vollständig. Man könnte es vielleicht beschreiben als GDB-TUI im Editor mit ein paar netten Mausfunktionen (Buttons für Step, Next usw. und Anzeige von Variableninhalten per Mouse-Hover). Ich werde evtl. noch ein paar Shortcuts hinzufügen und es dann künftig anstelle von GDB-TUI verwenden (die paar Male, wo ich so etwas tatsächlich brauche).
Du musst den in einer IDE vorhandenen Debugger nicht benutzen, aber du darfst und kannst bei Bedarf. Ich z.B. starte aue Eclipse heraus eine ganze Reihe von Debuggern (MPLABX, Lauterbach Trace32, Green Hills...). Das geht also nach wie vor dass du externe Tools in deinen Workflow integrierst. Lediglich für den gdb bringt Eclipse per default eine recht gute Integration mit, wobei Eclipse nur die GUI mitbringt, im Hintergrund läuft ein handelsüblicher gdb oder avr-gdb (Wobei ich diesen unter Linux leider nie verlässlich zusammen mit avarice und dem Dragon zum laufen gebracht habe, egal ob mit oder ohne Eclipse). Aber du hast recht, komplexe Applikationen debuggt man heute eh ganz anders. Der Hardware-Debugger ist eigentlich nur hei hardwarenahem Zeugs noch richtig nützlich.
:
Bearbeitet durch User
Yalu X. schrieb: > Auf diese Weise habe ich tatsächlich schon des Öfteren extrem > hartnäckige Fehler gefunden, die sich zuvor trotz größter Anstrengung > mit keinem Software-Tool lokalisieren ließen. Ich habe gestern auch erst wieder einen Bug gefunden, den ich vorher trotz intensiver Suche und Testcode nicht gesehen habe … Daraufhin habe ich beschlossen, das existierende API neu mit selbst geschriebenem Inhalt zu befüllen (der vorherige stammte teilweise aus Atmels ASF) – und beim drüber Nachdenken fiel mir sofort wie Schuppen aus den Haaren, was im ASF-geerbten Code falsch war. ;-) (Zur ihrer Ehrenrettung: in neueren Versionen hatten sie den Bug auch bereits korrigiert.) Ansonsten debuggen wir auch häufig genug mit dem Logic Analyzer, da kann man einfach mit ein paar GPIOs bestimmte interne Zustände verfolgen lassen und so trotzdem noch alles in Echtzeit tuckern lassen. Der GDB ist aber dennoch häufig mal mit von der Partie. Le X. schrieb: > (Wobei ich diesen unter Linux leider nie verlässlich zusammen mit > avarice und dem Dragon zum laufen gebracht habe, egal ob mit oder ohne > Eclipse). Ja, das liegt teilweise auch an der Art und Weise, wie diese Atmel-Tools seinerzeit in AVR Studio eingebunden worden sind. Das war eine grundlegend andere Herangehensweise als GDB, was dazu führt, dass GDB unverhältnismäßig viele low-level-Aktionen auf den ICEs angeworfen hat, die aber wiederum wegen der Arbeitsweise von Atmel Studio im ICE relativ schwerfällig abgearbeitet worden sind. Mit dem Übergang auf den Visual Studio hat sich das auch in den Atmel-Tools geändert, denn deren Debugger ist von der Funktionsweise grundlegend genauso low-level wie GDB. (Leider ist die AVaRICE-Einbindung dieser Tools nie wirklich komplett vernünftig fertig geworden. Das berührt dich aber für den Dragon sowieso nicht. ;-)
Jörg W. schrieb: > Ansonsten debuggen wir auch häufig genug mit dem Logic Analyzer, da kann > man einfach mit ein paar GPIOs bestimmte interne Zustände verfolgen > lassen und so trotzdem noch alles in Echtzeit tuckern lassen. Oh noch einer mit dieser Idee. Ich hab das mit dem PCI-Bus Analyzer gemacht, einfach auf Read only Register Werte geschrieben :) Die Kollegen haben mich vorher für verrückt erklärt bis die dann sahen wie gut das geht. Ist super für Echtzeit. :)
:
Bearbeitet durch User
Jörg W. schrieb: > Das war eine grundlegend andere Herangehensweise als GDB, was dazu > führt, dass GDB unverhältnismäßig viele low-level-Aktionen auf den ICEs > angeworfen hat, die aber wiederum wegen der Arbeitsweise von Atmel > Studio im ICE relativ schwerfällig abgearbeitet worden sind. Ja, so ungefähr hat sich das angefühlt. Sehr träge und nach kurzer Zeit ging die Verbindung zum Target verloren und mein PC in die Knie ;-) Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig zu debuggen?
Le X. schrieb: > Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig > zu debuggen? Du könntest dir mal den SVN-Stand von AVaRICE mit einem aktuellen Debug-Tool (Atmel-ICE, EDBG *) ansehen. Ich bin mit der Stabilität nicht wirklich zufrieden, allerdings wäre das nur mit einem Rundumschlag zu korrigieren, zu dem ich keine Energie habe. (OpenOCD kann mit den Dingern praktikabel umgehen, es geht also, wenn man es ordentlich aufzieht.) *) EDBG ist der eingebaute Debugger, der auf vielen Xplained-Boards zu finden ist. Den kann man auch abtrennen, ist dann eine deutlich preiswertere Variante als das Atmel-ICE. Das Atmel-ICE gibt's auch als reines PCB, das war mal in der gleichen Preisklasse wie der Dragon, inzwischen hat Microchip das aber alles massiv verteuert.
>Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig zu debuggen? Kommt auf den Typ an. Wenn es gut läuft, hält der SNAP eine komplette Debugsession unter MPLABX durch. Manche AVR werden erst unter dem PK4 einigermaßen zugänglich. >Arbeitet von euch noch jemand mit dem vi? Unter SSH mein std editor. Natürlich vim bevorzugt, aber hat ja nicht jedes altbackene Linux.
Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken hätten, und manche gar animierte Menüs, hat mal jemand ein Video gemacht, das ich recht nett fand: https://www.youtube.com/watch?v=84qoMxS-iqQ
Jack V. schrieb: > Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen > könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken > hätten, und manche gar animierte Menüs, Es gibt doch auch joe, ohne bunte Schaltflächen. Der funktioniert auch in der Console, ist aber bedienbar.
Joe schrieb: > Es gibt doch auch joe, ohne bunte Schaltflächen. Der funktioniert auch > in der Console, ist aber bedienbar. Mag sein, es geht im Grunde aber nicht um bunt oder nicht bunt, und auch nicht um GUI vs. CLI/TUI. Es geht auch nicht darum, dass Vim per se überlegen wäre, und am besten jeder Vim lernen müsse. Einfach mal das Video schauen, falls gerade sieben Minuten Lebenszeit übrig sind.
Jack V. schrieb: > https://www.youtube.com/watch?v=84qoMxS-iqQ Sehr gutes Video, vielen Danlk für den Link. Entscheidend für die Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und die "Expressiveness". Die Diskussionen zu "Software1 vs Software2" verlaufen oft nur deswegen (unnötigerweise) so hitzig, weil die Diskutanten die beiden Größen individuell sehr unterschiedlich gewichten. So kann ein Gelegenheitsnutzer einer Software, der naturgemäß ein hohes Gewicht auf die Discoverability legt, nur schwer nachvollziehen, dass für einen Vielnutzer die Expressiveness viel wichtiger ist, und umgekehrt.
Yalu X. schrieb: > Entscheidend für die > Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von > Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und > die "Expressiveness" Das mag schon so sein. Ich verstehe allerdings kein Wort. Oder muss das so sein, wenn man von vi spricht? Oder fühlen sich manche Leute besser, wenn sie sich unverständlich ausdrücken? Hatte zwar Englisch als Prüfungsfach im Abi, aber das geht mir wirklich etwas zu weit. Man sollte einen Text im Forum schon so schreiben, dass er von vielen verstanden wird.
Karl schrieb: > Yalu X. schrieb: >> Entscheidend für die >> Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von >> Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und >> die "Expressiveness" > > Das mag schon so sein. Ich verstehe allerdings kein Wort. Das Video nicht geschaut? Das erklärt doch gerade, was diese Wörter bedeuten.
Andi schrieb: > Das ist natürlich richtig. > Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach > effizienter zu erreichen. Also <> und ~ sind auf einer deutschen Tastatur sehr bequem zu erreichen. Ringfinger auf Shift + Mittelfinger auf > direkt daneben. Das ist jetzt nicht wirklich schwer. Ein richtiges Gewürge wird es erst bei {} und [], da muss man sich dann schon richtig verrenken. Je weiter Links das Zeichen auf der Tastatur ist, desto schlimmer. \ geht noch. } ist noch hinnehmbar. Aber alles was weiter links liegt, da verrenkt man sich die Hand. > Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit > deutschem Layout programmieren kann. Geht schon. Ist aber in der Tat umständlich.
Jörg W. schrieb: > Andi schrieb: >> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit >> deutschem Layout programmieren kann. > > Ich auch nicht. Seit ich eine deutsche Tastatur habe, habe ich daher ein > Keyboard-Mapping, bei dem die äöü-Tasten [\]/{|} geben und nur dann die > Umlaute, wenn man zugleich AltGr drückt (das passt gut mit dem rechten > Daumen zusammen). Womit setzt du das Keypboard Mapping um?
Jack V. schrieb: > Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen > könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken > hätten, und manche gar animierte Menüs, hat mal jemand ein Video > gemacht, das ich recht nett fand: > https://www.youtube.com/watch?v=84qoMxS-iqQ Das Video fängt schon mit einem Denkfehler an. Discoverability und Expressiveness schließen sich nämlich nicht gegenseitig aus. Im Video wird das aber behauptet. Auch ist die Behauptung falsch, dass man Expressivness nicht richtig in der GUI unterbringen könnte. Der Typ hat offenbar noch nie etwas von Menüs gehört. Es spricht zudem nichts dagegen, einen Editor mit einer einfachen Programmiersprache für den Editor zu kombinieren und den Plugins dann einen Button mit gegebenenfalls einem GUI Untermenü zu geben. Die einfachste Form davon dürften wohl Makros sein und das ganz bereits jeder halbwegs gescheite Editor.
Nano schrieb: > Jack V. schrieb: >> Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen >> könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken >> hätten, und manche gar animierte Menüs, hat mal jemand ein Video >> gemacht, das ich recht nett fand: >> https://www.youtube.com/watch?v=84qoMxS-iqQ > > Das Video fängt schon mit einem Denkfehler an. > > Discoverability und Expressiveness schließen sich nämlich nicht > gegenseitig aus. Im Video wird das aber behauptet. Sie schließen einander nicht streng aus, aber eine Tendenz gibt es durchaus. Man kann eben nicht beliebig viele Funktionen einbauen, ohne dass es irgendwann schwierig wird, alle schnell zu erfassen. > Auch ist die Behauptung falsch, dass man Expressivness nicht richtig in > der GUI unterbringen könnte. Kann man, aber mit Einschränkungen. > Der Typ hat offenbar noch nie etwas von Menüs gehört. Wenn du jede Funktion, die vim kann, in Menüs oder womöglich gar Toolbars stecken willst, wird das kein Mensch mehr überblicken können. Mit fünnfach verschachtelten Untermenüs, von denen jedes die komplette Höhe des Bildschirms braucht, ist das Ganze dann am Ende auch nicht mehr sonderlich discoverable.
Nano schrieb: > Womit setzt du das Keypboard Mapping um? xkb Nano schrieb: > Es spricht zudem nichts dagegen, einen Editor mit einer einfachen > Programmiersprache für den Editor zu kombinieren elisp? :-))
Jörg W. schrieb: > Nano schrieb: >> Womit setzt du das Keypboard Mapping um? > > xkb Danke. Könntest du deine xkb Datei hier mal reinstellen? Ich würde sie gerne ausprobieren. > Nano schrieb: >> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen >> Programmiersprache für den Editor zu kombinieren > > elisp? :-)) Ich bin zwar weder EMACS noch LISP Fan, aber ja, als Beispiel das es geht, ist das auch erwähnenswert.
Nano schrieb: > Discoverability und Expressiveness schließen sich nämlich nicht > gegenseitig aus. Im Video wird das aber behauptet. Hast du dasselbe Video angeschaut wie ich? Die Stelle, wo dies behauptet wird, kann ich nämlich nicht finden. Rolf hat die wesentlichen Aussagen des Videos IMHO gut zusammengefasst: Rolf M. schrieb: > Sie schließen einander nicht streng aus, aber eine Tendenz gibt es > durchaus. > ... Nano schrieb: > Es spricht zudem nichts dagegen, einen Editor mit einer einfachen > Programmiersprache für den Editor zu kombinieren Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche Programmierprachen mit :)
Nano schrieb: >> xkb > > Danke. Könntest du deine xkb Datei hier mal reinstellen? > Ich würde sie gerne ausprobieren. Bitte. Ich gehe dabei aber üblicherweise so vor, dass ich mir die existierende Belegung dumpen lasse und diese dann editiere.
Grundkenntnisse des vi oder dessen forkes gehören zu den Basics für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht!
Yalu X. schrieb: > Nano schrieb: >> Discoverability und Expressiveness schließen sich nämlich nicht >> gegenseitig aus. Im Video wird das aber behauptet. > > Hast du dasselbe Video angeschaut wie ich? Die Stelle, wo dies behauptet > wird, kann ich nämlich nicht finden. Guck dir doch die grafische Darstellung an, wo das Gegensätzlich angezeigt wird, links das eine, rechts das andere. Als ob man sich für eine der Seiten entscheiden müsste, man aber nicht beides haben könne. Und letzteres wird auch gesagt, guck es nochmal an. > Nano schrieb: >> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen >> Programmiersprache für den Editor zu kombinieren > > Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche > Programmierprachen mit :) Der Punkt ist, man kann auch eine schöne GUI mit intuitiven Menüs und trotzdem eine Programmiersprache haben. Und nein, warum vi nichts für mich ist, habe ich bereits eine Seite vorher erklärt. Die Programmiermöglichkeit allein ersetzt nämlich nicht die miserable GUI. Beim Debugger geht's schon los. Jede IDE ist da besser. Und für stinknormale Configfiles brauche ich die Features eines vi nicht, da reicht nano.
Rolf M. schrieb: > Karl schrieb: >> Yalu X. schrieb: >>> Entscheidend für die >>> Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von >>> Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und >>> die "Expressiveness" >> >> Das mag schon so sein. Ich verstehe allerdings kein Wort. > > Das Video nicht geschaut? Das erklärt doch gerade, was diese Wörter > bedeuten. Geschaut schon. Verstanden, nein. Mir ist es aber auch nicht so wichtig, jetzt massiv Zeit in die Übersetzung zu stecken.
Nano schrieb: > Guck dir doch die grafische Darstellung an, wo das Gegensätzlich > angezeigt wird, links das eine, rechts das andere. Diese Darstellung (die beiden Begriffe verbunden mit einer Linie) und den Text dazu ("fundamentally user interfaces can be placed on a spectrum of sorts") habe ich so verstanden, dass es zwischen dem linken und dem rechten Ende beliebig viele Zwischenstufen gibt, also vergleichbar mit einer Schwarz-Weiß-Skala, die nicht nur die beiden Extremwerte, sondern auch alle Zwischenwerte (Graustufen) enthält. Nano schrieb: > Der Punkt ist, man kann auch eine schöne GUI mit intuitiven Menüs und > trotzdem eine Programmiersprache haben. Empfindest du die Menüs von gvim als unintuitiv? Ich würde sagen, intuitiv und "discoverable" sind sie schon, nur halt sehr unvollständig (also wenig "expressive"), weswegen sie kaum ein Vim-User benutzt.
vi(m) ist heute doch wirklich obsolet. Nutzen nur noch ein paar ergraute Nerds, die früher nichts anderes hatten. Um nicht missverstanden zu werden. Gute Editoren auf der Shell sind unverzichtbar. Nicht nur wenn man mit SSH arbeitet. Aber nano ist viel einfacher und mittlerweile gibt es selbst für Programmierer auf der Shell moderne Alternativen wie den NiceEditor. Und warum nutzt man heutzutage keine Curortasten und muss erst in verschiedene Modi umschalten um navigieren zu können? Und selbst die Möglichkeiten mit grafischen Editoren Dateien remote zu bearbeiten sind heute gegeben. Ich habe auch schon in den 80ern mit dem Programmieren begonnen. Bin aber mit der Zeit gegangen und nicht bei vi hängen geblieben.
Nano schrieb: > Der Typ hat offenbar noch nie etwas von > Menüs gehört. Hattest du das Video wirklich geschaut? Bei etwa 2m55s wird das Problem damit anschaulich dargestellt. Das größere Problem ist, dass Jobs, die im Vim mit drei, vier Tastendrücken erledigt sind, sich nicht mal sinnvoll in Menüs abbilden lassen. So simple Sachen, wie beispielsweise „lösch doch bitte alle Buchstaben zwischen den aktuellen Quotes“, oder auch „lösch doch bitte alles bis zum nächsten Auftreten von Zeichen x“ oder auch „ersetze doch bitte alle x in der aktuellen Zeile durch y“, und so weiter. Das noch viel größere Problem ist, dass jemand, der nahezu ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei Strg-Tastenkombis nutzt, keine Vorstellung davon hat, wie’s ist, gar nicht drüber nachzudenken, wie etwas zu machen ist, sondern das einfach macht. Ist, wie das Zehnfingerschreiben: so, wie ich nicht drüber nachdenke, welche Tasten ich drücken muss, damit ein bestimmtes Wort auf dem Bildschirm erscheint, muss ich bei einem Editor, mit dem ich mich auskenne, nicht drüber nachdenken, welche Tasten ich drücken muss, damit eine bestimmte Aktion ausgeführt wird. Und dass jeder Griff zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden, der’s halt nicht kennt, auch nicht mental zu erfassen. Insofern bringt’s eigentlich auch nichts, da weiter Zeit zu versenken. Wen’s interessiert, warum manche Menschen solche Programme mögen, der findet im verlinkten Video eine mögliche Erklärung. Für den habe ich das verlinkt. Wer hingegen drauf aus ist, alle, die Sachen anders als sie selbst machen, als doof hinzustellen, der wird sich einzelne Ausdrücke aus dem Video herauspicken und solange darauf rumreiten, bis er sich überlegen fühlt. War schon immer so, wird immer so sein – so what?
:
Bearbeitet durch User
member of the big Johnson community schrieb: > Ne vi diskussion - im Jahre 2022. Die 90er haben gerade angerufen. nerd schrieb: > vi(m) ist heute doch wirklich obsolet. Nutzen nur noch ein paar > ergraute Nerds, … Tja, bei euren hochgradig cleveren Kommentaren drängt sich dem Beobachter sofort der Verdacht eines kreisförmigen Familienstammbaums auf.
Jörg W. schrieb: > Nano schrieb: > >>> xkb >> >> Danke. Könntest du deine xkb Datei hier mal reinstellen? >> Ich würde sie gerne ausprobieren. > > Bitte. > > Ich gehe dabei aber üblicherweise so vor, dass ich mir die existierende > Belegung dumpen lasse und diese dann editiere. Danke. Bisher habe ich eine x Keymap nicht bearbeitet.
Yalu X. schrieb: > Nano schrieb: >> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen >> Programmiersprache für den Editor zu kombinieren > > Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche > Programmierprachen mit :) Aus dem Kontext und meinen vorherigen Kommentaren weißt du ab er, das Vim viel fehlt und es viel zu kritisieren gibt. Also nein, er ist nicht die Lösung.
Jack V. schrieb: > Das größere Problem ist, dass Jobs, die im Vim mit drei, vier > Tastendrücken erledigt sind, sich nicht mal sinnvoll in Menüs abbilden > lassen. So simple Sachen, wie beispielsweise „lösch doch bitte alle > Buchstaben zwischen den aktuellen Quotes“, oder auch „lösch doch bitte > alles bis zum nächsten Auftreten von Zeichen x“ oder auch „ersetze doch > bitte alle x in der aktuellen Zeile durch y“, und so weiter. Es gibt zu Menüs auch Shortcuts. Beispielstring:
1 | string str = "Das ist ein Text."; |
In Nano: Cursor in Zeile platzieren. ALT + G STRG + T " eingeben + Enter drücken 1 cursor nach rechts ALT + A = Markerung gesetzt ALT + G STRG + T " eingeben + Enter drücken STRK + K Fertig. Und wenn du es schneller willst, erstellt du halt ein Makro. Und wenn du das hier willst: > "„lösch doch bitte > alles bis zum nächsten Auftreten von Zeichen x“ dann ersetzt du das zweite " durch ein x. > "„ersetze doch > bitte alle x in der aktuellen Zeile durch y“, Und so etwas kann so gut wie jeder Editor mit einer Suchen und Ersetzen Funktion. In der Regel genügt es, den Cursor in die gewünschte Zeile zu bringen und dann die S&E Funktion zu starten. Die meisten Editoren beginnen dann genau in der Zeile. Trivial. > Das noch viel größere Problem ist, dass jemand, der nahezu > ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei > Strg-Tastenkombis nutzt, keine Vorstellung davon hat, wie’s ist, gar > nicht drüber nachzudenken, wie etwas zu machen ist, sondern das > einfach macht. Blödsinn. Die Menüs nutzt man für selten benötigte Funktionen, die sich dann allein dadurch, dass man sieht, was in den Menüs verfügbar ist, erschließen. Für Dinge, die man öfters nutzt, lernt man die Shortcuts, also Tastaturkürzel oder legt sich Makros an. Beim Vim müsstest du jetzt bei Ersterem ewig im Handbuch oder deinen Notizen, falls du welche erstellt hast, suchen um nochmal zu sehen, wie es ging und eine gescheite Debugger Ansicht (siehe 1. Seite) hat Vim damit immer noch nicht. Vim ist nämlich halt keine IDE und das ist das, was ich brauche, wenn ich mehr machen will, als nur simple Configs editieren möchte. Und für die Configs reicht mir nano, der in seinen Editiermöglichkeiten Ausdrucksstark genug ist, siehe oben. > Ist, wie das Zehnfingerschreiben: Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem nach Lehrbuch, sondern macht sich was eigenes. > so, wie ich nicht > drüber nachdenke, welche Tasten ich drücken muss, damit ein bestimmtes > Wort auf dem Bildschirm erscheint, Das muss ich auch nicht und ich nutze das 10 Fingersystem nicht, sondern nur meine 10 Finger. Und ja, ich kann das auch im Dunkeln. > muss ich bei einem Editor, mit dem > ich mich auskenne, nicht drüber nachdenken, welche Tasten ich drücken > muss, damit eine bestimmte Aktion ausgeführt wird. Natürlich musst du das, gerade bei seltener benutzen Funktionen, die du ganz selten brauchst musst du das. Und das müsstest du auch in einer Shell, wenn wir jetzt mal die Analogie der CLI dazu nehmen. Und ab hier gewinnt dann der Editor mit intuitivem Menü. > Und dass jeder Griff > zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich > und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden, > der’s halt nicht kennt, auch nicht mental zu erfassen. Du verschwendest deine Zeit zum Suchen selten benutzter Funktionen und einer unzureichenden Debugger Ansicht. Da gewinnt jede IDE. Zumal man beim Programmieren mehr Zeit zum Nachdenken verbringt, als zum Tippen. Daher würde auch ein Wechsel zur Maus nicht viel ausmachen. Zumal der ab und zu Wechsel zur Maus gesund ist. Es ist nämlich ungesund, immer in der gleichen Position zu verharren. Übrigens auch der Grund, warum das 10 Fingersystem überholt ist. > Wer hingegen drauf aus ist, alle, die Sachen anders als sie > selbst machen, als doof hinzustellen, ... Du sprichst von dir selbst, deine Wortwahl: 1. > dass jemand, der nahezu > ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei > Strg-Tastenkombis nutzt, keine Vorstellung davon hat, 2. > Und dass jeder Griff > zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich > und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden, > der’s halt nicht kennt, auch nicht mental zu erfassen.
Ich will deinen Text nun nicht in Gänze zerlegen: Dass Vim nix für dich ist, hast du ja nun zur Genüge dargelegt, und ich habe auch überhaupt kein Problem damit – insbesondere käme mir nicht mal die Idee, dir die überhaupt die weitere Beschäftigung mit dem Programm nahelegen zu wollen. Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst, es schlechtzumachen; deswegen gehe ich mal auf ein Beispiel ein: Nano schrieb: > Beispielstring:string str = "Das ist ein Text."; > > In Nano: > Cursor in Zeile platzieren. > ALT + G > STRG + T > " eingeben + Enter drücken > 1 cursor nach rechts > ALT + A = Markerung gesetzt > ALT + G > STRG + T > " eingeben + Enter drücken > STRK + K > > Fertig. Beim Vim: Cursor in der Zeile irgendwo vor oder innerhalb der Quotes positionieren di" [Enter] Fertig. Vergleiche halt selbst, ob du tatsächlich das gezeigt hast, was du gezeigt haben wolltest – möglicherweise ist das nicht ganz gelungen. Selbst, wenn du alles mit Makros nachstellen könntest (was ich bezweifele, denn es fehlen die dazu notwendigen Modi): warum, um Bobs Willen, sollte man sich dann ein Jahr lang hinsetzen und einen anderen Editor anpassen, statt einfach Vim zu nehmen? Nano schrieb: > Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine > 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem > nach Lehrbuch, sondern macht sich was eigenes. Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du meinst das Layout – QWERTZ ist in der Tat nicht optimal. Ich nutze daher Neo2 – was übrigens ziemlich gut mit Vim harmoniert. Aber das war gar nicht der Punkt – ich ich hoffe wirklich sehr, dass du das selbst weißt. Der Punkt war, dass man nach einiger Zeit nicht drüber nachdenken muss, wie man zu dem gewünschten Ergebnis kommt, sondern es reicht, das gewünschte Ergebnis vor Augen zu haben. Was übrigens auch ein Grund sein mag, warum Nichtzehnfingerschreiber das nicht erfassen können: die Tastenfolgen (Obacht: keine Tastenkombinationen) sind letztlich kurze Wörter, die übrigens sogar einem leicht merkbaren Schema folgen, so dass man sich eben nicht hinsetzen und auswendig lernen muss. Und es ist keine Abwertung, wie du hier reindichten zu wollen scheinst, sondern eine Feststellung. Auch in den anderen Punkten zeigst du zeigst du gerade anschaulich, was ich hier mit Worten zu sagen versuchte: Jack V. schrieb: > Wer hingegen drauf aus ist, alle, die Sachen anders als sie > selbst machen, als doof hinzustellen, der wird sich einzelne Ausdrücke > aus dem Video herauspicken und solange darauf rumreiten, bis er sich > überlegen fühlt. Was ist eigentlich dein Problem damit, dass Leute mit dem Vim ziemlich gut klarkommen und ihn gar mögen? Trauma vom ersten Start vom Vim, als du gefangen warst und nicht wieder rausgefunden hattest? Ging eigentlich jedem so, den ich kenne und der mit Vim in Berührung gekommen ist – aber so eine Auswirkung, wie hier zu beobachten, hat’s bei keinem gehabt.
:
Bearbeitet durch User
Jack V. schrieb: > Trauma vom ersten Start vom Vim, als du gefangen warst und nicht wieder > rausgefunden hattest? Manche benutzen ihn seit 30 Jahren weil sie bisher nicht rausgekommen sind. Andere kennen kill -9
Hans schrieb: > Andere kennen kill -9 … und ärgern sich danach über das unbenutzbare Terminal. Wieder andere kennen kill -1. :^)
Walter K. schrieb: > Grundkenntnisse des vi oder dessen forkes gehören zu den Basics > für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht! Seh ich auch so. Zumindest wie man rauskommt sollte man wissen.
Le X. schrieb: > Walter K. schrieb: >> Grundkenntnisse des vi oder dessen forkes gehören zu den Basics >> für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht! > > Seh ich auch so. > Zumindest wie man rauskommt sollte man wissen. Na wie man's bei Windows gelernt hat: Alt-Ctrl-Del, warten bis der Bildschirm dunkel wird(**), warten bis der Bildschirm hell wird, fertig. (**) Für die schweren Fälle gibt's auch noch: ›Have you tried turning it off and on again?‹
Le X. schrieb: > Zumindest wie man rauskommt sollte man wissen. Stimmt, und das ist auch das Einzige, was ich kann :-) Ansonsten verwende ich den Nano in den seltenen Fällen, wenn ich auf einer reinen Textshell arbeite. Der ist dem alten WordStar nachempfunden (kennt den noch jemand? 80er Jahre? CP/M? Z80-Dampfmaschinen mit ASCII-Terminals? Grüne BAS-Monitore? Ach war dat schön damals...) Damit habe ich meine ersten Assembler- und Pascal-Sourcecodes geschrieben und bin daher mit Nano sofort klargekommen, obwohl zwischen CP/M und Linux das beinahe 15 Jahre andauernde dunkle DOS/Windows-Zeitalter lag.
vi, emacs ist doch in Wahrheit eine medizinische Anwendung. Die endlosen Tastaturkürzel dort dienen wunderbar als Übungen für Gelenkartrose und Gicht. Fitnessprogramm für die Gichtkrallen. Leute die sowas nutzen, können keine Maus bedienen, damit rosten die Fingergelenke ein und schmerzen, mit vi+emacs sind die Gelenke immer in Bewegung und beugen weiteren Entzündungen vor.
nerd schrieb: > Nutzen nur noch ein paar ergraute Nerds, die früher nichts anderes hatten. member of the big Johnson community schrieb: > Leute die sowas nutzen, können keine Maus bedienen Warum muss eigentlich immer gleich gegen die Nutzer der Software gegiftet werden? Ich könnt auch sagen: "Leute, die Klickibunti-Editoren benutzen, sind zu blöd, sich Tastenkürzel zu merken oder ins Handbuch zu schauen". Das sage ich nur nicht (hier steht's nur zu demonstrativen Zwecken), weil ich verstehe, dass es Leute gibt, die das bevorzugen, und weil es mich überhaupt nicht stören sollte, wenn andere keinen vim benutzen.
:
Bearbeitet durch User
member of the big Johnson community schrieb: > können keine Maus bedienen, damit rosten die > Fingergelenke ein und schmerzen, Bei der Mausbedienung hingegen werden die Fingergelenke ständig trainiert, besonders bei den heute üblichen beidhändigen Zehntastenmäusen mit Bildschirmtastatur.
Rolf M. schrieb: > Warum muss eigentlich immer gleich gegen die Nutzer der Software > gegiftet werden? Weil man seine eigene Entscheidung gegen sich selbst verteidigen muss? Das geht am einfachsten, indem man alle anderen für doof und unfähig erklärt.
Nano schrieb: > Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine > 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem > nach Lehrbuch, sondern macht sich was eigenes. Wichtig ist, blind schreiben zu können. Kannst Du das?
Jack V. schrieb: > Nano schrieb: >> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine >> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem >> nach Lehrbuch, sondern macht sich was eigenes. > > Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du > meinst das Layout – QWERTZ ist in der Tat nicht optimal. IMHO meint er damit sein individuelles Zehnfingersystem auf einem normalen Tastaturlayout. Das Lehrbuchzehnfingersystem ordnet jeder Taste einen bestimmten Finger zu, die Hände bleiben dabei immer mehr oder weniger an derselben Position. Das ist ein recht starres, speziell auf das Tippen von Fließtext auf einer Schreibmaschine optimiertes Konzept. Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten usw.) aus der fixen Handposition heraus gar nicht erreichbar sind. Wenn man aber die Hände sowieso bewegen muss, kann man auch gleich die feste Zuordnung von Fingern zu Tasten aufheben. Stattdessen wird eine Taste immer von demjenigen Finger betätigt, der sich gerade in der jeweils günstigsten Position befindet, so wie es auch ein Klavierspieler tut. Durch die Einbeziehung von Armbewegungen in die Tipparbeit verlieren auch die auf dem deutschen Tastaturlayout erforderlichen "krummen" Tastenkombinationen für einige Sonderzeichen (bspw. AltGr+{) viel von ihrem Schrecken. Auch ich nutze ganz intuitiv dieses "dynamische" Zehnfingersystem, muss allerdings gestehen, dass ich das klassische Zehnfingersystem trotz einiger Anläufe nie richtig gelernt und somit keinen direkten Vergleich habe.
Bert schrieb: > Benutzt auch noch jemand elvis? > War vor Jahren bei Linux mal der Hype. Elvis lebt. Ach ne, das ist ein anderer ;-)
Jede Generation hat ihre favorisierte Software. Das ist ganz normal und nicht schlimm.
Jack V. schrieb: > Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es > niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst, > es schlechtzumachen; Das machst du, siehe oben, da habe ich das belegt. Ich habe lediglich meine Meinung dazu gesagt und jetzt hast du ein Problem damit, sie zu akzeptieren, auch wenn du in deinem Eingangssatz gegenteiliges behauptest, so sieht man es hier. > deswegen gehe ich mal auf ein Beispiel ein: > > Nano schrieb: >> Beispielstring:string str = "Das ist ein Text."; >> >> In Nano: >> Cursor in Zeile platzieren. >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> 1 cursor nach rechts >> ALT + A = Markerung gesetzt >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> STRK + K >> >> Fertig. > > Beim Vim: > Cursor in der Zeile irgendwo vor oder innerhalb der Quotes positionieren > di" [Enter] > > Fertig. Mit anderen Worten, du kannst und willst nicht akzeptieren, dass andere Editoren das auch können. Das ist dein Problem, arbeite mal an dir! Und ich sagte dir bereits, dass nano Makros beherrscht, falls dir bekannt sein sollte, was das ist. Die kann man anlegen, dann ist das ein Tastendruck. Übrigens und das ist auch so ein Punkt, der dir hier nicht auffällt. Nano zeigt Kontextabhängig die Tastaturkommandos in der unteren Leiste an. Deswegen lässt sich obiges bei Nano auch ganz leicht intuitiv erschließen. Die angezeigten Tastaturkommandos sind somit praktisch bereits ein Menü. Du musst da also nicht di auswendig lernen. Mal abgesehen davon, das dein Befehl nicht das tut, was du hier behauptest. Selbst wenn ich ein : davor setze, macht er nicht das, was du behauptest. Da kommt dann: [code] System str = "Dies ist ein Text.\n"; ~ ~ ~ :di Type Name Content c ": id c "% test.txt Press ENTER or type command to continue [/quote] Und wenn man ENTER drückt, passiert gar nichts. Wenn ich das : weglasse und nur den Cursor in den String zwischen den " plaziere und dann di eingebe, dann passiert erst mal gar nichts und wenn man es dann gleich nochmal schreibt, wird "di" in den StrinG eingetragen. Was wohl daran liegt, so weit ich mich an Vim noch erinnern kann, dass das erste i als Insert Kommando verstanden wird. Wie dem auch sein, so wie du deine Anweisung beschreibst funktioniert es nicht. Getestet mit VIM - Vi IMproved 8.2 auf dem Raspberry Pi. > Vergleiche halt selbst, ob du tatsächlich das gezeigt hast, was du > gezeigt haben wolltest – möglicherweise ist das nicht ganz gelungen. Keine Ahnung was du jetzt wieder sagen willst, die nano Anweisung tut was sie soll und nano kann das. Du wurdest also wiederlegt, finde dich damit ab. > Selbst, wenn du alles mit Makros nachstellen könntest (was ich > bezweifele, denn es fehlen die dazu notwendigen Modi): warum, um Bobs > Willen, sollte man sich dann ein Jahr lang hinsetzen und einen anderen > Editor anpassen, statt einfach Vim zu nehmen? Warum ich vim nicht als IDE Ersatz nehme, habe ich dir ja jetzt zur Genüge erklärt. Lies dazu vor allem auch mal meine alten Kommentare eine Seite vorher. Warum ist es so schwer für dich zu akzeptieren, dass nicht jeder das nehmen will, was du nimmst? > Nano schrieb: >> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine >> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem >> nach Lehrbuch, sondern macht sich was eigenes. > > Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. NEIN! Das Zehnfingersystem ist ein Eigenname und es ist ein System, das damit anfängt, dass man, ich glaube es war der Zeigefinger, die Hände in einer Grundhaltung so auf die Tastatur legt, dass der linke Zeigefinger (bei einem deutschen oder US Layout) auf dem F liegt und der rechte auf dem J. Diese beiden Tasten haben nämlich, wenn du mal auf deine Tastatur guckst, auf den meisten Tastaturen dafür eine kleine Erhebung auf diesen beiden Taste, so dass sie sich vom Rest der anderen Tasten abheben und blind ertasten lasen. Diese sind für das Zehnfingersystem da. Die anderen drei Finger werden dann entsprechend links bzw. rechts davon dann auf die Tasten A, S, D und K, L, Ö platziert und wenn man dann die beiden Hände so über der Tastatur hält, dann ist das die Grundhaltung des 10 Fingersystems. Ziel des ganzen ist nun, von dieser Grundposition alle anderen Tasten schnell und effizient zu erreichen. Und falls du dich fragst, warum diese ASDF und JKLÖ Tasten keine Buchstaben sind, die extrem häufig benöntigt werden, dann liegt das daran, dass die klassischen Schreibmaschinenlayout deswegen kein Dvorak Tastaturlayout ist, weil die Schreibmaschinen kleine Hammer hatten, die beim Drück der Taste auf das Papier geschleudert wurden und somit einen Hin- und Rückweg hatten und die sich beim Schreiben möglichst nicht mit anderen Tastenhammern verharken sollten. Mit den Computern fiel dieses Problem weg, aber Mio Schreibkräfte waren bereits an die Schreibmaschine gewöhnt, so dass man das Layout beibehielt. > Du > meinst das Layout – QWERTZ ist in der Tat nicht optimal. Nein, lerne was DAS ZehnfingerSYSTEM ist. Das kommt schon vom Namen SYSTEM her. Da geht es nicht einfach nur darum, dass man 10 Finger benutzt, sondern dass man die 10 Finger auf eine ganz bestimmte Weise verwendet. Und dieses System wurde viele Jahre lang in den Schreibmaschinenkursen, die es früher noch gab, beigebracht. > Was ist eigentlich dein Problem damit, dass Leute mit dem Vim ziemlich > gut klarkommen und ihn gar mögen? Was kapierst du eigentlich nicht? Deine Erwartungshaltung ist: "Wer mit Vim einmal beginnt, der wird es als einzige Wahre Braut ansehen und noch noch damit schreiben." Und wenn deine Erwartungshaltung dann nicht erfüllt wird, dann lautet dein Motto: "Gegen jeden, der es wagt vim zu kritisieren und nicht als Editor zu nutzen, gegen den ziehe ich in den Krieg." Das ist deine Einstellung, die du hier an den Tag legst und dann fragst du mich ernsthaft so einen Blödsinn wie oben? Warum ich Vim nicht nutze, das habe ich oben bereits argumentativ und objektiv erklärt, lerne mal damit umzugehen. Ist ja schlimm so ein Verhalten. Und hier sieht man dann auch, dass du jeden persönlich angreifst, der vim nicht nutzen will: Jack V. schrieb: > Trauma vom ersten Start vom Vim, als > du gefangen warst und nicht wieder rausgefunden hattest? Man wird also, wenn man dir nicht folgt und auch vim nutzt, von dir persönlich angegriffen und bekommt von dir dann vorgeworfen: 1. ein Trauma zu haben. 2. gefangen zu sein. Und aus deinen vorherigen Postings: 3. keine Vorstellung zu haben. 4. und mental nicht in der Lage zu sein, es zu erfassen. Fazit: Komm mal mit dir klar Junge!
Norbert schrieb: > Le X. schrieb: >> Walter K. schrieb: >>> Grundkenntnisse des vi oder dessen forkes gehören zu den Basics >>> für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht! >> >> Seh ich auch so. >> Zumindest wie man rauskommt sollte man wissen. > > Na wie man's bei Windows gelernt hat: > Alt-Ctrl-Del, warten bis der Bildschirm dunkel wird(**), warten bis der > Bildschirm hell wird, fertig. Dein letztes Windows hatte wohl noch einen DOS Kernel. Unter einem Windows NT System landest du mit ALT+CTRL+DEL im Loginbildschirm und kannst dich dann als Administrator anmelden. Siehe hier: https://www.youtube.com/watch?v=9pSIgX29dP4 Die Tastenkombination CTRL+ALT+DEL um den Rechner neu zu starten ist übrigens eine BIOS Funktion und kommt daher vom BIOS und nicht von Windows. DOS nutzt noch die BIOS Funktionen, Windows NT aber nicht mehr.
Nano schrieb: > dass nano Makros beherrscht, falls dir bekannt sein sollte, was das ist. > Die kann man anlegen, dann ist das ein Tastendruck Der Haken ist: die musst du eben auch erst anlegen. Emacs hat auch welche, habe ich aber noch nie gebraucht. Ich finde die diversen Modi bei vi auch ätzend, wirklich zeitgemäß waren sie wohl schon zu Zeiten seiner Einführung nicht *), aber trotzdem kann ich akzeptieren, dass es viele Leute gibt, die damit gut zurecht kommen und würde diejenigen nicht als altmodisch betiteln. *) Diskussionen dazu kann man im Netz genügen nachlesen, müssen wir hier nicht wiederkäuen.
vancouver schrieb: > Le X. schrieb: >> Zumindest wie man rauskommt sollte man wissen. > > Stimmt, und das ist auch das Einzige, was ich kann :-) > > Ansonsten verwende ich den Nano in den seltenen Fällen, wenn ich auf > einer reinen Textshell arbeite. Der ist dem alten WordStar nachempfunden > (kennt den noch jemand? 80er Jahre? CP/M? Z80-Dampfmaschinen mit > ASCII-Terminals? Grüne BAS-Monitore? Ach war dat schön damals...) Damit > habe ich meine ersten Assembler- und Pascal-Sourcecodes geschrieben und > bin daher mit Nano sofort klargekommen, obwohl zwischen CP/M und Linux > das beinahe 15 Jahre andauernde dunkle DOS/Windows-Zeitalter lag. Nano hat seinen Ursprung in Pico. Pico ist ein Editor mit E-Mailclient aus dem Jahre 1989 und wurde früher bei einigen Linux Distributionen mitgeliefert. Pico gibt es sogar auch als DOS Version. Weil es Unklarheiten bei der Lizenz gab, wurde irgendwann Nano gestartet und der hat dann ab so ca. 2003 pico als Texteditor auf den Linuxsystemen nach und nach ersetzt. Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt. https://en.wikipedia.org/wiki/Pico_(text_editor)
Touch Typist schrieb: > Nano schrieb: >> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine >> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem >> nach Lehrbuch, sondern macht sich was eigenes. > > Wichtig ist, blind schreiben zu können. Kannst Du das? Dass ich das kann, habe ich oben bereits im gleichen Kommentar, das du hier zitierst, geschrieben. Siehe: Nano schrieb: > Das muss ich auch nicht und ich nutze das 10 Fingersystem nicht, sondern > nur meine 10 Finger. > Und ja, ich kann das auch im Dunkeln. Wichtig ist also auch, Texte komplett zu erfassen und Kommentare zu Ende zu lesen. Kannst du das?
Nano schrieb: > Dein letztes Windows hatte wohl noch einen DOS Kernel. > > Unter einem Windows NT System landest du mit ALT+CTRL+DEL im > Loginbildschirm und kannst dich dann als Administrator anmelden. Und den Taskmanager erreicht man damit nicht? Und dort einen Neustart veranlassen kann man damit nicht? Bemerkenswert!
Nano schrieb: > Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt. WordStar war zu der Zeit ein ziemlicher de-facto-Standard, insofern ist das nicht verwunderlich, dass diese Editoren daraus eine Reihe von Kommandos übernommen haben.
Jörg W. schrieb: > Nano schrieb: >> dass nano Makros beherrscht, falls dir bekannt sein sollte, was das ist. >> Die kann man anlegen, dann ist das ein Tastendruck > > Der Haken ist: die musst du eben auch erst anlegen. Ja, das ist richtig. Anlegen tut man so etwas aber nur, wenn es sich wirklich lohnt und man die Funktion ohnehin öfters braucht. Ich gehe meist anders vor und bin dann genauso schnell am Ziel. Nach dem " drück ich die Entertaste, dann landet der String in der nächsten Zeile. Dort mach ich ein CTRL+K und der String mitsamt "; ist weg. Dann nutze ich die Rücktaste, lande somit wieder in meiner vorherigen Zeile und dann kann ich den neuen String eintragen und mit "; abschließen. Die RISC Technik funktioniert somit auch beim Menschen, da braucht man nicht immer CISC. CTRL+K und das Gegenstück CTRL+U gehören bei mir unter nano zu den Häufigsten von mir benutzten Tastaturkürzel. > Emacs hat auch welche, habe ich aber noch nie gebraucht. Emacs habe ich nie benutzt. Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI. Und es ist auch, anders als vi, nie immer vorinstalliert, also habe ich es nie benutzt. > Ich finde die diversen Modi bei vi auch ätzend, wirklich zeitgemäß waren > sie wohl schon zu Zeiten seiner Einführung nicht *), aber trotzdem kann > ich akzeptieren, dass es viele Leute gibt, die damit gut zurecht kommen > und würde diejenigen nicht als altmodisch betiteln. Habe ich auch nicht, das war jemand anderes.
Yalu X. schrieb: > Jack V. schrieb: >> Nano schrieb: >>> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine >>> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem >>> nach Lehrbuch, sondern macht sich was eigenes. >> >> Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du >> meinst das Layout – QWERTZ ist in der Tat nicht optimal. > > IMHO meint er damit sein individuelles Zehnfingersystem auf einem > normalen Tastaturlayout. > > Das Lehrbuchzehnfingersystem ordnet jeder Taste einen bestimmten Finger > zu, die Hände bleiben dabei immer mehr oder weniger an derselben > Position. Das ist ein recht starres, speziell auf das Tippen von > Fließtext auf einer Schreibmaschine optimiertes Konzept. > > ... > > Durch die Einbeziehung von Armbewegungen in die Tipparbeit verlieren > auch die auf dem deutschen Tastaturlayout erforderlichen "krummen" > Tastenkombinationen für einige Sonderzeichen (bspw. AltGr+{) viel von > ihrem Schrecken. ++ Genau so ist es. Danke!
Nano schrieb: > Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt. Ups, da fehlt ein "nicht" am Satzende. Keine Ahnung wie das passieren konnte, vielleicht lag es auch am Raspberry Pi 3, das Browsen ist mit dem leider ziemlich lahm und wenn er beschäftigt ist, hängt er leider auch etwas beim Tippen. Temp ist trotz nachträglich angebrachter Kühlkörper 62.3'C, da kann es also auch sein, dass er runterdrosselt.
Nano schrieb: > Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI. Letzteres kann nur jemand sagen, der damit noch nicht gearbeitet hat :-), aber das gehört nicht in diesen Thread.
Nano schrieb: > Du musst da also nicht di auswendig lernen. > Mal abgesehen davon, das dein Befehl nicht das tut, was du hier > behauptest. Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma) eingeben. Das 'd' steht für "delete" und das 'i' für "inner" und das '"' für "quoted string". Der Befehl sucht, ausgehend von der aktuellen Cursorposition nach links und rechts jeweils das nächste '"' und löscht alles, was dazwischen liegt. Dabei werden ggf. escapete '"' bei der Suche übersprungen. Beispiel:
1 | person = "Forenbenutzer \"Nano\""; |
Nach der Eingabe von 'di"' steht da:
1 | person = ""; |
Statt 'i' kannst du auch 'a' nehmen (also 'da"'), dann werden auch die Anführungszeichen und ggf. nachfolgender oder vorangehender Whitespace gelöscht:
1 | person =; |
Möchtest du den Inhalt des Strings nicht löschen, sondern ändern, geht
das mit 'c' statt 'd' am Anfang, also mit 'ci"' ('c' = "change"). Damit
wird der Inhalt wie bei 'di"' gelöscht und in den Insert-Modus
umgeschaltet, so dass du den neuen Inhalt eingeben kannst. Mit 'y'
("yank") wird der Stringinhalt kopiert. Mit 'v' ("visual") wird er grau
markiert, so dass man vorab sehen kann, wie Vim den Befehl
interpretiert. Danach kann man bei Bedarf die Grenzen des markierten
Bereichs mit den Cursortasten verschieben und mit 'd', 'c' oder 'y' den
markierten Text löschen, ändern oder kopieren.
Statt des '"' am Ende des Befehls kann auch ein '(', '[', '{' oder '<'
verwendet werden, um den Inhalt eines Klammerpaars zu löschen, zu ändern
oder zu kopieren. Dabei werden Verschachtelungen korrekt berücksichtigt.
Hat man das Prinzip erst einmal verstanden, kann man einige wenige,
leicht zu merkende Kürzel in vielfältiger Weise kombinieren. Auch das
ist eine Form von Discoverability. Ich wüsste auch nicht, wie man so
etwas in sinnvoller Weise in Menüs packen könnte.
Jack V. schrieb: > „lösch doch bitte alle Buchstaben zwischen den aktuellen Quotes“ > „lösch doch bitte alles bis zum nächsten Auftreten von Zeichen x“ > „ersetze doch bitte alle x in der aktuellen Zeile durch y“, und > so weiter. Du bist aber wirklich sehr höflich zu Deiner Software. Find' ich gut! ;-)
Jörg W. schrieb: > Nano schrieb: >> Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI. > > Letzteres kann nur jemand sagen, der damit noch nicht gearbeitet hat > :-), aber das gehört nicht in diesen Thread. Eine TUI ist keine GUI. Ich möchte bspw. als Fensterabgrenzung keine dicken Textblöcke wie "█", "║", "▓" oder "│", sondern dünne < 2 Pixel Breite Linien und die Pixel daneben sollten sich auch gleich direkt für etwas anderes nutzen lassen können. Das geht mit einer Textblöcke basierten TUI grundsätzlich nicht. Ist so, da gibt es auch kein wenn und aber.
Yalu X. schrieb: > Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur > eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten > usw.) aus der fixen Handposition heraus gar nicht erreichbar sind. Das ist mit einer der Gründe, aus denen ich Neo so mag: die meisten Sachen sind ohne große Handbewegungen erreichbar. \/{}() sind gar auf der Grundlinie, und selbst Cursor- und einige Funktionstasten, wie Home, End, Backspace, Escape sind in der vierten Ebene auf dem Haupttastenfeld. Gerade Escape ohne die Handhaltung zu ändern zu erreichen, ist in Verbindung mit dem Vim sehr geschickt (um grad noch so die Kurve zum Threadthema zu bekommen …) :)
:
Bearbeitet durch User
Yalu X. schrieb: > Nano schrieb: >> Du musst da also nicht di auswendig lernen. >> Mal abgesehen davon, das dein Befehl nicht das tut, was du hier >> behauptest. > > Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma) > eingeben. Und genau das habe ich gemacht und nichts passiert. Nach deinem Kommentar habe ich sogar extra nochmal nachgeguckt, ob ich wirklich im Normalmode bin: https://linuxhint.com/vim_modes/ Und ja, bin ich, funktioniert aber nicht. Und ja, ich habe es auch ohne Hochkomma eingegeben. Entweder nutzt ihr also eine andere, neuere Version als ich, wie schon gesagt, nutze ich hier vim von Rasbian oder eure Anleitung ist schlecht. In jedem Fall zeigt es aber, das vim nicht intuitiv ist. Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es anzeigt, in welchem Mode es ist, ist auch schlecht. Schon interessant, dass man Tastatukommandos, wie im Link beschrieben, z.b. Taste k drücken muss, um auf andere Weise festzustellen, ob man überhaupt im Normalmode ist. Und k ist dann auch noch vom Artikelschreiber doof gewählt, denn der Cursor landet für gewöhnlich, bei einer geöffneten Datei ohnehin ganz oben. > Das 'd' steht für "delete" und das 'i' für "inner" und das '"' für > "quoted string". Das weiß ich, ich habe schon vor Jahren mit vim angesehen und Tutorials durchgearbeitet. Spätestens bei der Debuggeransicht hat er dann verloren. > Der Befehl sucht, ausgehend von der aktuellen > Cursorposition nach links und rechts jeweils das nächste '"' und löscht > alles, was dazwischen liegt. Dabei werden ggf. escapete '"' bei der > Suche übersprungen. Beispiel: > person = "Forenbenutzer \"Nano\""; Apropo Escape, nichtmal die Eingabe von di\" geht. Was geht ist D, das löscht dann alles ab Cursor bis Zeilenende. > Nach der Eingabe von 'di"' steht da: > person = ""; Nö. > Statt 'i' kannst du auch 'a' nehmen (also 'da"'), dann werden auch die > Anführungszeichen und ggf. nachfolgender oder vorangehender Whitespace > gelöscht: > person =; Nö. Was geht ist yy um ein paar dieser String Zeilen zu kopieren und mit P einzufügen. Aber euer Befehl geht nicht, weder di" noch da". > Möchtest du den Inhalt des Strings nicht löschen, sondern ändern, geht > das mit 'c' statt 'd' am Anfang, also mit 'ci"' ('c' = "change"). Geht auch nicht. Vielleicht liegt es auch einfach daran:
1 | s /usr/bin/vi -l |
2 | lrwxrwxrwx 1 root root 20 30. Okt 2021 /usr/bin/vi -> /etc/alternatives/vi |
3 | pi@raspberrypi:~ $ ls /etc/alternatives/vi -l |
4 | lrwxrwxrwx 1 root root 17 30. Okt 2021 /etc/alternatives/vi -> /usr/bin/vim.tiny |
5 | pi@raspberrypi:~ $ /usr/bin/vim.tiny --version |
6 | VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08) |
7 | .... |
> Ich wüsste auch nicht, wie man so > etwas in sinnvoller Weise in Menüs packen könnte. Das muss man nicht. Man kann trotzdem einen intuitiven GUI Editor mit Menüs und gescheiter Debuggeransicht und Co haben und trotzdem eine Befehlseingabe ermöglichen die genau das gleiche kann. Wenn man das aber macht, dann macht man es richtig, mit der richtigen visuellen Rückmeldung und nicht so ein Gewürge, wie bei vim. Es gibt z.B. IDEs mit vi Eingabe, vi sind die dadurch trotzdem nicht.
Nano schrieb: > /usr/bin/vim.tiny Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum? Erstaunlich …
:
Bearbeitet durch User
Nano schrieb: > Ich möchte bspw. als Fensterabgrenzung … dünne < 2 Pixel Breite Linien … Da hast du dir ja eine Menge Spielraum gelassen. Zwei ist zu viel und Null ist tendenziell eher schlecht zu erkennen… ;-)
Nano schrieb: > Yalu X. schrieb: >> Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma) >> eingeben. > Und genau das habe ich gemacht und nichts passiert. Hmmm, vim 8.1.1401: geht, gvim geht auch. @Yalu X ›di"‹ kannte ich noch nicht, ist aber extrem praktisch. Habe ich sofort verinnerlicht. Danke!
Nano schrieb: > Eine TUI ist keine GUI. Emacs GUI gibt's seit 30 Jahren. Mag dir nicht zusagen, aber es ist trotzdem eine - den TUI-Modus benutze ich höchstens via ssh, wenn mir die Verbindung zu lahm für die GUI ist.
Jack V. schrieb: > Nano schrieb: >> /usr/bin/vim.tiny > > Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie > eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum? > Erstaunlich … Mit Recht, den eure Aussage ist ja: "vim ist überall installiert." Ist ja nicht mein Problem, dass vim unter Rasbian so ne Krücke ist. Nano ist dort vollständig. Und es stellt sich hier dann auch gleich noch die Frage, warum man unter Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt. Der Raspberry Pi 3 hat 1 GiB RAM, selbst mein Pentium 2 hatte nichtmal 1/4 davon, aber bei dem war Vim damals unter einem meiner ersten Linux Distris, die ich benutzt habe, vollständig. Da stellt sich also auch die Frage, ob die neuen Versionen von vim bloatware sind.
Nano schrieb: > Jack V. schrieb: >> Nano schrieb: >>> /usr/bin/vim.tiny >> >> Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie >> eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum? >> Erstaunlich … Ergänzung: Zumal du mir hier ja Grundfeatures aufzeigen wolltest, die ein Editor können soll. Also bspw. einen String zwischen zwei " löschen. Schon komisch, dass man dafür eine Bloatwareversion braucht.
Nano schrieb: > Schon komisch, dass man dafür eine Bloatwareversion braucht. Du merkst aber schon das es dir so langsam entgleist, oder?
Nano schrieb: > Mit Recht, den eure Aussage ist ja: > "vim ist überall installiert." Zumindest meine war’s nicht. Auf meinen Systemen ist installiert, was ich installiere. Nano schrieb: > Und es stellt sich hier dann auch gleich noch die Frage, warum man unter > Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt. Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama – dauert keine Minute, bis man das behoben hat. Nano schrieb: > Da stellt sich also auch die Frage, ob die neuen Versionen von vim > bloatware sind. Wenn du 1,5MB mehr, für die du dann eben auch die entsprechende Funktionalität hast, Bloat nennst – bitte. In meinem Sprachgebrauch steht Bloat etwa für höheren Platzbedarf ohne entsprechende zusätzliche Funktionalität – und das ist hier ganz offensichtlich nicht der Fall.
Jörg W. schrieb: > Nano schrieb: >> Eine TUI ist keine GUI. > > Emacs GUI gibt's seit 30 Jahren. Als TUI ja, TUI = Text User Interface. https://de.wikipedia.org/wiki/Zeichenorientierte_Benutzerschnittstelle Und wenn eine GUI dabei ist, dann ist das nur, wie auch bei gvim, dran geflanscht, während aber eigentliche Hauptarbeitsoberfläche, in dem Fall dann bspw. verschiedene Fensteransichten dann immer noch als TUI realisiert sind und darum geht es ja, das will ich nicht. Eine moderne IDE hat das Problem nicht, die ist vollständig grafisch.
Norbert schrieb: > Nano schrieb: >> Schon komisch, dass man dafür eine Bloatwareversion braucht. > > Du merkst aber schon das es dir so langsam entgleist, oder? Ist doch wahr, da will er mir ein paar Grundfeatures von vim zeigen und dann kann das nicht einmal jede vim Installation. Das wäre so, als wenn ich bei Kate alle Plugins dazu nehme. Jack V. schrieb: > Nano schrieb: >> Und es stellt sich hier dann auch gleich noch die Frage, warum man unter >> Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt. > > Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der > Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama > – dauert keine Minute, bis man das behoben hat. Ja, man kann die Vollversion aus dem Repo nachinstallieren, das ist war. Vorinstalliert ist es in der Form nicht, nano ist es. Interessanterweise gibt's auch ein nano-tiny im Repo, aber das ist nicht vorinstalliert. > Nano schrieb: >> Da stellt sich also auch die Frage, ob die neuen Versionen von vim >> bloatware sind. > > Wenn du 1,5MB mehr, für die du dann eben auch die entsprechende > Funktionalität hast, Bloat nennst – bitte. Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine tiny Version brauchen. Vielleicht gibt's Leute, die Debian auf einem Pentium MMX mit 64 MiB RAM installieren wollen, keine Ahnung, ausschließen möchte ich es nicht.
Nano schrieb: > Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine > tiny Version brauchen. Warum sollte ich das klären? Du argumentierst doch auf der Basis einer abgespeckten Version … ich weiß, was es damit auf sich hat, und ich würde mir nicht die Blöße geben, wild rumzuranten und gar persönlich beleidigend zu werden, weil ich nicht einmal erkenne, dass ich nicht die Upstream-Version, sondern eine vom Distributor künstlich verkleinerte Version nutze. Abgesehen davon hab ich schon geschaut: es ist als Ersatz für ›vi‹ gedacht, der früher™ immer dabei war, aber nicht mehr weiterentwickelt wird. Wie auch immer – wer Vim möchte, wird Vim installieren können. Und dass die Debianleute jede Upstream-Software in ihre Einzelteile zerlegen und feingranulierte Pakete draus bauen, wirst du ja wohl kaum den Vim-Entwicklern anhängen wollen, oder? Wo du grad bei Bloat warst: vim.tiny und nano sind etwa gleichgroß. Wenn du also unter dem Gesichtspunkt erwartest, dass beim Vim die wirklich umfangreiche Funktionalität dabei wäre, während Nano sich zugunsten einfacher Bedienung auf einige Grundfunktionen beschränkt, wäre doch wohl Nano an dieser Stelle der Bloat? Wie auch immer … ist abzusehen, wo die „Diskussion“ mit dir hinführt: ins Tal der verbrannten Zeit. Das ist ein öder Ort – bitte reise alleine weiter.
Nano schrieb: > Eine moderne IDE hat das Problem nicht, die ist vollständig grafisch. Ich weiß nicht, was das für dich ist. Wenn man in den Fenstern JPEGs, PNGs und PDFs darstellen kann, dann ist das für mich schon "vollständig grafisch". (Bunte Icons für Menüs kann er auch schon lange, aber die verplempern mir zu viel Platz, die schalte ich immer als erstes aus.) Ich sag ja: du kennst das einfach nicht. Ist auch nicht schlimm, du musst das GUI davon ja nicht mögen, aber dann red doch lieber nicht drüber.
Jack V. schrieb: > Nano schrieb: >> Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine >> tiny Version brauchen. > > Warum sollte ich das klären? Du argumentierst doch auf der Basis einer > abgespeckten Version Nö, du hast gesagt, VIM kann das immer und überall. Grundfunktion halt. > … ich weiß, was es damit auf sich hat, und ich > würde mir nicht die Blöße geben, wild rumzuranten und gar persönlich > beleidigend zu werden, Also letzteres machst ja genau du, siehe mein altes Posting von heute Nachmittag, wo ich dir das bereits gesagt habe: Beitrag "Re: Vi Editor ausgestorben?" > weil ich nicht einmal erkenne, dass ich nicht die > Upstream-Version, sondern eine vom Distributor künstlich verkleinerte > Version nutze. Bitte erzähle hier keine Lügen. Ich habe es erkannt. Siehe mein obiges Posting, wo ich die Shellauszüge poste, ich hätte das nicht gepostet, wenn mir das nicht aufgefallen wäre. Und genau das ändert trotzdem nicht, dass vim dein Feature eben nicht überall und immer kann, wie du anfangs behauptet hast. > Wo du grad bei Bloat warst: vim.tiny und nano sind etwa gleichgroß. Wenn > du also unter dem Gesichtspunkt erwartest, dass beim Vim die wirklich > umfangreiche Funktionalität dabei wäre, während Nano sich zugunsten > einfacher Bedienung auf einige Grundfunktionen beschränkt, wäre doch > wohl Nano an dieser Stelle der Bloat? Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu deinem vim-tiny. > Wie auch immer … ist abzusehen, wo die „Diskussion“ mit dir hinführt: > ins Tal der verbrannten Zeit. Sag mal, hast du jetzt ernsthaft gelaubt, dass du mich von vim überzeugen kannst, wenn du mich nur oft genug persönlich angreifst, so wie du es oben getan hast oder jetzt mir Dinge unterstellst, die ich nicht getan habe? Ich habe dir bereits meine Kritikpunkte zu vim gesagt und die konntest du h alt nicht entkräften. Auch habe ich dir dargelegt, dass dein Feature, das deine vim-tiny Version nicht kann, ein normaler nano Editor kann und somit hast du nichts gezeigt, was vim irgendwie außergewöhnlich macht. Stattdessen habe ich dir dargelegt, dass all das auch ein normaler intuitiv erschließbarer Editor kann und so eine Befehlszeile auch immer einbaubar ist. Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein vim und für Configfiles reicht mir nano. Akzeptiere das endlich.
Ich finde es jetzt auch nicht zielführend wenn jede Linuxdistri ihre eigene Version eines abgespekten vim benutzt. Sollen sie doch den richtigen vim nutzen, dann gibts auch keine Inkompatibilitäten in der Bedienung und auch mit Bugfixes hat man es dann einfacher. Eine Erstellung einer extra abgespeckten Version ist sinnlos vergeudete Arbeitszeit. Ja die Installation des richtigen vim dauert vielleicht weniger als 2 Minuten. Trotzdem ist es ärgerlich wenn man es machen muss und nicht davon ausgehen kann, dass auch auf allen fremden Systemen die richtige Version installiert ist.
Nano schrieb: > Nö, du hast gesagt, VIM kann das immer und überall. Grundfunktion halt. Meine Güte, merkst du es wirklich nicht? Da hat ein Dritter Funktionalität zugunsten kleinerer Größe rausgepatched, es ist nicht „der“ Vim. Der behauptet nicht einmal, dass es „der” Vim wäre, sondern nennt es treffend „vim.tiny“. Und wenn du jetzt gar noch behauptest, dass dir das die ganze Zeit über bewusst gewesen wäre: was genau hast du dann mit dieser Farce bezweckt? Falls du wirklich ein solches Verständnisproblem damit hast, versuch’s dir doch einfach mal andersrum vorzustellen: Ich nehme mir den Nano-Code, patche einige Funktionen, die du oben gepostet hast, raus und behaupte dann, dass „der“ Nano das ja gar nicht könne; was du da behauptest, wär’ Stuss, die ursprüngliche Nano-Version wär’ Bloat, und würde dir noch ’n paar andere Sachen an den Kopf knallen, wie du weiter oben selbst abgesondert hast. Würdest du mir dann Recht geben? Rein logisch müsstest du – aber bist du in der Lage, das zu erkennen? Ich fürchte leider, dass nicht :( Nano schrieb: > Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein > vim und für Configfiles reicht mir nano. > Akzeptiere das endlich. Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen, dass das für mich vollkommen in Ordnung ist, und ich das mehrfach, direkt und eigentlich unmissverständlich so geschrieben habe. Das Problem liegt an deinem schon fast fanatisch erscheinenden Kampf gegen Vim und seine User – darin, dass du mit allen Mitteln versuchst, es als generell, für jeden gleichermaßen, untauglich darzustellen. Und da fügt sich die Episode mit vim.tiny auch irgendwie wunderbar ein. Bleibt nur die Frage: was könntest du davon haben? Ich denke, Norbert hat Recht: es ist dir wirklich entglitten. Grüß den Kaktus im Tal der verbrannten Zeit o/
:
Bearbeitet durch User
Rolf M. schrieb: > Warum muss eigentlich immer gleich gegen die Nutzer der Software > gegiftet werden? Es gehört in diesem Forum leider zum "guten Ton" dass überwiegend gegen Leute gegiftet wird anstatt sachlich über das Thema zu diskutieren. Ist hier so schlimm wie nirgends sonst. Leider... OT Ende
abcde schrieb: > Ich finde es jetzt auch nicht zielführend wenn jede Linuxdistri ihre > eigene Version eines abgespekten vim benutzt. Ist es auch nicht, aber erzähl' das mal den Leuten bei Debian. Aber ach, wenn es denn nur den vim beträfe -- aber bei denen geht das ja leider noch viel weiter, zum Beispiel mit der dash. Die spart ungefähr ein vierzehntel Kilobyte Arbeitsspeicher und bootet das System etwa eine halbe Tausendstel Sekunde schneller -- also, würde sie, wenn Debian nicht auf systemd gewechselt wäre -- und dafür nehmen sie einfach mal subtile Inkompatibilitäten mit dem Rest der Linux-Welt in Kauf und wundern sich (oder ärgern sich sogar), wenn erfahrene Linux-Profis Debian zwar selbst benutzen, es Anfängern aber trotzdem nicht empfehlen wollen.
Jack V. schrieb: > Und da fügt > sich die Episode mit vim.tiny auch irgendwie wunderbar ein. Bleibt nur > die Frage: was könntest du davon haben? Ich denke es ging darum, dass nano bei fast jedem Linux standardmäßig mitinstalliert wird und deshalb fast überall vorhanden ist. Vim wird hingegen nicht überall (zumindest nicht bei Debian und davon abgeleiteten Distros) automatisch mitinstalliert, stattdessen wird ein vim.tiny geliefert, der weniger kann als nano. Die Aussage, dass ein Vorteil von vim eben diese wäre, dass er überall installiert ist, stimmt also einfach nicht.
abcde schrieb: > Die Aussage, dass ein > Vorteil von vim eben diese wäre, dass er überall installiert ist, stimmt > also einfach nicht. Naja, die Aussage war, dass er überall verfügbar wäre. Das hat eine leicht andere Bedeutung. Weiterhin ist nano vielleicht bei Debian per default installiert (bestätigen kann ich es nicht: die letzten zehn Jahre oder so hab ich Debian mittels debootstrap zusammengesteckt, und da ist dann weder Vim, noch Nano installiert), bei anderen Systemen sieht’s halt auch schon wieder anders aus. Und wenn ich dann einen Editor installiere, dann doch den, der mir zusagt. Wenn mich dann jemand von der Seite anmacht und mir erzählen will, dass ich doof wäre und mein Editor sowieso nix taugen würde, dann frage ich mich schon ein wenig: WTF? Und wenn ich dann kurz erläutere, warum ich diesen Editor einem anderen gegenüber bevorzuge, und mir dann das entgegengeschleudert wird, was der Gast da rausgehauen hat, dann frage ich mich zusätzlich auch noch: WTF??
Yalu X. schrieb: > Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur > eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten > usw.) aus der fixen Handposition heraus gar nicht erreichbar sind. Bei vi(m) und emacs braucht man die Cursor- und Funktionstasten gar nicht. Im vi(m) (im command mode) bewegt man den Cursor mit h, j, k, l und im emacs mit C-b, C-f, C-p, C-n.
Jack V. schrieb: > Weiterhin ist nano vielleicht bei Debian per default installiert Witzigerweise ist er sogar bei MacOS standardmäßig dabei. ;-)
Hallo, hier wird ja immer wieder von den Vi(m)-Benutzern angeführt wie effektiv und schnell man mit Vi(m) gegenüber einem grafischen Editor mit seinen Auswahlmenüs arbeiten kann. Jetzt würde mich aber doch mal interessieren wie viel schneller man tatsächlich wird. Vielleicht kann ja mal jemand, der mit Programmen aus beiden Welten arbeitet, was dazu sagen. rhf
abcde schrieb: > Ich denke es ging darum, dass nano bei fast jedem Linux standardmäßig > mitinstalliert wird und deshalb fast überall vorhanden ist. Vim wird > hingegen nicht überall (zumindest nicht bei Debian und davon > abgeleiteten Distros) automatisch mitinstalliert, stattdessen wird ein > vim.tiny geliefert, der weniger kann als nano. Trotzdem kann auf so ziemlich jedem UNIXioden System unter dem Befehl "vi" ein Programm aufgerufen werden, mit dem seine Benutzerin ihre Dateien editieren kann. Also gut, wenn sie kann natürlich, das trifft ja nicht auf jede Benutzerin zu, wie wir hier im Thread wieder einmal eindrucksvoll bewundern durften. Aber das ist eine ganz andere Nummer: beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also beispielsweise zu dem Paketmanagement des Systems eine Paketquelle hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs, XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann. Und genau deswegen, weil es den vi und seine Klone und Abarten unter jedem UNIXoiden System gibt und man damit Textdateien editieren kann, ist es sinnvoll, dieses Werkzeug zumindest rudimentär zu beherrschen. Wenn ich eine Reifenpanne habe, muß ich mir leider auch mit dem verkrüppelten Witz behelfen, den mein KFZ-Hersteller unter der Bezeichnung "Wagenheber" beigelegt hat, und so ist das auch mit Debians bescheuertem "vim.tiny". Wenn ich planmäßig meine Sommer- oder Winterreifen aufziehen will, benutze ich meine komfortable Hebebühne, und wenn ich richtige Entwicklungsarbeit machen will, meinen Emacs. So ist das auch mit einem Editor: wenn ich einen Editor als Entwicklungsplattform benutze, ist eine ganz andere Nummer, als wenn ich nur mal schnell eine Konfigdatei editieren will. Den konfiguriert man sich, der wird gehätschelt, gepflegt, erweitert und über die Wochen, Monate und Jahre perfekt an die eigenen Bedürfnisse, Ideen und Ideale angepaßt. Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr (den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano" installieren können).
Roland F. schrieb: > Jetzt würde mich aber doch mal interessieren wie viel schneller man > tatsächlich wird. Das hängt wohl wirklich davon ab, wieviel du damit machst. Musst du nur jede Woche dreimal eine Config-Datei anpassen, dann brauchst du einen möglichst simplen Editor. Sitzt du den halben Tag (oder mehr) davor, dann willst du möglichst effizient sein. Dann wiederum gibt es Leute, die sind effizient, sich immer mal wieder durch ein paar Menüs zu hangeln und ansonsten viel tippen, während andere möglichst viel mit möglichst wenig Tastendrücken gemacht haben wollen. Das schließt nun keineswegs nur vi(m) oder Emacs ein, auch mit dem in letzter Zeit recht populär gewordenen VSCode (immerhin mal Opensource by Microsoft) kann man auf diese Weise arbeiten.
:
Bearbeitet durch Moderator
Roland F. schrieb: > Jetzt würde mich aber doch mal interessieren wie viel schneller man > tatsächlich wird. Einen Eindruck davon kann man auch in einigen (youtube) Videos bekommen. Z.B. "Vim Can Save You Hours Of Work" https://www.youtube.com/watch?v=bshMXXX40_4 oder "50+ Vim Tips and Tricks from Beginner to Expert" https://www.youtube.com/watch?v=ZEIpdC_klDI Wie bei anderen Sachen auch, hängt die Geschwindigkeit davon ab wie oft und lange man seinen Editor nutzt. P.S. Es gibt sicher bessere Videos, aber ich nutze youtube nicht oft.
Für alle die "Was ist besser: emacs oder vim?" nicht mehr hören können. Zur Abwechslung: "Nano Or Vim? Which Terminal Text Editor Should You Use?" https://www.youtube.com/watch?v=vAwo7CLWlUc :-)
Nano schrieb: > Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es > anzeigt, in welchem Mode es ist, ist auch schlecht. Natürlich hat Vim eine Statusleiste und zeigt dort, sobald man den Normal-Mode verlässt, auch den Mode an ("-- INSERT --" oder "-- VISUAL --"). Das ist auch beim vim-minimal von Arch-Linux und wahrscheinlich auch beim vim-tiny von Debian so. Nano schrieb: > Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu > deinem vim-tiny. Jetzt machst du dich aber langsam lächerlich. Natürlich kann man das mit jedem Editor, nur nicht mit jedem so einfach wie mit Vim. Selbst im Ur-vi (und damit erst recht auch im vim-tiny) geht das recht einfach mit
1 | T"d, |
allerdings werden dabei im Gegensatz zum Vim escapete Anführungszeichen innerhalb des Strings nicht korrekt behandelt. Zum Vergleich das oben von dir gepostete "Gewürge" (um deine Ausdrucksweise zu übernehmen) für den Nano: Nano schrieb: > ALT + G > STRG + T > " eingeben + Enter drücken > 1 cursor nach rechts > ALT + A = Markerung gesetzt > ALT + G > STRG + T > " eingeben + Enter drücken > STRK + K Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel schneller zeichenweise mit der Delete-Taste. Nano schrieb: > Schon komisch, dass man dafür eine Bloatwareversion braucht. Vi (ohne 'm') alles andere als Bloatware:
1 | vi: Installed Size : 315.50 KiB |
2 | nano: Installed Size : 2.48 MiB |
Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt, ist auch Vi trotz seines Alters noch ein recht guter und effizient nutzbarer Editor.
Ein T. schrieb: > beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall > gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine > Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also > beispielsweise zu dem Paketmanagement des Systems eine Paketquelle > hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs, > XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann. Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung, die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein nano auch meist installiert ist). Wenn man dann richtig arbeiten muss, nimmt man auch einen richtigen Editor.
Felix schrieb: > Ein T. schrieb: >> beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall >> gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine >> Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also >> beispielsweise zu dem Paketmanagement des Systems eine Paketquelle >> hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs, >> XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann. > > Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung, > die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein > nano auch meist installiert ist). Wenn man dann richtig arbeiten muss, > nimmt man auch einen richtigen Editor. Auch vi(m) kann ein richtiger Editor sein. Aber das ist dann eine andere Nummer als der "vim.tiny" oder der "nano" von dem aggressiven Gast hier.
Jörg W. schrieb: > Das schließt nun keineswegs nur vi(m) oder Emacs > ein, auch mit dem in letzter Zeit recht populär gewordenen VSCode > (immerhin mal Opensource by Microsoft) kann man auf diese Weise > arbeiten. VSCode ist deswegen ein guter Editor zum Programmieren, weil er das Language Server Protocol versteht und nutzt. https://en.wikipedia.org/wiki/Language_Server_Protocol Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu erfahren. Es gibt hunderte Editoren die ein paar Dutzend Programmiersprachen als unterstützt aufzählen, aber gemeint ist bei denen dann meist nur die farbliche Hervorhebung und das erkennen von Schlüsselwörtern. Eine Programmiersprachenunterstützung durch LSP ist aber weitaus mehr als nur die Syntax des Codes einer Programmiersprache mit einem entsprechenden Syntax Highligning darzustellen, bei LSP geht es darum, die Sprache auch wirklich zu verstehen und das im Editor dann entsprechend zu unterstützen. Es erspart vor allem auch dem Editorschreiber das Rad jedes mal neu zu erfinden und Fehler zu vermeiden, wenn er eine bestimmte Sprachunterstützung nun in den Editor einbauen möchte. Das LSP ist damit die Zukunft eines jeden ernsthaften Programmiereditors und jeder ernsthaften IDE und da die Unterstützung bei VSCode diesbezüglich sehr gut ist, zumal LSP mit VSCode anfing, ist VSCode natürlich sehr beliebt. Auch die neueren Versionen von KDevelop verfügen inzwischen über eine LSP Unterstützung, während Programmiersprachen die bei KDevelop mal als unterstützt bezeichnet wurden, aber es da meist nur um das Syntax Highlightning und erkennen von Schlüsselwörtern ging, deswegen aus KDevelop entfernt wurden.
Yalu X. schrieb: > Nano schrieb: >> Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es >> anzeigt, in welchem Mode es ist, ist auch schlecht. > > Natürlich hat Vim eine Statusleiste und zeigt dort, sobald man den > Normal-Mode verlässt, auch den Mode an ("-- INSERT --" oder "-- VISUAL > --"). Das ist auch beim vim-minimal von Arch-Linux und wahrscheinlich > auch beim vim-tiny von Debian so. Nein, bei vim-tiny von Debian bzw. Rasbian ist das nicht so, deswegen habe ich das oben auch erwähnt. Nur die Vollversion, die ich jetzt nachinstalliert habe, zeigt das an. > Nano schrieb: >> Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu >> deinem vim-tiny. > > Jetzt machst du dich aber langsam lächerlich. Natürlich kann man das mit > jedem Editor, nur nicht mit jedem so einfach wie mit Vim. Vim-tiny kann es nicht und Notepad wird das auch nicht können. Man braucht dazu also schon einen erweiterten Editor. PS: Es geht nicht darum, den String zwischen zwei "" händisch zu entfernen, das geht mit Notepad dann natürlich auch, war hier aber nicht gemeint. > Selbst im > Ur-vi (und damit erst recht auch im vim-tiny) geht das recht einfach mit > >
1 | > T"d, |
2 | > |
> > allerdings werden dabei im Gegensatz zum Vim escapete Anführungszeichen > innerhalb des Strings nicht korrekt behandelt. Das ist nicht die gleiche Kommandosequenz, die Jack angeführt hat. Du hast jetzt halt einen anderen Weg gefunden, prima, das funktioniert sogar in vim-tiny. Es ist aber dann schon eure Aufgabe, euch auf die richtige Kommandosequenz zu einigen. Natürlich beziehe ich mich bei meinen vorherigen Kommentaren auf das, was zuerst genannt wurde und nicht das, was ihr im Nachhinein alternativ noch herausfindet. Und das erstgenannte, das geht in vim-tiny dann halt nicht. > Zum Vergleich das oben von dir gepostete "Gewürge" (um deine > Ausdrucksweise zu übernehmen) für den Nano: > > Nano schrieb: >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> 1 cursor nach rechts >> ALT + A = Markerung gesetzt >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> STRK + K > > Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel > schneller zeichenweise mit der Delete-Taste. Tja keine Ahnung wer das braucht, es ging ja nur darum zu veranschaulichen das das auch geht und bei nano erschließt sich das sogar intuitiv. Wie ich das machen würde, mit STRG+K usw., das habe ich oben ja erklärt. > Vi (ohne 'm') alles andere als Bloatware: > >
1 | > vi: Installed Size : 315.50 KiB |
2 | > nano: Installed Size : 2.48 MiB |
3 | > |
> > Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt, > ist auch Vi trotz seines Alters noch ein recht guter und effizient > nutzbarer Editor. Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht?
Angehängte Dateien:
-
pico.png
8,6 KB -
pico_cli.png
18 KB -
pico_mem.png
10 KB -
pico_started.png
8,1 KB
> Yalu X. schrieb: >> Vi (ohne 'm') alles andere als Bloatware: >> >>> vi: Installed Size : 315.50 KiB >> nano: Installed Size : 2.48 MiB >> So, habe jetzt mal pico nachgemessen. pico: Installed Size : 116.11 KiB Und der läuft sogar mit nur 528 KiB RAM. Siehe Screenshots. :p >> Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt, >> ist auch Vi trotz seines Alters noch ein recht guter und effizient >> nutzbarer Editor. Ich habe übrigens nicht bestritten, dass er ineffizient wäre. Für Configdateien werde ich trotzdem nano, pico oder meinetwegen notepad.exe und edit.exe einsetzen, solange einer von denen verfügbar ist.
Roland F. schrieb: > Hallo, > hier wird ja immer wieder von den Vi(m)-Benutzern angeführt wie effektiv > und schnell man mit Vi(m) gegenüber einem grafischen Editor mit seinen > Auswahlmenüs arbeiten kann. > Jetzt würde mich aber doch mal interessieren wie viel schneller man > tatsächlich wird. Vielleicht kann ja mal jemand, der mit Programmen aus > beiden Welten arbeitet, was dazu sagen. Das wird eher schwierig, das in objektiven Zahlen auszurücken. Ich weiß nur, dass Kollegen öfter mal beeindruckt sind, wie schnell ich manche Dinge mit vim erledigt bekomme. Nano schrieb: > VSCode ist deswegen ein guter Editor zum Programmieren, weil er das > Language Server Protocol versteht und nutzt. > > https://en.wikipedia.org/wiki/Language_Server_Protocol > > Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu > erfahren. Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende Funktionalität (kontextsensitive Autovervollständigung, Anzeige von Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.) für einige Sprachen auch schon ohne Language Server mitbringt. Es kann aber wohl auch mit Language Servern kommunizieren. https://github.com/ycm-core/YouCompleteMe#semantic-completion-for-other-languages
:
Bearbeitet durch User
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? Selbstverständlich! Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw. Ich liebe es, dass man vi/m LERNEN muss und wenn man es gelernt hat, ist die Arbeit damit sehr effektiv. Das ist genau das Gegenteil von dem "user-friendly" Windows-Scheiß (usw.), wo behauptet wird, dass alles so leicht und einfach gemacht ist, dass es selbst kleine Kinder intuitiv beherrschen können. Wenn man aber etwas nur ein bisschen Anspruchsvolleres braucht, dann klickt man sich tot und es dauert eine Ewigkeit. Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn gesund hält...
neovim hätte nativen LSP-Support, für den ursprünglichen Vim gibt es mehrere Möglichkeiten, das bei Bedarf einzurichten. Bevor der Gast nun mit „ja, aber aber aber … aber das ist nicht nativ!!k“ kommt: bei den meisten IDEs wird’s ebenfalls über Plugins oder Extensions realisiert, und für Nano oder gar Pico gibt’s gar keine Möglichkeit – also STFU!
Nano schrieb: > VSCode ist deswegen ein guter Editor zum Programmieren, weil er das > Language Server Protocol versteht und nutzt. Aha. VSCode ist also deshalb ein "guter Editor", weil er ein selbst definiertes Protokoll benutzt. Interessant. Mit dieser Argumentationslinie kannst du wohl jeden Editor als "guten Editor" deklarieren … (Ich stelle natürlich nicht in Abrede, dass VSCode ein guter Editor ist, nur die Argumentation ist Käse.)
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
streitgespraech-islieb.png
100 KB
Jack V. schrieb: > und für Nano oder gar Pico gibt’s gar keine Möglichkeit – also STFU!
Bei jedem BSD und jedem Mac oder MacBook ist der vi oder vim standardmäßig dabei!
Nano schrieb: > VSCode ist deswegen ein guter Editor zum Programmieren, weil er das > Language Server Protocol versteht und nutzt. Jaja, tollstes Feature seit geschnittenem Brot. Blöd halt, daß die Entwicklung von Sourcecode seit etlichen Jahrzehnten ohne dieses tolle Ding auskommt -- inklusive der Entwicklung von LSP selbst. Weißt Du, ich hab' jetzt schon eine ganze Menge solcher "Gott-Features" gesehen, ohne die Entwickler angeblich nicht mehr arbeiten können. Die meisten davon sind nach kurzer Zeit wieder sang- und klanglos untergegangen. Syntax-Highlighting, Autocompletion, -Brackets und -Indentation haben sich allerdings gehalten. > https://en.wikipedia.org/wiki/Language_Server_Protocol > > Keine Ahnung ob vim das auch kann, Lesen bildet: [1]. Dein toller nano ist da übrigens nicht aufgeführt. Emacs und vi dagegen schon. [1] https://microsoft.github.io/language-server-protocol/implementors/tools/
Nano schrieb: > Es ist aber dann schon eure Aufgabe, euch auf die richtige > Kommandosequenz zu einigen. Warum sollten sie? >> Nano schrieb: >>> ALT + G >>> STRG + T >>> " eingeben + Enter drücken >>> 1 cursor nach rechts >>> ALT + A = Markerung gesetzt >>> ALT + G >>> STRG + T >>> " eingeben + Enter drücken >>> STRK + K >> >> Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel >> schneller zeichenweise mit der Delete-Taste. > > Tja keine Ahnung wer das braucht, es ging ja nur darum zu > veranschaulichen das das auch geht und bei nano erschließt sich das > sogar intuitiv. Äh... also wenn das "intuitiv" ist, haben wir beide fundamental unterschiedliche Vorstellungen von der Bedeutung dieses Wortes. >> Vi (ohne 'm') alles andere als Bloatware: >> >>
1 | >> vi: Installed Size : 315.50 KiB |
2 | >> nano: Installed Size : 2.48 MiB |
3 | >> |
> > Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht? Egal, nano ist offensichtlich Bloatware. 2,5 MB für einen Editor, dem obendrein auch noch Features fehlen, die Du hier anpreist wie geschnittenes Brot... wow.
Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich vorher ein paar Stunden oder Tage einarbeiten zu müssen. Irgendwelche kryptischen Tastenkombinationen sind da nicht das Mittel der Wahl, die vergisst man auch ganz schnell wieder wenn man sie nicht jeden Tag braucht. So ein kleiner Editor muss auch nicht alles können, aber Cursortasten sollte er schon kennen. Man sollte die Datei auch abspeichern und den Editor beenden können, ohne dazu ein Handbuch lesen zu müssen. Für größere Programmierprojekte nimmt man dann natürlich was anderes.
T1000 schrieb: > VIM lebt noch. Es gibt eine neue Version: > https://www.vim.org/vim90.php Noch nicht bei Debian-sid
Zitat von https://wiki.debian.org/vim If you don't know anything about vi, it is better to use nano.
Siggi schrieb: > Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei > benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich > vorher ein paar Stunden oder Tage einarbeiten zu müssen. Das ist richtig, sofern man ansonsten nicht mit einem anderen Editor arbeitet. Ich würd’ mir ziemlich blöde vorkommen, würde ich zur Anpassung einer Config-Datei etwa nano oder pico starten, während ich ansonsten eigentlich ausschließlich Vim nutze. -- Ich hab mir nun mal neovim genauer angeschaut und bin gerade fast sicher, dass er den Vim bei mir ablösen wird.
Felix schrieb: > Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung, > die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein > nano auch meist installiert ist). Wenn man dann richtig arbeiten muss, > nimmt man auch einen richtigen Editor. Was man eben so hören bzw. lesen will ... Ich verwende den Vim gerne. Ist mein Lieblingseditor. Ich nutze Vim-Plugins in jeder IDE. Eben weil es damit (für mich) schneller geht. Mal eben zwei Worte oder Zeilen vertauschen, Ziffern in Variablennamen Hoch- oder Runterzählen, Suchen und Ersetzen, Text bis zu einem bestimmten Zeichen löschen/Ersetzen, ... und das alles ohne ein einziges Mal die Hand von der Tastatur zu nehmen. Inklusive all der Features von der IDE wie Codevervollständigung, Syntaxhighlighting etc. Einfach Mal über den Tellerrand schauen! Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam!
Jack V. schrieb: > Siggi schrieb: >> Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei >> benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich >> vorher ein paar Stunden oder Tage einarbeiten zu müssen. > > Das ist richtig, sofern man ansonsten nicht mit einem anderen Editor > arbeitet. Ich würd’ mir ziemlich blöde vorkommen, würde ich zur > Anpassung einer Config-Datei etwa nano oder pico starten, während ich > ansonsten eigentlich ausschließlich Vim nutze. Ja wenn du vim sonst auch nutzt, ist es naheliegend, ihn auch für eine kleine Config-Datei zu nutzen.
Rolf M. schrieb: > Nano schrieb: >> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das >> Language Server Protocol versteht und nutzt. >> >> https://en.wikipedia.org/wiki/Language_Server_Protocol >> >> Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu >> erfahren. > > Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende > Funktionalität (kontextsensitive Autovervollständigung, Anzeige von > Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.) > für einige Sprachen auch schon ohne Language Server mitbringt. Es kann > aber wohl auch mit Language Servern kommunizieren. > https://github.com/ycm-core/YouCompleteMe#semantic-completion-for-other-languages Gut zu wissen. Und mit welcher Erweiterung debuggst du deinen Code? Und zeigst Stack, Register, Watch-Variablenansichten usw. auf einmal an und zwar so, dass das gleich upgedated wird, wenn du durch den Code stepst? Und wie sieht's mit automatischem Wiederholen der Eingaben beim Debuggen aus, also eine Eingabesequenz? (Record and replay debugging) Sowie reverse debugging oder dem manuellen ändern der Variablenwerte, während dem Debugging Durchlauf? Eine gescheite IDE hat in der Regel eine gute Debugger Integration und bietet all das und noch viel mehr. Und Vim?
Petr T. schrieb: > Openbsd schrieb: >> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die >> ultimativen Vorzuege dieses Editors? > > Selbstverständlich! > > Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du > z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw. Mit JEDEM mit Mausbedienung! Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig! Insgesamt also 2 Tasten, nicht 3. > Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn > gesund hält... Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus. Owned!
Nano schrieb: > Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus. Immer noch kein Zehnfingersystem (mit beliebigem Layout) gelernt? Dann brauchst von Effizienz auch nix zu schreiben.
Jack V. schrieb: > neovim hätte nativen LSP-Support, für den ursprünglichen Vim gibt es > mehrere Möglichkeiten, das bei Bedarf einzurichten. Aha, dann bietet also nur neovim das out of the box. Während man bei vim das erst alles nachinstallieren und einrichten muss. Wozu soll man dann vim nehmen, wenn man gleich neovim nehmen kann? > Bevor der Gast nun > mit „ja, aber aber aber … aber das ist nicht nativ!!k“ kommt: bei den > meisten IDEs wird’s ebenfalls über Plugins oder Extensions realisiert, Gescheite IDEs liefern diese Plugins und Extensions aber mit der Installation der IDE gleich mit. > und für Nano oder gar Pico gibt’s gar keine Möglichkeit – also STFU! Nano und pico muss das auch nicht, weil nano für Configfiles da ist und nicht die Aufgabe hat, eine IDE zu ersetzen. Du wirbst dagegen bei vim allerdings auch mit vim als IDE Ersatz, das ist der Unterschied, was ich bei nano nie getan habe. Oben habe ich es sogar klar abgegrenzt, da habe ich irgendwo geschrieben, dass ich nano zum Editieren von Configfiles und kleinen Sachen nutze und eine IDE zum Programmieren. Also STF selber U! Jörg W. schrieb: > Nano schrieb: >> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das >> Language Server Protocol versteht und nutzt. > > Aha. VSCode ist also deshalb ein "guter Editor", weil er ein selbst > definiertes Protokoll benutzt. Interessant. Mit dieser > Argumentationslinie kannst du wohl jeden Editor als "guten Editor" > deklarieren … Falsch, das LSP ist standardisiert, es ist ein Standard! Und jeder fähige IDE und Editor greift diesen Standard auf.
Jack V. schrieb: > Nano schrieb: >> Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus. > > Immer noch kein Zehnfingersystem (mit beliebigem Layout) gelernt? Dann > brauchst von Effizienz auch nix zu schreiben. Ist das dir jetzt nicht peinlich? Scroll mal nach oben und lies da nochmal nach. Nochmal für die ganz Dummen: DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz bestimmtes und das hat mit Layouts auch nichts zu tun. Und hier noch zum Nachlesen und bilden: https://de.wikipedia.org/wiki/Zehnfingersystem Vor allem ab hier: https://de.wikipedia.org/wiki/Zehnfingersystem#Grundlegendes_Prinzip Schon zu sagen "kein Zehnfingersystem gelernt" zu sagen ist dämlich, denn es gibt nur EIN Zehnfingersystem, es müsste also heißen "Immer noch nicht das Zehnfingersystem gelernt". Und nein, wieso auch, es hat beim Programmieren keinerlei Vorteile! Owned!
Nano schrieb: > Aha, dann bietet also nur neovim das out of the box. > Während man bei vim das erst alles nachinstallieren und einrichten muss. > Wozu soll man dann vim nehmen, wenn man gleich neovim nehmen kann? An welcher Stelle ist diese Frage relevant? Nahezu alles, was hier im Thread zu vim geschrieben wurde, lässt sich genausogut auf nvim abbilden. Nano schrieb: > Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann > 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig! Hörmal: ich akzeptiere vollkommen, dass du Programme, die eine initale Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist überhaupt nichts verkehrt. Wäre schön, wenn du im Gegenzug die Physik akzeptieren würdest: in der Zeit, die du zur Bewegung deiner Hand zur Maus benötigst, hat jemand, der mit der Tastatur gut umgehen kann, die drei Buchstaben abgesetzt. Dein „Beispiel“ mit der Maus wirkt genauso krampfhaft, wie deine Shortcut-Wüste für die Funktion von di" oben. Aber just for fun: zeig doch mal bitte kurz auf, wie du ddp umsetzen würdest :)
:
Bearbeitet durch User
Ein T. schrieb: > Nano schrieb: >> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das >> Language Server Protocol versteht und nutzt. > > Jaja, tollstes Feature seit geschnittenem Brot. Blöd halt, daß die > Entwicklung von Sourcecode seit etlichen Jahrzehnten ohne dieses tolle > Ding auskommt -- inklusive der Entwicklung von LSP selbst. Und trotzdem haben KDevelop und viele weitere IDEs und Editoren auf LSP umgestellt, einfach weil das viel sinnvoller ist, als etwas eigenes zu Kreiieren, das dann meist, aufgrund fehlender Manpower nur halb so gut ist. > Weißt Du, ich hab' jetzt schon eine ganze Menge solcher "Gott-Features" > gesehen, ohne die Entwickler angeblich nicht mehr arbeiten können. Die > meisten davon sind nach kurzer Zeit wieder sang- und klanglos > untergegangen. Syntax-Highlighting, Autocompletion, -Brackets und > -Indentation haben sich allerdings gehalten. Begreife erst einmal die Bedeutung des LSP. > Dein toller nano ist da übrigens nicht aufgeführt. Muss er nicht, denn nano ist keine IDE! > Emacs und vi dagegen schon. Was man erwarten kann, wenn man es als IDE Ersatz bewirbt.
Nano schrieb: > Muss er nicht, denn nano ist keine IDE! Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist ebenfalls keine IDE, sondern ein Editor.
Ein T. schrieb: >>> Nano schrieb: >>>> ALT + G >>>> STRG + T >>>> " eingeben + Enter drücken >>>> 1 cursor nach rechts >>>> ALT + A = Markerung gesetzt >>>> ALT + G >>>> STRG + T >>>> " eingeben + Enter drücken >>>> STRK + K >>> >>> Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel >>> schneller zeichenweise mit der Delete-Taste. >> >> Tja keine Ahnung wer das braucht, es ging ja nur darum zu >> veranschaulichen das das auch geht und bei nano erschließt sich das >> sogar intuitiv. > > Äh... also wenn das "intuitiv" ist, haben wir beide fundamental > unterschiedliche Vorstellungen von der Bedeutung dieses Wortes. Ne, es ist ein Fakt, dass das intuitiv ist, da nano die Hotkeys entsprechend in der unteren Leiste mit Beschriftung anzeigt. Du musst im Prinzip nur ALT + G wissen. Der Rest erklärt sich selbst. > >>> Vi (ohne 'm') alles andere als Bloatware: >>> >>>
1 | >>> vi: Installed Size : 315.50 KiB |
2 | >>> nano: Installed Size : 2.48 MiB |
3 | >>> |
>> >> Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht? > > Egal, nano ist offensichtlich Bloatware. 2,5 MB für einen Editor, dem > obendrein auch noch Features fehlen, die Du hier anpreist wie > geschnittenes Brot... wow. Nano hat doch das Feature. Oben ist es belegt, du hast es sogar selber zitiert. Und vi hat das Feature übrigens nicht. Und mit pico funktioniert bereits meine eigene Lösung.
Nano schrieb: > Nochmal für die ganz Dummen: > DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz > bestimmtes und das hat mit Layouts auch nichts zu tun. Ja, und weiter? Hände in Grundhaltung, Daumen über Space, Layout ist laut von dir verlinkten Artikel nicht festgelegt. Was genau ist eigentlich dein Punkt (was ich mich zunehmend eh frage, wenn du auf solchen Nebensächlichkeiten rumrödelst, die zum eigentlichen Thema nix beitragen). Also, bitte beantworte mir mit klaren Worten: was ist dein Problem mit dem Zehnfingersystem in diesem Kontext?
:
Bearbeitet durch User
ThomasW schrieb: > ...Einfach Mal > über den Tellerrand schauen! > > Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die > Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam! Zum Glück glaubst du das nur, eine Behauptung wider besserem Wissen wäre nämlich eine Lüge. Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger Integration gescheitert ist. Das impliziert, dass ich mich mehrere Tage mit vim beschäftigt habe. Und dann haben wir hier die Hass und Pöbelfraktion, die nicht wahrhaben will, dass und warum man vim ablehnt. Die Argumente und Begründungen stehen sogar dabei, aber die Pöbelfraktion verhält sich halt wie ein kleines Kind. Getreu dem Motto "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen wird."
Nano schrieb im Beitrag # > "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen > wird." Weshalb sollte man auch vim zerreißen? Er ist nun mal der genialste Editor - und die, die das nicht begreifen können … für die gibt es halt Nano
Jack V. schrieb: > Nano schrieb: >> Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann >> 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig! > > Hörmal: ich akzeptiere vollkommen, dass du Programme, die eine initale > Lernkurve haben, nicht magst, Und das ist jetzt eine Lüge wider besserem Wissen, denn oben stehen meine Gründe bezüglich vim dran und da geht es nicht um die Lernkurve. Und so etwas auch noch für allgemeingültig zu erklären im Sinne von jedes Programm, von Blender bis [such die jedes beliebig komplexe Programm aus] ist noch dreister. Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören und keinen anständigen Diskurs mit Anstand und Niveau führen könenn. > Damit ist > überhaupt nichts verkehrt. Wäre schön, wenn du im Gegenzug die Physik > akzeptieren würdest: in der Zeit, die du zur Bewegung deiner Hand zur > Maus benötigst, hat jemand, der mit der Tastatur gut umgehen kann, die > drei Buchstaben abgesetzt. Dein „Beispiel“ mit der Maus wirkt genauso > krampfhaft, wie deine Shortcut-Wüste für die Funktion von di" oben. Deine kindische Gegenreaktion ist mal wieder albern. Denn auch weiter oben habe ich dir bereits erklärt, dass man beim Programmieren die meiste Zeit nicht mit Tippen verbringt, sondern damit, sich Gedanken zu machen, wie man ein Problem jetzt löst. Die Maus ist da eine willkommene Abwechslung und oh Überraschung, sogar Notpad.exe von Windows kann das mit 2 Tasten und Maus. > Aber just for fun: zeig doch mal bitte kurz auf, wie du ddp umsetzen > würdest :) STRG + K SRRG + U
Nano schrieb: > "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen > wird." Hast du’s mal mit Selbstreflektion versucht? Ich meine: du musst dir bloß mal die schiere Masse deiner Beiträge hier anschauen, teils mehrere am Stück, dazu diese absurden „Beispiele“, das mit der Strg+…-Orgie und das mit der Maus, um ›di"‹ und ›2dd‹ nachzubilden, um gerade Nano als überlegen darzustellen. Dazu noch diese Unterstellungen, wie die oben zitierte, um Vim-User als infantil darzustellen … Hatte ich am Ende Recht mit der Vermutung, dass da ein Trauma hinter steht? Ich warte übrigens noch auf deine Umsetzung von ›ddp‹ in nano oder pico – wäre ganz lieb, wenn du die noch nachreichen könntest. Ich erzähle dir dann auch wieder, warum ›ddp‹ zu schreiben erheblich schneller ist, als deine Strg+Maus-Orgie :) Nano schrieb: > Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger > Integration gescheitert ist. Ja nē – is klar: Debugger. Kannst du dir nicht einfach eingestehen, dass du dich mit Vim im Grunde nicht einmal ausreichend beschäftigt hast, um überhaupt zu wissen, wovon hier alle schreiben? Mein Vorschlag: mach mal ’n Wochenende mit Vim rum. Tutorial durchgehen, viel praktisch anwenden und so. Und dann lies nochmal, was du hier so abgelassen hast. Ich verspreche dir: du wirst dich sehr schämen :)
Jack V. schrieb: > Nano schrieb: >> Muss er nicht, denn nano ist keine IDE! > > Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist > ebenfalls keine IDE, sondern ein Editor. Du erzählst mir da nichts schockierendes, ich bin eher über deine Intelligenz schockiert. Denn hier wird von dir und anderen vim ja als IDE Ersatz beworben. In dem ganzen Thread willst du mir erklären, warum ich anstatt einer IDE vim einsetzen soll und jetzt willst du plötzlich zurückrudern und sagst nun, dass du das alles nicht so gemeint hast?
Jack V. schrieb: > Nano schrieb: >> Nochmal für die ganz Dummen: >> DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz >> bestimmtes und das hat mit Layouts auch nichts zu tun. > > Ja, und weiter? Wer erklärt es ihm noch einmal? Oben haben es ja einige schon getan, aber bei ihm dauert das wohl länger. Also, wer erklärt es noch einmal, so dass er es kapiert?
Jack V. schrieb: > Dazu noch diese Unterstellungen, wie die oben > zitierte, um Vim-User als infantil darzustellen … Ich habe da ausschließlich nur von dir gesprochen und dieses Pöbelverhalten hast du schon gestern gezeigt und auch da habe ich dich darauf hingewiesen und du willst nichts daraus lernen. > Ich warte übrigens noch auf deine Umsetzung von ›ddp‹ in nano oder pico > – wäre ganz lieb, Kannst du nicht lesen? Oben steht es bereits. Jack V. schrieb: > Nano schrieb: >> Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger >> Integration gescheitert ist. > > Ja nē – is klar: Debugger. Kannst du dir nicht einfach eingestehen, dass > du dich mit Vim im Grunde nicht einmal ausreichend beschäftigt hast, um > überhaupt zu wissen, wovon hier alle schreiben? Wie schon gesagt, lies oben nochmal nach. Am besten fängst du mit dem Thread von ganz von vorne an und liest die alten Beiträge. Der Thread wurde ja eh aus dem Grab geholt. > Mein Vorschlag: mach mal ’n Wochenende mit Vim rum. Tutorial durchgehen, > viel praktisch anwenden und so. Und dann lies nochmal, was du hier so > abgelassen hast. Ich verspreche dir: du wirst dich sehr schämen :) Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass ich das schon vor Jahren gemacht habe. Und nö, ich schäm mich nicht, ich bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt.
Nano schrieb: > Denn hier wird von dir und anderen vim ja als > IDE Ersatz beworben. Dann zeig mal eine Kostprobe deiner Intelligenz, und zitiere die Stelle, an der ich dieses mache. Ebenso die Stelle, an der ich dir erklären möchte, dass du Vim anstelle einer IDE einsetzen solltes! Wie? Kannst du nicht? Weil ich nämlich das genaue Gegenteil geschrieben habe? Na sowas aber auch … Ernstgemeinte Frage: merkst du es wirklich nicht selbst? Nano schrieb: > Wer erklärt es ihm noch einmal? Erklär’ du mir doch bitte genau einmal, was das Problem mit dem Zehnfingersystem und Vim sein soll. In meinem täglichen Erleben harmoniert das nämlich ganz wunderbar, insbesondere im Zusammenhang mit Neo2. Wie? Kannst du nicht? Weil es nämlich gar kein Problem mit dem Zehnfingersystem und Vim gibt, sondern beide ganz ausgezeichnet harmonieren? Na sowas aber auch … Nano schrieb: > Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass > ich das schon vor Jahren gemacht habe. Sorry, aber ich muss da nun mal direkt fragen: was bringt’s dir, so dreist zu lügen?
:
Bearbeitet durch User
Ergänzung zu: > ich > bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt. Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem in diesem Thread. Gestern hast du übrigens gesagt, dass du dich aus dem Thread entfernst.
Nano schrieb: > Ergänzung zu: > >> ich >> bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt. > > Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem > in diesem Thread. Ja, komm – ich kopier’s einmal für dich zusammen. Wenn du’s dann noch nicht erfasst hast, weiß ich auch nicht weiter. Dann gehe ich davon aus, dass du ’n …ter Troll bist, und nicht nur von eingeschränkter Auffassungsgabe: Jack V. schrieb: > ich akzeptiere vollkommen, dass du Programme, die eine initale > Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist > überhaupt nichts verkehrt. Jack V. schrieb: > Nano schrieb: >> Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein >> vim und für Configfiles reicht mir nano. >> Akzeptiere das endlich. > > Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen, > dass das für mich vollkommen in Ordnung ist, und ich das mehrfach, > direkt und eigentlich unmissverständlich so geschrieben habe. Jack V. schrieb: > Dass Vim nix für dich > ist, hast du ja nun zur Genüge dargelegt, und ich habe auch überhaupt > kein Problem damit – insbesondere käme mir nicht mal die Idee, dir die > überhaupt die weitere Beschäftigung mit dem Programm nahelegen zu > wollen. Nun mach doch bitte auch das Gleiche für deine Behauptung, ich würde Vim als IDE-Ersatz propagiert haben, oder dir gar die Verwendung von Vim als IDE-Ersatz empfohlen haben. Wie, kannst du nicht? Na sowas aber auch … Nano schrieb: > Gestern hast du übrigens gesagt, dass du dich aus dem Thread entfernst. Ja … ärgere mich auch selbst, dass du mit deiner absurden Trollerei wieder Erfolg hattest. Aber danke für die Erinnerung :)
:
Bearbeitet durch User
Es ist schon interessant wie fanatisch man sein Tool lieben kann. Überkochende Emotionen sind ein Garant für gute Unterhaltung.
Jack V. schrieb: > Nano schrieb: >> Denn hier wird von dir und anderen vim ja als >> IDE Ersatz beworben. > > Dann zeig mal eine Kostprobe deiner Intelligenz, und zitiere die > Stelle, an der ich dieses mache. Da du aus dem dem Threadverlauf und Kontext weißt, warum ich eine IDE und nicht vim benutze, (ganz vorne schreibe ich übrigens auch was zum Thema Debuggen) du aber dennoch hier: Beitrag "Re: Vi Editor ausgestorben?" dagegen gehalten hast, sagst du auch mit genau diesem Kommentar, was deiner Meinung beim Programmieren wichtig sei und damit bewirbst du vim als IDE Ersatz. Es ergibt sich also aus dem Kontext. Zumal auch das Beispiel Strings zwischen zwei Quotes programmiertypisch ist. Zum Kochbücher schreiben braucht man so eine Funktion nämlich eher nicht. > Ebenso die Stelle, an der ich dir > erklären möchte, dass du Vim anstelle einer IDE einsetzen solltes! Es ist aus dem Kontext ergebend das gleiche Kommentar. > Wie? Kannst du nicht? Doch, kann ich, siehe dein Kommentar, siehe vorheriger Absatz. > Weil ich nämlich das genaue Gegenteil geschrieben > habe? Na sowas aber auch … Und das ist ein paar Kommentare später genau die Stelle, in der du so etwas zwar behaupten willst, aber mich dann gleich persönlich angreifst, weil ich vim nicht nutze. Damit ist deine Behauptung nicht aufrichtig und somit hinfällig. > Nano schrieb: >> Wer erklärt es ihm noch einmal? > > Erklär’ du mir doch bitte genau einmal, was das Problem mit dem > Zehnfingersystem und Vim sein soll. Ah, du siehst jetzt ein, dass es DAS Zehnfingersystem gibt? Warum nicht gleich so. Fest steht aber und das sieht man hier wieder gut: > In meinem täglichen Erleben > harmoniert das nämlich ganz wunderbar, insbesondere im Zusammenhang mit > Neo2. > > Wie? Kannst du nicht? Weil es nämlich gar kein Problem mit dem > Zehnfingersystem und Vim gibt, sondern beide ganz ausgezeichnet > harmonieren? Na sowas aber auch … Dass du ein Problem damit hast, Niederlagen einzugestehen, denn jetzt, nachdem du festgestellt hast, dass das Zehnfingersystem etwas ganz bestimmtes ist, machst du eine ganz neue Baustelle auf um deine Niederlage zu kaschieren. Und zu deiner Frage, warum das Zehnfingersystem zum Programmieren nicht gut geeignet ist, haben andere hier vor mir schon erklärt, lies da nochmal nach. > Nano schrieb: >> Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass >> ich das schon vor Jahren gemacht habe. > > Sorry, aber ich muss da nun mal direkt fragen: was bringt’s dir, so > dreist zu lügen? Hier: Beitrag "Re: Vi Editor ausgestorben?" da steht und das Kommentar ist aus dem Jahr 2020 (Anmerkung: Inhaltich bezieht sich das sogar noch auf einen Zeitpunkt ein paar Jahre vorher, aber es wurde damals ja nicht nach einem genauen Zeitpunkt gefragt): "Ein paar Tutorials habe ich auch schon durchgearbeitet, aber über kurz oder lang vergisst man die weiterführenden Kommandos halt doch und leistungsfähige GUI Editoren können heutzutage mehr, als mancher Vim Nutzer denkt." Und da Beitrag "Re: Vi Editor ausgestorben?" steht: "Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist deutlich umständlicher, als die Buttons und Tastaturkombinationen in der IDE. Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt sehen können möchte. Bei gdb muss man erst den step eingeben und dann sagen, welche Variablen man anschauen will. Bei der IDE sieht man die Variablenzustände immer und man drückt einfach seine Taste oder den Button. Und da das nicht bei vim voreingestellt ist, hat man noch eine weitere Hürde bis alles passt." Fazit: Hättest halt nur mal den Thread nochmal gelesen, wie ich dir geraten habe. Ich denke damit bist du jetzt aus der Diskussion raus. Du wolltest dich eigentlich bereits gestern schon aus dieser entfernen, schon vergessen.
Nano schrieb: > Es ergibt sich also aus dem Kontext. Du weißt aber schon, dass du bei so zusammengedichteten Kontexten auch mal arg danebenliegen kannst? Nun: in diesem Fall scheint es so zu sein, und du liegst mit deiner Interpretation meiner Beiträge völlig daneben. Tut mir leid, dir das mitteilen zu müssen: du hast die ganze Zeit gegen einen imaginären Feind „argumentiert“. Teils ziemlich … wirr, wenn ich das so sagen darf. Nimm dein Nano und deine IDE, mach deinen Kram damit, aber hör endlich auf, die Leute vollzusülzen, die das Konzept vom Vim kennen und mögen.
:
Bearbeitet durch User
Jack V. schrieb: > Nano schrieb: >> Muss er nicht, denn nano ist keine IDE! > > Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist > ebenfalls keine IDE, sondern ein Editor. Dazu kann man verschiedene Ansichten vertreten, immerhin unterstützen vi(m) und Emacs so ziemlich alle Funktionen, die eine IDE auch hat. Sie sind allerdings deutlich flexibler und besser konfigurierbar, nicht auf Klickibunti angewiesen, meistens wesentlich performanter als die üblichen GUI-Monster und unterstützen deutlich mehr Sprachen als diese. Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell: das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-)
Ein T. schrieb: > Dazu kann man verschiedene Ansichten vertreten, immerhin unterstützen > vi(m) und Emacs so ziemlich alle Funktionen, die eine IDE auch hat. Ja, und man kann sie zu einer IDE konfigurieren – incl. Debugger, Syntaxhighlight, Outlines, Filebrowser, etc., pp. Aber letztlich sind es Editoren, wenn auch ziemlich ausgefeilte und umfangreiche Vertreter ihrer Spezies, und wenn man einem User, der stark auf „discoverability” angewiesen ist und der daher die herkömmlichen im hohen Maße visuell ausgerichteten IDEs verwendet, und der auch von sich aus überhaupt nicht den Wunsch verspürt, daran irgendwas zu ändern, versucht, diese Editoren als IDE anzubieten, dann geht’s schief. Im schlimmsten Falle passiert dann, was man hier vom Gast zu sehen bekommen hat. Sollte man also nicht machen. Anders sieht’s aus, wenn jemand mit dem notwendigen Maß an Neugier und Offenheit von sich aus anfängt, sich das mal genauer anzugucken, und da auch mal ein paar Stunden investiert. Ist wie in der Psychologie: der Patient muss es von sich aus wollen, sonst wird es nichts.
Jack V. schrieb: > Nano schrieb: >> Ergänzung zu: >> >>> ich >>> bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt. >> >> Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem >> in diesem Thread. > > Ja, komm – ich kopier’s einmal für dich zusammen. Wenn du’s dann noch > nicht erfasst hast, weiß ich auch nicht weiter. Dann gehe ich davon aus, > dass du ’n …ter Troll bist, und nicht nur von eingeschränkter > Auffassungsgabe: Und wieder eine Beleidigung… > > Jack V. schrieb: >> ich akzeptiere vollkommen, dass du Programme, die eine initale >> Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist >> überhaupt nichts verkehrt. Nein, das du kein Problem damit hättest, dass ich vim nicht nutze, sagst du zwar immer wieder und du wiederholst dich, du meinst es aber nie so und das habe ich dir bereits Gestern erklärt warum du hier nicht aufrichtig bist: Hier ist dein alter Text: Beitrag "Re: Vi Editor ausgestorben?" Da sagst du zwar, dass du zwar kein Problem damit hättest, dass ich vim nicht nutze, aber dann greifst du mich anschließend direkt wieder an, womit du deine erste Aussage selbst untergräbst und darauf bin ich dann gestern hier eingegangen, wo ich deine persönlichen aggressiven Angriffe dann nochmal detailliert beschrieben habe: Beitrag "Re: Vi Editor ausgestorben?" Da habe ich dir geschrieben: ### Anfang des Zitats: " Jack V. schrieb: > Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es > niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst, > es schlechtzumachen; Das machst du, siehe oben, da habe ich das belegt. Ich habe lediglich meine Meinung dazu gesagt und jetzt hast du ein Problem damit, sie zu akzeptieren, auch wenn du in deinem Eingangssatz gegenteiliges behauptest, so sieht man es hier. .... [gekürzt] Jack V. schrieb: > Trauma vom ersten Start vom Vim, als > du gefangen warst und nicht wieder rausgefunden hattest? Man wird also, wenn man dir nicht folgt und auch vim nutzt, von dir persönlich angegriffen und bekommt von dir dann vorgeworfen: 1. ein Trauma zu haben. 2. gefangen zu sein. Und aus deinen vorherigen Postings: 3. keine Vorstellung zu haben. 4. und mental nicht in der Lage zu sein, es zu erfassen. " ### ENDE des Zitats. Du hast also ein Problem damit, dass du zwar Dinge sagst, aber nicht ernst meinst, denn dein Gesagtes zerstörst du gleich wieder mit persönlichen Beleidigungen gegen mich, also stimmt es nicht, was du uns hier weiß machen willst. Du drehst dich wie ein Wendehals und hast ein grundsätzliches Problem, wenn du nicht im Recht bist. Man sieht das auch bei deinem Ausweichen beim Thema das Zehnfingersystem. > > Jack V. schrieb: >> Nano schrieb: >>> Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein >>> vim und für Configfiles reicht mir nano. >>> Akzeptiere das endlich. >> >> Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen, >> dass das für mich vollkommen in Ordnung ist, und ich das mehrfach, >> direkt und eigentlich unmissverständlich so geschrieben habe. Und dann hast du gleich die Beleidigungen im gleichen Kommentar hinterhergeschickt, also nein, genau das meinst du nicht, es ist für dich nicht in Ordnung, dass ich vim nicht nutze. Wäre es für dich in Ordnung, dann hättest du dir die Beleidigungen sparen können. Aber da du, wie ich es hier jetzt schon mehrfach verdeutlicht habe, ein Problem damit hast, wenn man dein geliebtes vim kritisiert, kommst du auf keinen grünen Zweig. Das Problem liegt hier also allein an dir. Selbst in deinem letzten Posting, wo du erneut beteuerst, dass es dir egal wäre, wenn ich kein Vim nutze, unterstellst du mir, dass ich generell eine Abneigung gegen Programme mit Lernkurve hätte. AUch das ist nicht nur eine Lüge wider besserem Wissen, sondern eben schon wieder ein persönlicher Angriff. Jack V. du hast also Probleme und du solltest endlich mal lernen damit umzugehen, das sagte ich dir gestern schon.
Wer sich dauernd selber versichern muss wie elitär er ist, ist es meistens nicht. Ein T. schrieb: > Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell: > das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat > man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr > flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese > Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von > Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-)
:
Bearbeitet durch User
Walter K. schrieb: > Nano schrieb im Beitrag # > >> "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen >> wird." > > Weshalb sollte man auch vim zerreißen? > Er ist nun mal der genialste Editor - und die, die das nicht begreifen > können … für die gibt es halt Nano Schreib das mal ins EMACS Forum. Auf die Reaktionen bin ich gespannt. :)
Nano schrieb: > Jack V. du hast also Probleme und du solltest endlich mal lernen damit > umzugehen, das sagte ich dir gestern schon. Warte eine Woche. Rufe dann erst den Thread nochmal auf. Guck dir an, wo überall dein Gastnick drübersteht, was in den Beiträgen steht, und wie die Diskussion so verlaufen ist. Und dann überlege ganz in Ruhe, auf wessen Seite die Probleme sein könnten, und wie du sie für dich lösen kannst. Wird warm hier, im Tal der verbrannten Zeit – ich fahr’ dann mal wieder heim. Bis dann o/
Nano schrieb: > Und mit welcher Erweiterung debuggst du deinen Code? Auch wenn's nicht Vim ist: mit GUD beim Emacs. Mit Fenstern für Register, Stacktrace, Disassembly und all dem Kram. Nur, weil du das nicht glauben willst und immer noch so tust, als wären aktuelle Editoren keine GUIs.
Jack V. schrieb: > Nano schrieb: >> Jack V. du hast also Probleme und du solltest endlich mal lernen damit >> umzugehen, das sagte ich dir gestern schon. > > Warte eine Woche. Rufe dann erst den Thread nochmal auf. Guck dir an, wo > überall dein Gastnick drübersteht, was in den Beiträgen steht, und wie > die Diskussion so verlaufen ist. Und dann überlege ganz in Ruhe, auf > wessen Seite die Probleme sein könnten, und wie du sie für dich lösen > kannst. Tja, dass du deine Probleme, in Angesicht der genannten und belegten Beweislage, immer noch nicht erkennen willst, nennt man auch Ignoranz. > Wird warm hier, im Tal der verbrannten Zeit – ich fahr’ dann mal wieder > heim. Bis dann o/ :dh:
Nano schrieb: > Und das ist jetzt eine Lüge [...] > > [...] ist noch dreister. > > Deine kindische Gegenreaktion ist mal wieder albern. [...] > > Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören > und keinen anständigen Diskurs mit Anstand und Niveau führen könenn. Ja, die erkennt man wirklich sehr gut. [Anmerkung des Zitierenden: Die Aussagen wurden etwas umgestellt.]
Ein T. schrieb: > Nano schrieb: >> Und das ist jetzt eine Lüge [...] >> >> [...] ist noch dreister. >> >> Deine kindische Gegenreaktion ist mal wieder albern. [...] >> >> Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören >> und keinen anständigen Diskurs mit Anstand und Niveau führen könenn. > > Ja, die erkennt man wirklich sehr gut. Fakten darf man nennen. Er hat nunmal gelogen. Er war nunmal dreist. Und seine Gegenreaktion war kindisch. Alles Fakt und oben steht die Beweislage. Und ob du auch zur Hass und Pöbelfraktion dazu gehörst, da darf sich jeder selber ein Bild anhand deiner folgenden Kommentare machen. Ich habe die Stellen mal fett markiert: > Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr > (den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt > hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano" > installieren können). Quelle: Beitrag "Re: Vi Editor ausgestorben?" > Aber das ist dann eine andere > Nummer als der "vim.tiny" oder der "nano" von dem aggressiven Gast hier. Quelle: Beitrag "Re: Vi Editor ausgestorben?" > *Lesen bildet:* [1]. Dein toller nano ist da übrigens nicht aufgeführt. Beitrag "Re: Vi Editor ausgestorben?" > Diese > Stärken wissen Menschen, *deren Fähigkeiten sich im Schubsen von* > *Computermäusen erschöpfen,* natürlich nicht zu schätzen. ;-) Beitrag "Re: Vi Editor ausgestorben?" Ich schließe mich daher Le X. Kommentar an, denn Recht hat er. Da schrieb er: Le X. schrieb: > Wer sich dauernd selber versichern muss wie elitär er ist, ist es > meistens nicht. > > Ein T. schrieb: >> Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell: >> das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat >> man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr >> flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese >> Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von >> Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-) Beitrag "Re: Vi Editor ausgestorben?"
Nano, was ist los mit dir? Dein Hass gegenüber Vim scheint dich inzwischen ja regelrecht aufzufressen. Du kochst ja noch mehr als der c-hater, wenn irgendjemand in seiner Gegenwart den bösen Buchstaben ausspricht =8-o Und das nur wegen eines Texteditors, den dich kein Mensch der Welt zu nutzen zwingt? Ich möchte dir ja nicht zu nahe treten, aber hat dir Bram Moolenaar vielleicht deine Alte ausgespannt? Entschuldige bitte diesen Gedanken, aber mir fallen im Moment fast keine anderen Gründe ein, die einen Menschen so sehr auf 180 bringen können. Warum bist du überhaupt in diesen Thread eingestiegen. Nach eigener Aussage benutzt du Eclipse und Nano, weswegen dir Vi(m) doch völlig am Allerwertesten vorbei gehen kann, oder? Ich persönlich bin kein Freund von Eclipse, weil dessen Konzept und Umsetzung nicht meiner Arbeitsweise entsprechen. Trotzdem erkenne ich, dass viele (auch in meinem Bekanntenkreis) sinnvoll damit arbeiten können, und käme deswegen nie auf die Idee, einen Kreuzzug gegen diese Software zu beginnen. Zum einen hätte so eine Aktion für mich keinerlei persönlichen Nutzen, zum anderen würde ich mich damit wohl ziemlich lächerlich machen, also lass ich's besser bleiben :) Geh doch einfach mal nach draußen, iss ein Eis, trink etwas Kühles dazu und komm nach zwei Stunden wieder zurück. Vielleicht schmunzelst du dann selber über die komischen Dinge, die du hier in den letzten Tagen von dir gegeben hast :)
Yalu X. schrieb: > Dein Hass gegenüber Vim scheint dich inzwischen ja regelrecht > aufzufressen Es ist schon interessant wie unterschiedlich man Diskussionen aufnehmen kann. Für mich als Mitleser mit neutraler Haltung zu vim stellt sich der Sachverhalt ganz anders da. Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht so taugt und auch ein paar Sätze als Begründung mitgeliefert. Ob man seine Ansichten nun teilt oder nicht, aber sein recht harmloser Kommentar erst hat hier Leute auf den Plan gerufen die man durchaus als Fanboys betrachten darf und deren Werben um ein dummes Tipp-Tool ich durchaus als aggresiv bezeichnen würde. Und ja, deren Argumente waren nicht nur sachlich sondern zielten auch darauf ab, persönlich einen Stich zu setzen. Und leider hat sich auch die Moderation nicht erwehren können, mit drauf zu hauen. Der nano kann halt nicht raus aus seiner Haut. Für ihn ist das wohl wichtig darzustellen dass nicht er angefangen hat. Ich selber hätt mir gedacht "dann leckts mich halt am Arsch". Was interessiert schon was ein paar Leute im Netz denken? Nichtsdestotrotz, ich hatte meinen Spaß. Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal vorstellen ;-)
:
Bearbeitet durch User
Rolf M. schrieb: > Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende > Funktionalität (kontextsensitive Autovervollständigung, Anzeige von > Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.) > für einige Sprachen auch schon ohne Language Server mitbringt. Ich habe das mal installiert, aber wie aktiviere oder nutze ich das jetzt?
1 | pi@raspberrypi:~ $ sudo apt search ^vim-youcompleteme |
2 | Sortierung… Fertig |
3 | Volltextsuche… Fertig |
4 | vim-youcompleteme/stable,now 0+20200825+git2afee9d+ds-2 all [installiert] |
5 | fast, as-you-type, fuzzy-search code completion engine for Vim |
6 | |
7 | pi@raspberrypi:~ $ vim-addon-manager |
8 | # Name User Status System Status |
9 | editexisting removed removed |
10 | jinja removed removed |
11 | justify removed removed |
12 | matchit removed removed |
13 | youcompleteme removed removed |
Der addon-manager zeigt es als removed an.
Le X. schrieb: > Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal > vorstellen Kannst mal sehen. Ob es in dreißig Jahren sowas mit Eclipse vs. IntelliJ oder Atom vs. Sublime geben wird? Ich glaube nicht … ;) Nano schrieb: > Er hat nunmal gelogen. Eigentlich wollte ich mich nun wieder raushalten, aber bei einer solchen Unterstellung erwarte ich dann doch schon, dass entsprechende Nachweise erbracht werden. Und zwar nicht das, was du dir da an wirren Unterstellungen zusammengedichtet oder was du „interpretiert“ hast, sondern exakt das Zitat, das objektiv belegt, dass ich gelogen (im Deutschen steht das für: bewusst die Unwahrheit sagen) hätte. Bitte keine drei Meter Textwand mit Schwurbeleien auf verschiedenen Nebenschauplätzen auf drölf Beiträge am Stück verteilt, wie oben – ich fordere dich hiermit auf, präzise die Unterstellung, ich hätte gelogen, zu belegen!
:
Bearbeitet durch User
Le X. schrieb: > ... > Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht > so taugt und auch ein paar Sätze als Begründung mitgeliefert. > > Ob man seine Ansichten nun teilt oder nicht, aber sein recht harmloser > Kommentar erst hat hier Leute auf den Plan gerufen die man durchaus als > Fanboys betrachten darf und deren Werben um ein dummes Tipp-Tool ich > durchaus als aggresiv bezeichnen würde. > Und ja, deren Argumente waren nicht nur sachlich sondern zielten auch > darauf ab, persönlich einen Stich zu setzen. Und leider hat sich auch > die Moderation nicht erwehren können, mit drauf zu hauen. > > Der nano kann halt nicht raus aus seiner Haut. Für ihn ist das wohl > wichtig darzustellen dass nicht er angefangen hat. Danke. So ist es, ich habe eigentlich nur Begründet warum ich vim nicht nutze und damit konnten die Fanboys nicht umgehen, worauf sie mich dann persönlich angriffen. Und dann verteidige ich mich und meine Position. @Yalu X. Ich bin hier übrigens ganz entspannt.
Nano schrieb: > Ein T. schrieb: > Fakten darf man nennen. Ja, für alternative Fakten muß man kein Präsident eines Staates sein. > Und ob du auch zur Hass und Pöbelfraktion dazu gehörst, da darf sich > jeder selber ein Bild anhand deiner folgenden Kommentare machen. Ich > habe die Stellen mal fett markiert: > >> Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr >> (den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt >> hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano" >> installieren können). > Quelle: > Beitrag "Re: Vi Editor ausgestorben?" Wow, sogar mit Quellenangabe, da hast Du ja fast schon eine wissenschaftliche Arbeit abgeliefert. Trotzdem bleibe ich bei meiner Aussage und halte das, was die Debian-Leute da gemacht haben, für bescheuert: erst "specken" sie einen wohlbekannten und unter allen UNIXoiden Systemen vorhandenen Editor ab und obwohl er nicht die von den anderen Versionen bekannten Features besitzt, benennen sie ihn nicht einmal um: der Name ist derselbe wie beim Original, nur die Features sind es nicht. Darauf bist ja sogar Du als erklärter Debian-Fanboy hereingefallen, herzlichen Glückwunsch auch. Das finde ich schon vollkommen irre, und um die "Einsparung" mal in $Summe von $Einheit von $Währung zu beziffern, habe ich die überteuerte NvME SSDPE2KX040T801 von Intel [1] zur Berechnung herangezogen: vier (4) TB Diskspace für 1009,90 Euro. Wenn man dieses Gerät benutzt und eine Einsparung von 1,5 MB ansetzt, dann beträgt diese grandiose Einsparung nicht einmal 0.04 Eurocent. Noch viel bescheuerter wird diese ganze Nummer aber, wenn dieselben Spinner dann als Alternavive eine Software installieren, die 2,5 MB groß ist. Ich meine, mal ehrlich: wer macht sowas, die Kompatibilität willkürlich und völlig sinnlos brechen für einen Gewinn, der mit "verschwindend" noch sehr wohlwollend benannt ist? Wie unprofessionell! Denselben Schwachsinn machen die Debianer ja auch mit der Dash anstelle der Bash, auch das eine unfaßbar dämliche Entscheidung -- insbesondere vor dem Hintergrund moderner Versionen mit systemd, wo dieser Austausch der Shells außer Verwirrung nichts, aber auch rein gar nichts nutzt. Weißt Du, wir begegnen uns hier ja nicht zum ersten Mal, und tatsächlich bin ich nach unseren letzten... Gesprächen mehrmals in mich gegangen und habe sogar Freunde und Kollegen gebeten, die Threads zu lesen und mir zu sagen, ob es vielleicht an mir läge und ich Dich beleidigt, provoziert, oder belogen hätte. Aber jetzt stelle ich fest, daß das Problem offenbar doch nicht bei mir liegt und Du bei anderen, die eine andere Meinung vertreten als Du, genauso reagierst wie bei mir -- sogar dann, wenn diese Menschen Dir nicht einmal widersprechen! Sobald eine andere Ansicht als Deine eigene vertreten wird als Deine, scheinst Du das als eine persönliche Beleidigung wahrzunehmen, überziehst den oder die Betreffenden mit endlosen Postings, die aber längst nichts mehr mit dem Thema zu tun haben und in denen Du Dich auf komplette Nebensächlichkeiten kaprizierst, dann bezichtigst Du Dein Gegenüber der Lüge und anderer Böswilligkeiten sogar dann, wenn diese Dir ausdrücklich gesagt haben, daß niemand Dir Deine Entscheidung madig machen oder Dein Lieblingsförmchen wegnehmen will. Sei mir bitte nicht wieder böse, aber: bist Du sicher, daß die Kommunikation in so einem Forum wie diesem Dir (oder dem Forum) gut tut? Geh' doch mal eine Runde spazieren, hör' ein bisschen erbauliche Musik, spiel mit dem Hund oder der Katze, hack' einen Klafter Holz oder tu' etwas anderes, das Dich entspannt. [1] https://www.hiq24.de/shop//Intel-SSD-4.0TB-DC-P4510----2.5%22-U.2-PCIe-NVMe-3.1/261264/100/i.html?
Le X. schrieb: > Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht > so taugt und auch ein paar Sätze als Begründung mitgeliefert. Naja, sein erstes Posting hier fing an mit: Nano schrieb: > Gott bewahre! > > Ich benutze lieber eine richtige IDE.
Jack V. schrieb: > Eigentlich wollte ich mich nun wieder raushalten, aber bei einer solchen > Unterstellung erwarte ich dann doch schon, dass entsprechende Nachweise > erbracht werden. Und zwar nicht das, was du dir da an wirren > Unterstellungen zusammengedichtet oder was du „interpretiert“ hast, > sondern exakt das Zitat, das objektiv belegt, dass ich gelogen (im > Deutschen steht das für: bewusst die Unwahrheit sagen) hätte. Das habe ich alles schon oben belegt. Die Kurzform ein Beispiel wo du gelogen hast: Du hast mir unterstellt, dass ich etwas gegen vim und grundsätzlich auch alle anderen Programme mit steiler Lernkurve hätte, weil es eine steile Lernkurve hätte und das wissentlich, denn meine Gründe warum ich vim ablehne war nicht die Lernkurve, sondern die anderen Punkte, die ich oben bereits angeführt habe und die jeder nachlesen konnte, auch du. Also hast du wissentlich wider besserem Wissen etwas behauptet, was nicht stimmt und das nennt man nun einmal eine Lüge. Raussuchen kannst du die Kommentare im Thread selber, belegt habe ich es bereits und ich mache mir die Arbeit jetzt nicht noch einmal, nur weil du nicht willens bist zu lesen.
Nano schrieb: > @Yalu X. > Ich bin hier übrigens ganz entspannt. Sehr gut. Dann zeig das aber auch :)
Nano schrieb: > Also hast du wissentlich wider besserem Wissen etwas behauptet, was > nicht stimmt und das nennt man nun einmal eine Lüge. Offensichtlich hast du eine andere Definition von Lüge, als ich und die Leute, die ich kenne, und die Wörterbücher, die ich kenne. Nachdem du nämlich kenntlich gemacht hast, dass die Lernkurve nicht dein Punkt wäre, habe ich das kein weiteres Mal angebracht, wie du auch problemlos selbst feststellen kannst. Es kann daher mitnichten von einer wissentlichen Falschbehauptung, vulgo „Lüge“, gesprochen werden. Bitte zeige nun ganz entspannt einen richtigen Beleg für deine wiederholte Unterstellung auf. Warum du bei dem Thema derart abgehst, dass du dich derart angegriffen und verfolgt fühltest, und aus dieser Verteidigungshaltung ein solches Maß an Textwüste incl. unsachlicher Angriffe produzieren musstest, ist mir allerdings auch schleierhaft. Ist mir schon klar, dass ich daraufhin ebenfalls provoziert habe, aber nur davon, dass einem jemand zeigt, dass bestimmte Aufgaben mit Programm V schneller und bequemer zu erledigen sind, als mit Programm N, kann man doch eigentlich nicht so abgehen? Wie auch immer – wir warten noch auf deinen Weg, wie ›ddp‹ in Nano umzusetzen wäre.
:
Bearbeitet durch User
Yalu X. schrieb: > Und das nur wegen eines Texteditors, ... Es ist schon irgendwie lustig - eher traurig, wie sich erwachsene Menschen über 2 Jahre um ein Unix Urgestein wie den vi streiten können. Der vi, mittlerweile in den Mittvierziger, hatte ganz sicher seine Daseinsberechtigung, weil er eben wenig Speicher brauchte und auch im Terminal funktionierte. Für die damalige Zeit ohne Zweifel hervorragend. Hinzu kam das er halt auf allen *X'en vorhanden war. Dennoch die Bedienung mit den Tastenkombis, Tasten und die Umschalterei zwischen den einzelnen Modi ist mehr als gewöhnungsbedürftig, aber gut man kann (mußte) alles lernen. Die Zeit ist aber nicht stehen geblieben und ob der Editor nun 200kB oder 2,5MB belegt ist bei den heutigen Rechnern nun wirklich Rille. Heutzutage sind grafische Editoren angesagt, die eigentlich keine Wünsche mehr offen lassen und für die man nicht erst mal Dokumentation lesen muß, um irgendetwas mach zu können - allein das Beenden des Editors stellt denjenigen, der das erste Mal den vi benutzt, vor eine unüberwindbare Hürde. Klar wer das Teil jahrzehntelang intensiv nutzt und die Funktion jeder Taste kennt, wird ihn wohl weiter benutzen - es ist für ihn halt die gewohnte Arbeitsumgebung. Wer neu einsteigt oder umsteigt wird wohl eher auf einen grafischen Editor setzen und wenn's mal auf der Shell bzw. remote im ssh-Terminal sein soll dann halt den nano. Zwischenzeitlich gibt es aber auch grafische Editoren, zumindest unter Win (z.B. PSPad), mit denen man auch per SFTP sehr komfortabel auf dem Remotesystem arbeiten kann - man sitzt quasi am Remoterechner. Keine Ahnung ob es so etwas auch für Linux gibt, könnte mir das aber durchaus vorstellen. Ansonsten stimme ich Lex zu, wenn er schreibt: Le X. schrieb: > Nichtsdestotrotz, ich hatte meinen Spaß. > Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal > vorstellen ;-) Man kann eigentlich seinem ganzen Beitrag nur zu stimmen.
Jack V. schrieb: > Nano schrieb: >> Also hast du wissentlich wider besserem Wissen etwas behauptet, was >> nicht stimmt und das nennt man nun einmal eine Lüge. > > Offensichtlich hast du eine andere Definition von Lüge, als ich Die Definition einer Lüge ist juristisch definiert als eine unwahre Tatsachenbehauptung wider besserem Wissen. Beides muss erfüllt sein, sowohl dass die Tatsachenbehauptung unwahr ist, als auch, dass sie wider besserem Wissen geäußert wird. Beides war bei dir erfüllt. Anders wäre es, wenn ich im Thread nicht erwähnt hätte, warum ich vim ablehne, dann wäre es zwar immer noch eine unwahre Tatsachenbehauptung seitens dir, aber noch keine wider besserem Wissen. Da du aber den Grund kanntest, da er ja im Thread stand und lesbar für alle war, war es eine Tatsachenbehauptung wider besserem Wissen. > Warum du ... ein solches > Maß an Textwüste incl. unsachlicher Angriffe produzieren musstest, Siehe oben, du hat mich angegriffen, nicht anders herum. > Wie auch immer – wir warten noch auf deinen Weg, wie ›ddp‹ in Nano > umzusetzen wäre. Steht oben, das hatte ich dir schon letztes mal gesagt, als du ein zweites mal gefragt hast, jetzt fragst du ein drittes mal. Du solltest halt meine Antworten auch mal lesen.
Jack V. schrieb: > Kannst mal sehen. Ob es in dreißig Jahren sowas mit Eclipse vs. IntelliJ > oder Atom vs. Sublime geben wird? Ich glaube nicht … ;) Nö, da sind die längst über holt und es gibt was Neues. Ob das dann besser ist sei mal dahin gestellt. Dennoch werden sich die Hardcoreunixer immer noch mit dem Rest der Welt über den vi/vim streiten. Ist halt so - jedem Tierchen sein Pläsierchen. Darf ja auch jeder gern halten wie er mag.
Jack V. schrieb: > Ist wie in der Psychologie: der Patient muss es von sich aus wollen, > sonst wird es nichts. Naja, nicht so ganz. Man denke an eine Schlaganfallselbsthilfegruppe. Die wollen normalerweise auch trainieren, haben aber oft eher unpassende Trainer, und so keine Motivation. Und ohne Motivation läuft nix. (!) Mit den reden bringt auch nicht viel, die argumentieren dann in etwa so: so eine linke (oder rechte) Hand braucht man doch eigentlich gar nicht. Unabhängig davon und darüber hinaus hier: Kognitive Dissonanz Ich finde die Unterscheidung zwischen "Sichtbar" und "Unsichtbar" eher etwas untreffend. Tatsächlich geht es um Bedienung, und die kann man sowohl intern (sichtbar vs sichtbar) wie auch außen (unsichtbar vs unsichtbar) unterscheiden wie auch (sichtbar vs unsichtbar) Die muss aber oft jeder selbst entscheiden. Den TX16W Sampler von Yamaha hatten früher viele schnell wieder veräußert, wegen der komplizierten Bedienung. Ich fand die nicht so schlimm, ich hatte mich eher über die Möglichkeiten gefreut. Die sehr gute Emu Emax2 Bedienung konnte man dem nicht ansehen. Aber man konnte darüber in Fachzeitschriften lesen. Ohne aber zu wissen, wie das gemeint war. Die Bedienung musste man "erfahren", um zu erkennen, wie gut die tatsächlich ist. Ausdrucksstärke ist für mich eher ein Begriff für Kunst, mit Bezug auf Können. Ansonsten: Was ist eigentlich der Unterschied zu "Klickibunti"? Tastaturhengst, Konsolerator, Autist, oder sowas in der Art? Notepad hat seinen Charme, aber der ist halt - bewiesenermaßen - für einige Leute nicht erkennbar. Früher hatte ich eine andere Haltung, da dachte ich über Notepad, so ein popelding, und freute mich über so ein tolles Programm wie Editpad. Man sollte unter Linux nicht davor zurückschrecken, Notepad über Wine aufzurufen. Aber extra für Notepad Wine zu installieren, das ist natürlich Quatsch.
Zeno schrieb: > Nö, da sind die längst über holt und es gibt was Neues. > […] > Dennoch werden sich die Hardcoreunixer immer noch mit dem Rest der Welt > über den vi/vim streiten. Das wären dann siebzig Jahre (von vi in seinen Vierzigern ausgehend, wie von dir selbst geschrieben wurde). Spricht schon irgendwie für solide Software, oder? ;) Nano schrieb: > Beides war bei dir erfüllt. Davon, dass du’s gebetsmühlenhaft wiederholst, wird es nicht wahrer. Du kannst keine Lüge belegen, weil keine da war – und damit hat es sich. Nano schrieb: > Steht oben, das hatte ich dir schon letztes mal gesagt, als du ein > zweites mal gefragt hast, jetzt fragst du ein drittes mal. Du solltest > halt meine Antworten auch mal lesen. Ja – tut mir leid, ist tatsächlich in den Buchstabenwüsten untergegangen. Strg-k und Strg-u also, ja? In einem grad eigens zum Testen installierten Nano löscht das die aktuelle Zeile und fügt sie an der gleichen Stelle wieder ein. Das ist nicht, was ›ddp‹ macht; das entspräche ›ddP‹ Weil ich das Ding grad schon mal installiert habe: Nano schrieb: > In Nano: > Cursor in Zeile platzieren. > ALT + G > STRG + T > " eingeben + Enter drücken > 1 cursor nach rechts > ALT + A = Markerung gesetzt > ALT + G > STRG + T > " eingeben + Enter drücken > STRK + K funktioniert bei mir auch nicht. GNU nano, Version 6.3
:
Bearbeitet durch User
Jack V. schrieb: > funktioniert bei mir auch nicht. GNU nano, Version 6.3 Bei mir auch nicht. Ich wollte aber nicht kleinlich sein und habe das Problem erst einmal für mich behalten, um die Diskussion nicht weiter anzuheizen.
Yalu X. schrieb: > Bei mir auch nicht. Ich wollte aber nicht kleinlich sein und habe das > Problem erst einmal für mich behalten, um die Diskussion nicht weiter > anzuheizen. Auf meiner Fedora Installation ging das mit di" auch nicht. Auf der alten FullBlown Kali-Version in der VM aber schon. Insofern war das Beispiel vielleicht nicht so glücklich gewählt. Ich fand es mal sehr verfänglich, dass man z.B. gruseligen Java-Code in einem Rutsch sehr viel netter aussehen lassen kann. Aber das mit dem Modewechsel, den 7Js, 5dws usw. oder versehentliche Vertipper vermeiden, das braucht seine Zeit. Man muss ja auch einen gewissen Blick entwickeln, welche Werte passen, welcher Workflow fließt, und das geht halt nicht von heute auf morgen, oder mal eben in 30 Min.
Nano schrieb: > ThomasW schrieb: > >> ...Einfach Mal >> über den Tellerrand schauen! >> Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die >> Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam! > > Zum Glück glaubst du das nur, eine Behauptung wider besserem Wissen wäre > nämlich eine Lüge. > Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger > Integration gescheitert ist. > Das impliziert, dass ich mich mehrere Tage mit vim beschäftigt habe. > Und dann haben wir hier die Hass und Pöbelfraktion, die nicht wahrhaben > will, dass und warum man vim ablehnt. Die Argumente und Begründungen > stehen sogar dabei, aber die Pöbelfraktion verhält sich halt wie ein > kleines Kind. > Getreu dem Motto > "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen > wird." Das ist der Teil aus meinem Post der dir am wichtigsten war? Wow! Wenn du meinen ganzen Beitrag gelesen hättest, dann hättest du vielleicht auch verstanden warum es überhaupt keine Debugger-Integration in einen Texteditor braucht. Das ist in meinen Augen ohnehin der falsche Ansatz. Man kann nämlich einfach den Vim als Plugin in IDEs nutzen. Dann hast du deinen Debugger ohne grosses Theater!
Jack V. schrieb: > Nano schrieb: >> Beides war bei dir erfüllt. > > Davon, dass du’s gebetsmühlenhaft wiederholst, wird es nicht wahrer. Du > kannst keine Lüge belegen, weil keine da war – und damit hat es sich. Ich glaube inzwischen, dass du hier nur trollst. > Strg-k und Strg-u also, ja? In einem grad eigens zum Testen > installierten Nano löscht das die aktuelle Zeile und fügt sie an der > gleichen Stelle wieder ein. Das ist nicht, was ›ddp‹ macht; das > entspräche ›ddP‹ Du willst also zwei Zeile vertauschen? Das ist zumindest das was ddp macht, ja? Nichts leichter als das, du gehst an den Anfang der Zeile und drückst STRG + K Cursor runter STRG + U In Kate geht das übrigens noch einfacher. Einfach Shift + STRG Taste gedrückt halten und Cursor Taste nach unten, fertig. Das geht sogar mit ganzen Zeilen, einfach mehrere Zeilen markieren und dann wie gerade beschrieben. > Nano schrieb: >> In Nano: >> Cursor in Zeile platzieren. >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> 1 cursor nach rechts >> ALT + A = Markerung gesetzt >> ALT + G >> STRG + T >> " eingeben + Enter drücken >> STRK + K > > funktioniert bei mir auch nicht. GNU nano, Version 6.3 Die 1 steht NICHT für die 1 Taste, sondern bedeutet ein cursor runter. Und am Ende ist das STRK nur ein Tippfehler, es sollte STRG heißen.
Nano schrieb: > Nichts leichter als das, du gehst an den Anfang der Zeile und drückst > > STRG + K > Cursor runter Wozu mit dem Cursor an den Zeilenanfang? Es reicht wenn der Cursor in der gewünschten Zeile steht. Nach dem Ausschneiden hüpft er dann automatisch auf den Zeilenanfang.
Nano schrieb: > Ich glaube inzwischen, dass du hier nur trollst. Komisch, geht mir bei dir auch so: Du erinnerst dich – es ging bei diesen Beispielen überhaupt gar nicht darum, ob man die Aufgabe im Nano mit Tastatur und Maus ebenso erledigt bekommt, denn das sollte bei Textbearbeitungsaufgaben in einem Editor immer der Fall sein. Es ging darum, es mit vergleichbarem Aufwand und in vergleichbarer Zeit zu erledigen. Und darum, dass deine aufgezeigten Wege da eigentlich nur eines zeigen: geht nicht. Das sollte dir eigentlich selbst aufgefallen sein, wenn du die Dreibuchstabenfolgen mit deinen Konstrukten da vergleichst. Und das waren eher triviale Sachen, wie du ja wohl wissen wirst, wenn du dich, wie du behauptet hast, tatsächlich soweit mit Vim beschäftigt hast, um das einschätzen zu können. Mal ganz objektiv jetzt: di" habe ich in ca. 0,5s geschrieben, und dabei die Hände kaum bewegt. Wie lange brauchst du für deine Strg-Orgie? Nano schrieb: > Nichts leichter als das, du gehst an den Anfang der Zeile und drückst Sind immer noch fünf Tasten und man muss die die Handstellung wechseln, um die Cursortasten zu erreichen. Aber stimmt, war ein eher schlechtes Beispiel. Ich mach mal ein Neues: angehängt findest du eine Textdatei, bei der jede Zeile mit einem . beginnt, der in jeder Zeile entfernt werden soll. Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei in einer Kombination und eine Buchstabentaste, und bin entsprechend in weniger als einer Sekunde durch. Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen? Wieviel Zeit?
:
Bearbeitet durch User
Jack V. schrieb: > Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen? > Wieviel Zeit? Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Jack V. schrieb: > Ich mach mal ein Neues: angehängt findest du eine Textdatei, bei der > jede Zeile mit einem . beginnt, der in jeder Zeile entfernt werden soll. > Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei in einer > Kombination und eine Buchstabentaste, und bin entsprechend in weniger > als einer Sekunde durch. Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5 Zeichen: :%s/^\.//g Freue mich auf deine Lösung!
sepp schrieb: > Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das > macht. Um ein Problem zu lösen, das einmal im Leben vorkommt. Ungefähr fünf Minuten mit der Suchmaschine meines geringsten Misstrauens, und es kommt häufiger vor, dass ich in mehreren zusammenhängenden Zeilen untereinanderstehende Zeichen löschen, oder an diesen Stellen Zeichen einfügen möchte. Gerade wenn man an Configs rumschraubt, ist das ziemlich oft überaus praktisch und zeitsparend – gerade deswegen habe ich es mir ja mal angeeignet, und ich hab die fünf Minuten seither hundertfach wieder reingeholt – falls du darauf hinauswolltest. ThomasW schrieb: > Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5 > Zeichen: :%s/^\.//g Ja, das wäre der zweite Weg, der mir einfiele. Hab aber einen Fehler gemacht: fünf Tastenbetätigungen waren es beim Einfügen der Punkte beim Erstellen der Beispieldatei. Zum Löschen reichen vier: Strg+v (für Visual Block Mode), G (für Cursor in letzte Zeile) und x (für löschen). Wobei es bei deiner Variante mit der Ersetzung egal wäre, wo sich der Cursor zum Anfang befindet, bei meiner Variante ging ich vom frischen Aufruf der Datei mit Cursor am Anfang der ersten Zeile aus – ansonsten wäre der halt noch dort zu positionieren (je nach Variante bis zu drei Tastendrücke zusätzlich: ^gg).
:
Bearbeitet durch User
Die Benutzung von vi(m) ist eine Philosophie, eine Lebenseinstellung, ein Lebensinhalt, absolute Hingabe, ein Selbstzweck um Probleme zu lösen die man sonst nicht hätte, eine Herausforderung. Vielleicht etwa vergleichbar mit einem Leistungssport.
Nano schrieb: > Als Editor war mir Emacs zu groß Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch viel RAM waren, ist schon lange vorbei.
:
Bearbeitet durch User
Anscheinend ist zu diesem Thema wirklich schon alles gesagt worden. Nur halt nicht von jedem. Hinzu kommt, das in gefühlt 90% der Antworten (wenn man sie denn überhaupt so nennen mag) gar nicht auf die Frage eingegangen wird, sondern in Internet-üblicher Art und Weise auf völlig belangloses anderes Zeug hingewiesen wird. Korrektur. Nicht nur hingewiesen, sondern geradezu anders denkenden aufgezwungen wird. Es geht hier aber nicht um völlig belangloses anderes Zeug, es geht hier um den vi editor. Und es geht wohl auch um die Frage warum er selbst nach Jahrzehnten immer noch von einer riesigen Schar sehr gerne und sehr häufig benutzt wird. Aber ich gestehe gerne zu, das diese Erkenntnis zumindest eine rudimentäre Lese- und Verständnisfähigkeit voraus setzt.
ThomasW schrieb: > Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5 > Zeichen: :%s/^\.//g Wenn ich das richtig sehe sind das ja regular Expressions, was aber nun kein Alleinstellungsmekrmal des vi/vim ist. Diese (regular Expressions) nutzen einem aber auch nur dann etwas wenn man die im Kopf hat. Dazu kommen noch die unzähligen Befehle des Editors die man sich merken muß. Wenn man das alles nicht Kopf hat und erst nachschlagen muß, dann ist man mit dem nano oder jedem beliebigen graphischen Editor wahrscheinlich schneller, selbt dann wenn man zwei Tasten mehr drücken oder die Maus bemühen muß. Zudem kommt es bei mir eher selten vor das ich in einem Text hunderte Zeichen an gleicher Position entfernen/ersetzen muß.
(prx) A. K. schrieb: > Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch > viel RAM waren, ist schon lange vorbei. Dafür wird hier aber rum gemosert das der nano ja so viel Speicher braucht, wohingegen der vi ja so sparsam ist. Dafür braucht der vi halt jede Menge biologischen ROM und da sind wir dann schon beim Rick: Rick schrieb: > Die Benutzung von vi(m) ist eine Philosophie, eine Lebenseinstellung, > ein Lebensinhalt, absolute Hingabe, ein Selbstzweck um Probleme zu lösen > die man sonst nicht hätte, eine Herausforderung. > Vielleicht etwa vergleichbar mit einem Leistungssport. Besser kann man es nicht auf den Punkt bringen.
Zeno schrieb: > Dafür wird hier aber rum gemosert das der nano ja so viel Speicher > braucht, wohingegen der vi ja so sparsam ist. Du solltest dich aber schon ’n bisschen am tatsächlichen Verlauf orientieren, um dich nicht völlig unglaubwürdig zu machen: es wurde zunächst „rumgemosert“, dass vim ja soviel Speicher brauchen würde und daher Bloatware sei, wohingegen nano ja so sparsam wäre.
(prx) A. K. schrieb: > Nano schrieb: >> Als Editor war mir Emacs zu groß > > Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch > viel RAM waren, ist schon lange vorbei. Wobei der vim auch schon ordentlich zu gelegt hat. Sieh dir mal die neuste Version an.
Jack V. schrieb: > Du solltest dich aber schon ’n Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt. Jack V. schrieb: > um dich nicht völlig unglaubwürdig zu machen Wenn Du meinst - Deine Meinung ist mir da so ziemlich Rille. Viel peinlicher hier ist, wie einige ihr Lieblingsspielzeug verteidigen. Das hat ja schon religiöse Züge.
Zeno schrieb: > Viel peinlicher hier ist, wie einige ihr Lieblingsspielzeug verteidigen. > Das hat ja schon religiöse Züge. Ist in der Tat schon erschreckend, wenn jemand den Nano so anbetet, dass er sich selbst danach benennt, und schon bei der kleinsten Andeutung, dass ein Job in einem anderen Programm vielleicht einfacher und effizienter erledigt werden könnte, so durchdreht. Zeno schrieb: > Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt. Natürlich nicht – ich nehm’ dich sowieso nicht mehr ernst, selbst, wenn du jetzt anfangen würdest, dich an der Realität zu orientieren. Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung deiner anderen Beiträge sein kann.
:
Bearbeitet durch User
sepp schrieb: > Jack V. schrieb: >> Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen? >> Wieviel Zeit? > > Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das > macht. Um ein Problem zu lösen, das einmal im Leben vorkommt. Eigentlich nicht viel, denn es sind selbstverständlich nicht 500 komplett von einander losgelöste Kommandos, sondern diese sind logisch aufgebaut, so dass man sich, wenn man das Prinzip mal kennt, leicht komplexere Kommandos aus einfacheren zusammenstellen kann. Ab einem gewissen Grad erschließen sich sehr viele Kommandos von selbst. ThomasW schrieb: > Jack V. schrieb: >> Ich mach mal ein Neues: angehängt findest du eine Textdatei, bei der >> jede Zeile mit einem . beginnt, der in jeder Zeile entfernt werden soll. >> Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei in einer >> Kombination und eine Buchstabentaste, und bin entsprechend in weniger >> als einer Sekunde durch. > > Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5 > Zeichen: :%s/^\.//g > > Freue mich auf deine Lösung! Da es ja eigentlich nur darum geht, das erste Zeichen jeder Zeile zu entfernen, würde ich das so machen: Ctrl+v, dann Shift+g, dann d. Wenn man Ctrl und Shift mit einrechnet, sind das 5 Tastendrücke. Zeno schrieb: > Wenn man das alles nicht Kopf hat und erst nachschlagen muß, dann ist > man mit dem nano oder jedem beliebigen graphischen Editor wahrscheinlich > schneller, selbt dann wenn man zwei Tasten mehr drücken oder die Maus > bemühen muß. Man kann natürlich auch mit vim arbeiten, ohne sämtliche Kommandos im Kopf zu haben. Dann braucht man eben an manchen Stellen auch mehr Tastendrücke. > Zudem kommt es bei mir eher selten vor das ich in einem Text hunderte > Zeichen an gleicher Position entfernen/ersetzen muß. Der Punkt ist eben, dass man, wenn man sich mit vim auskennt, auch schnell ein Kommando findet, mit dem man recht einfach eine Bearbeitung machen kann, die vielleicht nicht so oft vorkommt, aber bei anderen Editoren schnell umständlich werden kann. Das hier ist vielleicht ein recht spezieller Fall, aber mir laufen des öfteren mal spezielle Fälle unterschiedlichster Art über den Weg.
Rolf M. schrieb: > Da es ja eigentlich nur darum geht, das erste Zeichen jeder Zeile zu > entfernen, würde ich das so machen: Ctrl+v, dann Shift+g, dann d. Wenn > man Ctrl und Shift mit einrechnet, sind das 5 Tastendrücke. Diese Lösung ist cool! Kam weiter oben schon und ich merke, dass ich den visualmode zu wenig nutze. Dafür ganz automatisch was ich schon beim sed so oft genutzt habe ;-)
Ich finde es spannend, dass in den letzten wenigen Jahren immer mehr deutschsprachige Videos auf Youtube zu vim aufgetaucht sind. Es scheinen also auch wieder mehr junge Leute Gefallen an vim zu finden. Hat wahrscheinlich auch etwas mit Nostalgie und Coolnessfaktor zu tun. Wenn man Interesse an solchen Sachen hat und jeden Tag mehrere Stunden einen Editor braucht, kann die Einarbeitung in vim sicher lohnend sein und auch Spaß machen. Für Gelegenheitsnutzer ist es aber eher nichts. Die haben die kryptischen Befehle dann schneller wieder vergessen als sie sie gelernt haben.
Zeno schrieb: > Nano schrieb: >> Nichts leichter als das, du gehst an den Anfang der Zeile und drückst >> >> STRG + K >> Cursor runter > Wozu mit dem Cursor an den Zeilenanfang? Es reicht wenn der Cursor in > der gewünschten Zeile steht. Nach dem Ausschneiden hüpft er dann > automatisch auf den Zeilenanfang. Oh, ja, da hast du natürlich recht. Bei dem anderen Beispiel kann man bei der zweiten Zeile mit
1 | " eingeben + Enter drücken |
kann man das " sogar weglassen, da es bereits als Vorschlag in der Klammer steht. Somit verkürzt sich das auf:
1 | Cursor in Zeile platzieren. |
2 | ALT + G |
3 | STRG + T |
4 | " eingeben + Enter drücken |
5 | 1 cursor nach rechts |
6 | ALT + A = Markierung gesetzt |
7 | ALT + G |
8 | STRG + T |
9 | Enter drücken |
10 | STRG + K |
Jack V. schrieb: > Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen? > Wieviel Zeit? So ein weltfremdes Beispiel kommt in der Realität bei mir nicht vor. Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell mit awk. Wenn es nur ein paar Zeilen sind, kann es auch sein, dass ich Kate öffne und einfach die Blockauswahl dafür nutze. Die erlaubt spaltenweises auswählen, also anders als das klassische Markieren.
Jack V. schrieb: > Gerade wenn man an Configs > rumschraubt, ist das ziemlich oft überaus praktisch und zeitsparend – > gerade deswegen habe ich es mir ja mal angeeignet, und ich hab die fünf > Minuten seither hundertfach wieder reingeholt – falls du darauf > hinauswolltest. Also wenn es dir nur um das Entfernen von Kommentarzeichen geht, nano bietet das Entfernen oder Setzen von Kommentarzeichen mit der Taste ALT + 3 an. Wenn man die Zeilen vorher markiert, gehen auch mehrere Zeilen auf einmal. Das gesetzte Kommentarzeichen wird hierbei abhängig vom Dateityp gesetzt. Default ist #, bei bspw. C >= C99 und C++ Code werden stattdessen // gesetzt.
(prx) A. K. schrieb: > Nano schrieb: >> Als Editor war mir Emacs zu groß > > Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch > viel RAM waren, ist schon lange vorbei. Das mag sein, aber gerade wenn ich nur kleine Configdateien bearbeiten will oder mal von der Bash aus kurz eine Notiz in eine TXT Datei schreiben will, dann nehme ich dafür einen Editor der schnell geöffnet und geladen ist und den man dann auch, weil er so schnell wieder da ist, ohne Planungsängste, dass er zum Öffnen wieder Zeit kostet, auch gleich wieder schließen kann. Diese Aufgaben erfüllt nano, aber auch Notepad, gedit oder kate. Bei den letzten beiden sollten die dafür notwendigen Bibliotheken, also GTK oder QT dann allerdings schon im RAM geladen sein. Und das ist dann wiederum ein Grund, warum ich den auf Desktopebene eingesetzten Editor dann abhängig davon mache, welches Desktop Environment ich gerade nutze. Bei KDE (qt basiert) ist es somit, wenn es nicht nano von der shell aus ist, immer Kate (auch qt) und bei Mate (gtk basiert) ist es pluma (gedit, gtk basiert). Unter Windows führt das dann sogar dazu, dass ich dort Notepad++ anstatt bspw. Geany (wäre GTK basiert) bevorzuge. Denn Notepad++ nutzt direkt die WinAPI und ist damit auch sehr schnell geladen. Geany müsste erst einmal die GTK Lib Laden, das dauert mir zu lange. Gut, heute in Zeiten von SSDs ist das nicht mehr so deutlich zu spüren, aber früher, bei Festplatten war das ein sehr wichtiger Punkt. Das nutzen verschiedener Editoren ist hier auch kein Problem, da alle diese Editoren sich von selbst erschließen, da sie ja intuitiv sind. Nano habe ich allerdings überall installiert, auch unter Windows. Und bei den heutigen Linux Distris, die ich nutze, ist nano ohnehin per default immer dabei. Und beim Programmieren wofür ich dann eine richtige IDE nehme, ist das sowieso anders, die IDE starte ich Morgens und schließe sie wieder Abends. Da sind mir die Ladezeiten relativ egal. Der "Blitz" Faktor eines Editors ist mir also wichtig.
Nano schrieb: > So ein weltfremdes Beispiel kommt in der Realität bei mir nicht vor. Ja, das Beispiel ist konstruiert – aber nicht, weil sowas in der Art in der Realität nicht vorkäme, sondern um es einfach und nachvollziehbar zu halten. Schreib doch einfach, dass die Aufgabe mit Nano nicht sinnvoll zu lösen ist, statt Gründe zu suchen, warum man das ja überhaupt nicht brauchen würde. Ist halt nicht sein Gebiet, damit ist nichts verkehrt. Ist nur schade, dass du nicht benennen möchtest, welches Problem du eigentlich mit Vim hast. Die oben geäußerte Vermutung mit dem Trauma war natürlich nicht ernst gemeint – aber irgendwas muss diesem irrationalen Zwang ja zugrunde liegen, aus dem du so krampfhaft zu zeigen versuchst, dass Nano mindestens genauso leistungsfähig wäre und dabei selbst solche offensichtlichen Absurditäten bringst, wie die Behauptung, deine Strg-Orgie in Nano wäre mindestens genauso effizient, wie die drei Tastendrücke im Vim, oder dass man statt fünf Tastendrücken doch einfach ’nen fully bloated Qt-Editor hochreißen und mit der Maus rumstochern sollte. Nano schrieb: > Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell > mit awk. Und bevor ich für so einen trivialen Job den Editor verlasse, den Awk-Aufruf zusammenschreibe und auf die Datei loslasse, um sie dann wieder im Editor zu öffnen und weiterzumachen, drücke ich halt meine fünf Tasten im Editor. So what?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.