Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die ultimativen Vorzuege dieses Editors? Wenn nein, warum nicht?
Weniger "vi" als "vim", für einfache Fälle. Grund: Es gibt ihn seit zig Jahren auf jedem "*x" System. Grund anfangs: Weil er mit jeder Tastatur funktioniert.
:
Bearbeitet durch User
Wenn ich mal irgendwo schnell paar Zeilen ändern muss, dann auch "vi" (wobei es mir dann ziemlich egal ist, was für eine Implementierung sich hinter diesen beiden Buchstaben verbirgt). Grund: der gleiche wie bei A.K.: überall (auf Unixen) vorhanden.
VIM hat Features die andere Editoren nicht haben, z.B. CTRL-X CTRL-F direkt im Editor nach Dateinamen suchen.
Openbsd schrieb: > Wenn nein, warum nicht? weil beim Vim :set nocompatible in der .vimrc an der ersten Stelle steht. Und neovim sowas als default selbst setzt.
A. K. schrieb: > Grund: Es gibt ihn seit zig > Jahren auf jedem "*x" System. Und mit OpenWatcom Vi auch für DOS in einer funktionierenden OSS Version.
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? > > > Wenn nein, warum nicht? Weil ich mir die Shortcuts nie merken kann (und Nano besser ist).
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Weil ich den gleichen Editor auf AIX, Solaris, BSD und Linux vorfinde und nicht lange ueber Tastenkombinationen nachdenken muss. Allerdings trifft das auch auf Emacs zu.
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? > > > Wenn nein, warum nicht? vi beherrsche ich zwar, bin dabei aber nicht sicher. nano ist einfacher und deshalb nutze ich diesen, wenn ich einen Editor im shell-Fenster brauche. Ansonsten nutze ich unter Linux gedit oder nedit.
olibert schrieb: > Allerdings trifft das auch auf Emacs zu. Nicht, wenn das erste Unix ein Microport Unix für 286 war. EMACS = eight megabytes and constantly swapping. Allerdings verwende ich üblicherweise tatsächlich den Emacs, customized. Aber ich hau den nicht jedesmal drauf, wenn ich bloss einen Editor für Configfiles brauche.
:
Bearbeitet durch User
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Inzwischen mehr neovim Warum? Na weil notepad++ für PowerUser gemacht wurde - und Nano für VHS Dozenten und BWLer
zitter_ned_aso schrieb: > User schrieb: >> z.B. CTRL-X CTRL-F >> direkt im Editor nach Dateinamen suchen. > > na klar ;-) In einer z.B. kde-edelkonsole mglw. schon ;) sonst halt wie üblich vlt. via Shellbefehl :!find ... :!locate ... Ergebnis gleich einlesen :read :r bzw. :r!xy :r!xy dann steht das Ergebnis der Aktion im Buffer oder man schickt das in den Hintergrund mit Ctrl-Z und macht was anderes. Solange es noch Leute gibt denen systemd am init vorbeigeht wird der gebraucht ;)
Seit emacs ist vi obsolet! Das kann man überall im Usenet nachlesen! Ernsthaft: das erste, was ich bei Systemen mache, die den vi mitbringen: ich ersetze ihn durch den Vim und erstelle einen Symlink namens vi. Insofern muss ich im Sinne des Eingangsposts sagen: nein, ich arbeite nicht mehr mit dem vi.
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Ja! >Wenn ja, warum? Falsche Frage! Die Frage ist "Wann arbeitet man mit dem vi?" dann erübrigt sichFrage: > Was sind die > ultimativen Vorzuege dieses Editors? Ich benutzt den vi wenn ich remote bspw überne ssh arbeite. Also zur Bearbeitung von Konfigurationsdateien, logs durschauen auf einem Headless system oder sourcen auf einem built-Server beacker. vi braucht halt wenig Bandbreite im Vergleich zu den Pixel-Gui-Editoren und es gibt ihn für quasi jedes system, nicht nur für Windows/DOS Tipp-Prothesen. Manche schätzen, das man den vi komplett ohne Mouse nutzen kann. Das reisst den geschickten Tipper nicht aus dem Flow. Und man kann den vi auch zur IDE pushen mit multiple windows, diff und compile from editor: https://www.youtube.com/watch?v=YhqsjUUHj6g
Openbsd schrieb: > Was sind die > ultimativen Vorzuege dieses Editors? 1. Recht vielseitig und kann man in der Konsole benutzen (toll z.B. für Windows (kommt u.a. mit Watcom-Compiler Installation)). 2. Ziemlich gut standardisiert - bzw. muss man normalerweise nicht erst groß nachinstallieren oder nach Alternativen suchen. 3. Sehr schnell für Powerhacker wie Spieleprogrammierer z.B. 4. kleine Challenge (hatte mal an der Uni angefangen: wie kommt man aus diesem Editor heraus??) 5. Nettes recht verfängliches Tutorial für Vim auf Linuxen - kommt normalerweise per Eingabe: vimtutor de 6. Macht auch irgendwie Spaß, wenn man merkt, dass es besser wird 7. Nette Kaffee-Tasse (Vi Bild von ct): https://www.heise.de/ct/ftp/08/16/184/
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? * Weil er auf jedem *NIX on board ist. * Weil es ihn auch für alle anderen OS gibt. * Weil er überall (annähernd) gleich funktioniert. (Und das schon seit >30j) * Weil man mit ihm sehr schnell und effizient arbeiten kann. (Finger können auf der Tastatur bleiben) Allerdings (zumindest meiner Erfahrung nach) Voraussetzung: * US Keyboardlayout Was zur Situation führt dass man, wenn man zwischen Textverarbeitung, Email, ... und Programmierarbeiten wechselt, immer das Keyboardlayout wechseln muss. (Was ja seit Win7 auch auf Windows sehr einfach geht.) Und natürlich, dass man sich angewöhnt beim Tippen nicht mehr auf die Tasten zu schauen ;) BTW: Weiß zufällig jemand wie man unter Windows ein bestimmtes Keyboardlayout an eines oder mehrere Fenster binden kann?
Andi schrieb: > (Und das schon seit >30j) Den gibts seit 43 Jahren und er stammt von einem Gründer von Sun Microsystems.
Andi schrieb: > Allerdings (zumindest meiner Erfahrung nach) Voraussetzung: > * US Keyboardlayout Die Zeichen sind immer die gleichen, nur die Position auf der Tastatur nicht. Hängt also davon ab, ob man sich die Position merkt, oder das Zeichen.
Angehängte Dateien:
-
vi_cup.jpg
69 KB
*Weil vi lokal nützlich beim Kaffeetrinken ist. Die Tastatur sollte trocken bleiben. Sonst ändert sich das Layout!
A. K. schrieb: >> * US Keyboardlayout > > Die Zeichen sind immer die gleichen, nur die Position auf der Tastatur > nicht. Hängt also davon ab, ob man sich die Position merkt, oder das > Zeichen. Das ist natürlich richtig. Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach effizienter zu erreichen. Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit deutschem Layout programmieren kann. Man merkt eben dass ich aus einer Zeit stamme, wo man anfangs nur US-Tastaturen an Terminals kannte ;) Wie lästig war das damals als die ersten VT100-Terminals mit Deutscher Tastatur auftauchten... ;)
Andi schrieb: > Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach > effizienter zu erreichen. Auch, wenn’s OT ist: mit Neo2 ist’s noch viel effizienter erreichbar, gar nicht zu reden von {} und [] und so Sachen. Damit funktioniert zwar wieder die hjkl-Navigation nicht gescheit, im Gegenzug hat’s aber auch direkt aus der Grundstellung heraus erreichbare Cursortasten auf der vierten Ebene, so dass man die vi-Navigation auch nicht braucht. Zumindest im Vim nicht, vi in der Urversion kann ja mit den Cursortasten nicht so richtig.
Andi schrieb: > Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit > deutschem Layout programmieren kann. Ich auch nicht. In frühen Jahren - das war vor der PC Dominanz - verwendeten ein Freund und ich an einem 68000 Eigenbau-Rechner mit Eigenbau-OS eine Async-Tastatur mit Eigenbau-Layout auf US Grundlage. Damals konnte man Tastaturen vergleichsweise günstig kundenspezifisch angepasst kaufen. Und den AIM65 davor gab es sowieso nur in US-ASCII. Auf eine 16-Segment LED kriegst du keine Umlaute drauf. Irgendwann setzte sich dann aber doch der PC durch, es wurde Deutsch und der Zeichencode normiert. Ich habe mich aber nie an ß gewöhnen können und verwende weiterhin ziemlich konsequent ss. Ausser dort, wo so Grammar-Nazis wie Autokorrektoren partout auf ß bestehen.
:
Bearbeitet durch User
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). Damit kann zwar sonst niemand schreiben außer mir :), aber ich habe auf diese Weise beide Welten. Unter MS-DOS brauchte es dafür noch so'n doofes TSR-Programm, seit Unix geht das einfacher und direkt im OS / X11.
Openbsd schrieb: > Vi Editor ausgestorben? Vi hat außerhalb kommerzieller Unix-Systeme kaum Verbreitung erlangt, da sein Quellcode erst seit 2002 frei (sowohl wie Beer als auch wie Freedom) verfügbar ist und es zu diesem Zeitpunkt schon jede Menge leistungsfähigere (und teilweise zu Vi abwärtskompatible) Editoren gab. Ausgestorben ist er deswegen aber noch nicht, den Quellcode gibt es hier https://github.com/n-t-roff/heirloom-ex-vi und seine Söhne (Vim, Elvis, Nvi usw.) erfreuen sich nach wie vor großer Beliebtheit. > Arbeitet von euch noch jemand mit dem vi? Mit Vi nicht, aber mit seinen Nachfolgern. > Wenn ja, warum? Jedenfalls nicht, weil es beim ersten Kontakt sofort gefunkt und so etwas wie Liebe auf den ersten Blick stattgefunden hätte :) Sondern deswegen: Ich verwendete Vi erstmals auf einer Sun-Workstation. Das geschah aber eher aus der Not heraus, weil auf diesem Rechner sonst kein tauglicher Editor installiert war. Privat verwendete ich auf dem Amiga den mit dem Aztec-C-Compiler von Manx mitgelieferten Vi-Klon Z, der für damalige Verhältnisse recht leistungsfähig war und sogar Ctags unterstützte. Auch hier gab es für mich kaum Alternativen. Emacs konnte zwar noch mehr, war aber auf den 16-Bit-Homecomputern wie dem Amiga oder Atari ST wegen des zu großen RAM-Bedarfs nicht lauffähig (diese Rechner hatten weder Eight Megabytes noch Swap-Space ;-)). Für kleine Computer gab es nur den µEmacs, der aber so stark abgespeckt war, dass ich lieber beim Z blieb. Nachdem ich mich an die Bedienung von Vi und Z gewöhnt hatte und es Vi-Klone für praktisch jede Plattform gibt, auf der ein Editor überhaupt Sinn macht, war es naheliegend, weiterhin auf dieser Schiene zu fahren. Etwas anderes benutze ich nur noch in Ausnahmefällen. Wenn ich die Wahl habe, nehme ich den Vim, der der mächtigste Vi-Sohn sein dürfte. Da er (ggf. mit Plug-Ins) alles kann, was ich von einem guten Editor erwarte, schaue ich mich nur noch sehr sporadisch nach Alternativen um. Diese gibt es zwar mittlerweile durchaus, sie sind aber für meine Bedürfnisse maximal ebenbürtig zum Vim, weswegen ein Umstieg mit dem damit verbundenen Einarbeitungsaufwand verschwendete Zeit wäre. Sogar die Busybox, die oft auf schmalbrüstigen Embedded-Systemen eingesetzt wird, enthält neben Ed einen (abgespeckten) Vi. Kurz: Mit Vi & Co. ist man einfach überall zu Hause :)
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? In meinem Admin-Team arbeiten vier von fünf Leuten mit dem vim und einer (moi) mit dem GNU Emacs. Sie können alles, was man von einer modernen IDE oder Editor erwartet, Syntaxhighlighting natürlich sowieso, aber auch Autocompletion, Codenavigation, Refactoring... und für uns ist einer der wesentlichen Vorzüge, daß man sie auch auf der Kommandozeile über dünne Netzwerkverbindungen nutzen kann. Und hie und da nutze auch ich den vi(m), einfach weil er auf jedem UNIXoiden System verfügbar ist und ich nicht überall einen Emacs installieren darf, kann oder will. > Wenn nein, warum nicht? Naja, einem Einsteiger würde ich eher Atom, Sublime, Visual Studio Code, UltraEdit, Kate, gedit oder einen anderen moderneren Editor empfehlen -- einfach, weil sie die auch unter anderen Programmen üblichen Shortcuts und Menüführungen verwenden, und dadurch die Lernkurve häufig flacher ist. Aber sonst, why not? Ist halt noch ein Stück altes UNIX-Feeling... ;-)
Ich arbeite taeglich damit. Wie schon einige geschrieben haben, es ist auf allen unixoiden Systemen vorhanden und mit Linux, BSD, Solaris, AIX habe ich taeglich zu tun. Privat nutze ich allerdings auch vim.
> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit > deutschem Layout programmieren kann. Ich auch nicht. Deshalb habe ich auch immer noch meine englische IBM-Tastatur aus den 80ern. Ich wuesste auch keinen Grund wieso ich daran etwas aendern sollte. Aber es spricht natuerlich auch nichts dagegen deutsche Tastaturen einfach auf englisch umzuschalten. Man muss ja beim schreiben nicht auf die Tasten schauen. .-) Olaf
Ich benutze auch keinen vi, aber vim sehr häufig, sowohl lokal als auch remote per ssh - zuhause und am Arbeitsplatz. Manche Kollegen nutzen von Zeit zu Zeit vi, wenn sie was auf der Kommandozeile editieren müssen. Allerdings nur, weil sie nicht wissen, dass es durchaus signifikante Unterschiede zu vim gibt. Auf meinem Android-Handy habe ich mir die App "VimTouch" installiert. Da ich dort aber eigentlich nie einen Texteditor brauche, nutze ich die gar nicht. Außerdem ist es per Touchscreen vermutlich nicht sehr bequem zu bedienen. ;-) Jörg W. schrieb: > Wenn ich mal irgendwo schnell paar Zeilen ändern muss, dann auch "vi" > (wobei es mir dann ziemlich egal ist, was für eine Implementierung sich > hinter diesen beiden Buchstaben verbirgt). Naja, vim ist schon deutlich besser als vi. Letzterer kann z.B. beim undo nur eine Stufe und kann im Edit-Mode nicht per Cursor-Tasten navigieren. Alleine das sollte schon als Grund reichen, eher vim zu verwenden. Sheeva P. schrieb: > Naja, einem Einsteiger würde ich eher Atom, Sublime, Visual Studio Code, > UltraEdit, Kate, gedit oder einen anderen moderneren Editor empfehlen -- > einfach, weil sie die auch unter anderen Programmen üblichen Shortcuts > und Menüführungen verwenden, und dadurch die Lernkurve häufig flacher > ist. Aber sonst, why not? Ist halt noch ein Stück altes UNIX-Feeling... > ;-) Es gibt auch noch gvim. Da hat man dann auch Menüs und Toolbars und so Zeug. Und da steht bei den Menüeinträgen auch wie von anderen GUI-Programmen gewohnt die Tastenkombinationen dahinter. Das kann beim Einstieg helfen.
:
Bearbeitet durch User
Ich benutze alle paar Tage vi oder vim (sind anscheinend per symlink verbunden so dass ich über Unterschiede nichts weiß). Weil das per ssh auch auf embedded boards ohne Display und Tastatur sofort verwendbar ist und wie andere auch schon schrieben überall gleich ist. Ob man nun den ab-und-zu-Gebrauch als "arbeiten" bezeichnen kann? Als Code-Editor nehme ich etwas anderes. Im Prinzip ist das so wie ich immer noch den winzigen Schraubendreher aus meiner Jugendzeit auf der Werkbank liegen habe und den genau dann verwende, wenn ich ihn brauche. Jedes Werkzeug hat nun mal seinen Einsatzbereich, egal wie alt es ist. Schlußfolgerung: ein Werkzeug wird nicht schlecht wenn es alt ist, sondern wenn es abgenutzt oder kaputt ist.
:
Bearbeitet durch User
Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vi? Ich nicht. > Wenn nein, warum nicht? Weil ich - nicht täglich Unixoide Systeme administriere - nicht aus einer Zeit stamme wo es keine/kaum Alternativen gab bzw. die Verwendung eines physischen Terminals zum Remote-Login an einem Großrechner Standard war - ich für mich trotz mehrmaligem Ausprobieren keinen Vorteil gegenüber der relativ hohen Einarbeitungszeit sehe Für große Projekte verwende ich plattformübergreifend Eclipse (true story), für kleineres Zeugs KDevelop oder Kate, unter Windows Notepad++ oder was auch immer die jeweilige Distri grad so installiert hat. Für die wenigen Fälle wo ich remote auf einem Board oder auf einem System ohne x11 mal ne Zeile in einer Config-Datei ändern muss reicht der nano.
:
Bearbeitet durch User
Andi schrieb: > Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit > deutschem Layout programmieren kann. Deshalb hatte damals auch Pascal hierzulande eine viel stärkere Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout einfach viel angenehmer von der Hand als C.
Bernd K. schrieb: > Deshalb hatte damals auch Pascal hierzulande eine viel stärkere > Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout > einfach viel angenehmer von der Hand als C. Wobei man beim Programmieren auch ab und zu mal denken sollte, nicht nur tippen. ;-)
Mir passiert es gelegentlich, dass ich schnell einen Text oder Quellcode im Editor meiner Wahl, z.b. UEStudio oder joe, verfasse und der Compiler sich anschließend über die Zeichenfolge :wq beschwert.
Bernd K. schrieb: > Deshalb hatte damals auch Pascal hierzulande eine viel stärkere > Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout > einfach viel angenehmer von der Hand als C. Aber nur, wenn man die Kommentare mit
1 | (* *) |
schreibt, sonst hat man ja das gleiche Problem. Pascal habe ich aber ohnehin vorrangig zu Zeiten benutzt, da ich sowieso noch eine englische Tastatur hatte. Rolf M. schrieb: > Alleine das sollte schon als Grund reichen, eher vim zu verwenden. Nö, wenn ich das alles brauche, habe ich auch einen Emacs in Reichweite. :-) Den [n]vi[m] nehme ich vor allem dann, wenn es keinen Emacs gibt oder der Job wirklich so klein ist, dass es auf irgendwelche besonderen Features nicht ankommt. Habe Anfang der 1990er in einem Laden gearbeitet, wo alles mit Unix gemacht wurde (DG/UX, kennt heute keiner mehr). Meine Kollegen benutzten alle fleißig den vi (noch den "richtigen"), und ärgerten sich oft genug mehr oder weniger damit 'rum. Ich bin damals ziemlich schnell beim Emacs gelandet, war aber von den Kollegen wohl trotzdem noch derjenige, der am Ende die meisten vi-Kommandos kannte. ;-)
:
Bearbeitet durch Moderator
Linux/Unix Admin hier, ich benutzte vim jeden Tag als mein Hauptwerkzeug weil er - überall installiert ist - klein und schnell ist - im Terminal bzw. in SSH Sessions Funktionen liefert die üblicherweise GUI Editoren vorbehalten sind. In letzter Zeit kommt immer mal wieder EMACS dazu, weil ich den org-mode für mich entdeckt habe.
Jörg W. schrieb: > Bernd K. schrieb: >> Deshalb hatte damals auch Pascal hierzulande eine viel stärkere >> Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout >> einfach viel angenehmer von der Hand als C. > > Aber nur, wenn man die Kommentare mit > > ( ) > > schreibt, ... und wenn man Array-Indizes mit (. und .) klammert, also bspw. so:
1 | a(.x.) := b(.x.) |
Digraphen gibt es aber auch in C: <% und %> für die geschweiften, <: und :> für die eckigen Klammern und %: für das #-Zeichen. Bei mir ist mittlerweile das vordere Daumengelenk der rechten Hand in einem 90°-Winkel fest verwachsen, so dass ich mit Daumen und Zeigefinger problemlos die AltGr-Kombinationen für die geschweiften und eckigen Klammern erreiche. Da brauche ich weder Digraphen noch eine englische Tastaturbelegung ;-) JJ schrieb: > In letzter Zeit kommt immer mal wieder EMACS dazu, weil ich den org-mode > für mich entdeckt habe. Gibt es in ähnlicher Form auch für Vim: https://github.com/jceb/vim-orgmode Hab's aber noch nicht ausprobiert.
Yalu X. schrieb: > Gibt es in ähnlicher Form auch für Vim: > > https://github.com/jceb/vim-orgmode > > Hab's aber noch nicht ausprobiert. Ich schon, der hat leider viele Features die nicht implementiert sind [1] und wenn du PDF Exporte willst ruft vim-orgmode auch nur EMACS auf. Derzeit nutze ich spacemacs, das ist ein best-of-both-worlds EMACS-Customizing. [1] https://github.com/jceb/vim-orgmode/blob/master/doc/orgguide.txt
Wenn man sich mal verinnerlicht hat, dass der vi/vim ein Mode-basierter Editor ist dies beim Arbeiten immer im Hinterkopf hat und sich immer darüber klar ist, welchen Mode man gerade benutzt und auch noch weiss, wie man sich zwischen den wichtigsten Modi bewegt... wird der vi/vim nicht nur sehr logisch erscheinen sondern man lernt ihn schätzen. Am Anfang gehört etwas Überwindung dazu, die Finger von der Maus zu lassen (auch wenn die im vim natürlich längst unterstützt wird und sich gerade im visual-mode anbietet ) und was noch viel wichtiger ist -und was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten zu lassen ( am besten die Pfeiltasten remappen ). Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu den Pfeiltasten zucken;-)
Walter K. schrieb: > und was noch viel wichtiger ist -und > was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten > zu lassen ( am besten die Pfeiltasten remappen ). > Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu > den Pfeiltasten zucken;-) Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV. Diese Tastenbelegung stammt noch aus einer Zeit als man noch elektrische Schreibmaschinentastaturen in Terminals eingebaut hat. Überall sonst auf der Welt wird mit den Pfeiltasten, Pagetasten, Home und End navigiert, mit shift markiert und mit shift-del, shift-ins cut & paste. Das sitzt vielen (mir auch) so tief im Muskelgedächtnis daß es schwer fällt sich da nur für vim umzugewöhnen. Deshalb benutz ich den vim auch nur wenn ich mal per ssh irgendwo in ner remote shell bin um 3 Zeilen in ner Konfig-Datei zu bearbeiten, auf dem Desktop und zum längeren Arbeiten dann doch lieber vscode.
Bernd K. schrieb: > Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV. Ist er nicht, denn die Pfeiltasten funktionieren ja grundsätzlich. Man muss ja nicht unbedingt solche Ratschläge aus dem letzten Jahrtausend so bierernst nehmen. Auch ein Emacs hat aus historischen Gründen seine eigenen Kommandos zur Navigation (C-P, C-N), aber ich kann mich nicht dran erinnern, wann ich die das letzte Mal benutzt hätte. Jeder normale Mensch nimmt die Cursortasten.
Jörg W. schrieb: > Jeder normale Mensch nimmt die Cursortasten. Einspruch. Es ist erheblich bequemer, den Cursor bewegen zu können, ohne die Hände aus der Grundstellung nehmen zu müssen. Natürlich nur für die, die ihre Hände normalerweise in der Grundstellung haben – dann ist’s allerdings deutlich spürbar. Die, welche üblicherweise sowieso mit’m Zeigefinger in geringer Höhe Suchkreise über den Tasten ziehen, werden vermutlich keinen Nachteil darin sehen, die Hand zu den Cursortasten bewegen zu müssen.
Sorry: Quark. Ich tippe seit Jahrzehnten mit 10 Fingern (habe ich schon vorm Computerzeitalter mit der Schreibmaschine gemacht, wo es wirklich Überwindung kostete, mit dem kleinen Finger den Wagen anzuheben). Wenn ich den Text schreibe, habe ich die Finger auf der Haupttastatur liegen – aber dann muss ich nicht groß navigieren (höchstens mal mit der Löschtaste). Wenn ich im Text hin und her navigiere, dann brauch ich nicht die 10 Finger auf der Tastatur, denn in erster Linie suche ich da irgendwas.
Jörg W. schrieb: > Sorry: Quark. Halten wir fest: es gibt verschiedene Ansichten. Zumindest ein Zehnfingerschreiber stört sich daran, zum Verschieben des Cursors die Hände übermäßig bewegen zu müssen, und das bin ich. Wahrscheinlich gibt es noch mehr – sonst hätten die Neolinge die Navigationstasten nicht auf die Grundlinie gelegt, und in der Vi-Doku würde hjkl nicht als Feature hervorgehoben. Insofern halte ich’s für etwas anmaßend, das mal eben pauschal als „Quark“ abzutun, nur, weil man’s selbst nicht so empfindet.
:
Bearbeitet durch User
Jack V. schrieb: > Insofern halte ich’s für etwas anmaßend, das mal eben pauschal als > „Quark“ abzutun. Der „Quark“ war insbesondere die Reaktion auf deinen zweiten Absatz oben – der implizit unterstellt, alle diejenigen, die Cursortasten benutzen, wären zu blöd zum 10-Finger-Schreiben. Hättest du dir den Absatz gespart, hätte ich gar nicht auf deine Äußerung reagiert, da es in der Tat einfach nur verschiedene Meinungen gibt.
Jörg W. schrieb: > Der „Quark“ war insbesondere die Reaktion auf deinen zweiten Absatz oben > – der implizit unterstellt, alle diejenigen, die Cursortasten benutzen, > wären zu blöd zum 10-Finger-Schreiben. Entschuldige, aber deine Interpretation war in diesem Fall falsch. Natürlich nutzen die meisten Zehnfingerschreiber die Pfeiltasten, weil eben die wenigsten Programme eine andere Steuerungsmöglichkeit vorsehen, und es käme mir nicht im Traum in den Sinn, sie deswegen als blöd hinzustellen. Im Vi und seinen Ablegern (um wieder auf das Thema zurückzukommen) gibt es aber eine Alternative auch für qwert-User, und wenn diese sich drauf einlassen, könnten sie durchaus ’nen Komfortgewinn erfahren. Die bringt nur keinerlei Vorteile für Nichtzehnfingerschreiber, darauf war meine Aussage bezogen.
:
Bearbeitet durch User
Die Verwendung von H, J, K und L als Cursor-Tasten gehen auf das ADM-3A-Terminal zurück, auf dem der Vi-Entwickler Bill Joy, damals gearbeitet hat und bei dem das (normalerweise in Kombination mit Ctrl) tatsächlich die Cursor-Tasten waren. http://xahlee.info/kbd/ADM-3A_terminal.html Auf diesem Terminal war auch die Escape-Taste leichter erreichbar, und für den Doppelpunkt (zum Umschalten in den Command-Mode) musste kein Shift gedrückt werden. Auch die Tilde als Symbol für das Home-Directory in Unix-Shells hat wohl dort seinen Ursprung. Nachdem ich das gelesen habe, habe ich natürlich sofort Escape auf die die Tabulator-, Ctrl auf die Caps-Lock-, Tab auf die linke Ctrl- und den Doppelpunkt auf die Akzent-Taste gelegt. Damit flutscht es mit dem Vim jetzt noch besser. Angenehm ist dabei vor allem, dass Escape nun auf einer großen Taste liegt und man den Arm dafür nicht so weit ausstrecken muss. Auf die freigewordene Esc-Taste könnte man passend zu ihrer Beschriftung das Shutdown-Kommando legen ;-)
Yalu X. schrieb: > Auf die freigewordene Esc-Taste könnte man passend zu ihrer Beschriftung > das Shutdown-Kommando legen Irgendeine englische Tastatur (ich glaube, von älteren Suns) hatte dort einfach nichts drauf stehen. Eignet sich gut für die berühmte „anykey“. ;-)
:
Bearbeitet durch Moderator
Nur wenn ich auf meinem Linux-Server (keine GUI) ein paar Zeilen in einem config-file o.ä. ändern muss.
Ich sehe gerade, dass das Tastaturlayout des Apple II dem des ADM-3A gar nicht unähnlich ist: https://i.pinimg.com/474x/e3/1b/53/e31b53767fad646fc635271d1192fe13--apple-ii-all-products.jpg Damit wäre der Apple die ideale Plattform für Vi gewesen. Leider kam der entsprechende Port (VI65) Jahrzehnte zu spät: http://vi65.sourceforge.net/
Yalu X. schrieb: > Nachdem ich das gelesen habe, habe ich natürlich sofort Escape auf die > die Tabulator-, Ctrl auf die Caps-Lock-, Tab auf die linke Ctrl- und den > Doppelpunkt auf die Akzent-Taste gelegt. Diese Aussage bestärkt mich in meiner Überzeugung daß es mindestens zwei fundamental unterschiedliche Typen von Menschen zu geben scheint: Einmal die deren versierter Umgang mit der Tastatur damit steht und fällt daß ihre Tasten auch morgen noch genau an der selben Stelle liegen an der sie gestern schon waren und dann gibt es anscheinend welche die sich mal eben schnell die halbe Tastatur bis zur Unkenntlichkeit ummappen und damit dann trotzdem noch zurechtkommen. Die Existenz letzterer Gruppe muss es sein die dafür verantwortlich ist daß sich vim so hartnäckig hält. Mitglieder der ersten Gruppe (Mehrheit) können das absolut nicht nachvollziehen, das ganze Gehirn scheint fundamental anders verschaltet zu sein um sowas zu ermöglichen.
:
Bearbeitet durch User
Bernd K. schrieb: > Die Existenz letzterer Gruppe > muss es sein die dafür verantwortlich ist daß sich vim so hartnäckig > hält. Das denke ich nicht. Tatsächlich habe ich in meinem Umkreis noch nie jemanden gehabt der seine Tastatur remappt. (Wenn man von der Umschaltung de-en absieht) Auch auf einer ganz normalen Belegung kann der vim seine Stärken ausspielen.
Bernd K. schrieb: > Yalu X. schrieb: >> Nachdem ich das gelesen habe, habe ich natürlich sofort Escape auf die >> die Tabulator-, Ctrl auf die Caps-Lock-, Tab auf die linke Ctrl- und den >> Doppelpunkt auf die Akzent-Taste gelegt. > > Diese Aussage bestärkt mich in meiner Überzeugung daß es mindestens zwei > fundamental unterschiedliche Typen von Menschen zu geben scheint: ... > ... das ganze Gehirn scheint fundamental anders verschaltet zu sein. Keine Angst, ich bin kein Alien. Die Änderung des Tastatur-Layouts habe ich längst wieder rückgängig gemacht. Es ging mir bei der ganzen Aktion nur darum, mich einmal in meinem Leben wie Bill Joy zu fühlen :)
Weils so schön zum Thema passt: https://www.golem.de/news/happy-hacking-keyboard-fujitsu-legt-einen-klassiker-aus-den-90er-jahren-neu-auf-2001-145908.html
Bernd K. schrieb: > Die Existenz letzterer Gruppe z.B. - C-Programmierung - Unixe/Linuxe, die kein Deutsch können - viele gute englischsprachige Rpgs - Erfahrung mit vielen verschiedenen Tastaturen/Layouts Dann gibt es aber auch noch so Sachen wie: Du kannst mit einer einzigen logischen Operation mit den SSE-Registern ganze Sätze in einem Rutsch von Groß auf Klein oder umgekehrt umstellen bzw. in dieser Richtung normieren. Sofern keine großen Sonderzeichen dabei.. Mit vielen Sonderzeichen geht es sequentiell besser. Aber: Einer der schnellsten Tipper, die ich sah, der brauchte nur 2 Finger. Layouts waren dem ziemlich egal. Wer 10 Finger schreiben kann, weiss, dass ueben ueben ueben hilft bzw. Uebung den Meister macht. Das gilt genauso für hjkl ;)
Bernd K. schrieb: > Diese Aussage bestärkt mich in meiner Überzeugung daß es mindestens zwei > fundamental unterschiedliche Typen von Menschen zu geben scheint: Einmal > die deren versierter Umgang mit der Tastatur damit steht und fällt daß > ihre Tasten auch morgen noch genau an der selben Stelle liegen an der > sie gestern schon waren und dann gibt es anscheinend welche die sich mal > eben schnell die halbe Tastatur bis zur Unkenntlichkeit ummappen und > damit dann trotzdem noch zurechtkommen. Was heißt "trotzdem"? Sie mappen sich das ja um, gerade damit sie besser damit zurecht kommen, weil es intuitiver ist (häufig verwendete Zeichen/Funktionen möglichst einfach erreichbar). Ich würde das vielleicht auch machen, aber was mich davon abhält ist, dass ich wahrscheinlich wahnsinnig werden würde, wenn ich an einem Rechner arbeite, wo ich dieses Mapping nicht benutzen kann. Also lieber doch so, dass es auf jedem Rechner ohne Umbauten geht. Ist schon schlimm genug, wenn ich unter Windows kein focus-follows-mouse habe. Jörg W. schrieb: > Irgendeine englische Tastatur (ich glaube, von älteren Suns) hatte dort > einfach nichts drauf stehen. Eignet sich gut für die berühmte > „anykey“. ;-) Es gibt "Das Keyboard" in einer Version, wo auf gar keiner Taste was aufgedruckt ist: https://www.daskeyboard.com/de/daskeyboard-4-ultimate/ Nur die Harten kommen in'n Garten. ;-) Nette Anekdote: Ein Kollege hat mal während ich im Urlaub war ein paar Tastenkappen auf meiner Tastatur vertauscht. Ich hab das anfangs gar nicht gemerkt und hab's dann einfach so gelassen, weil's mir egal war. Bis ein anderer Kollege an meinem Rechner was eintippen musste und daran fast verzweifelt ist, weil es immer falsch war. Da hab ich mich wieder an die vertauschten Tasten erinnert, und dann war's klar.
:
Bearbeitet durch User
Andi schrieb: > Tatsächlich habe ich in meinem Umkreis noch nie > jemanden gehabt der seine Tastatur remappt. Ich habe auf dem Netbook die rechte Shift-Taste zu PgDn gemacht. Eine der wichtigsten Funktionen, sonst nur umständlich über Fn+Down erreichbar. Am Desktop in der Firma habe ich die Tastenkappe von ShiftLock abgezogen. Eine der ärgerlichsten Tasten überhaupt.
:
Bearbeitet durch User
Nette Anekdote zum vim: Kommt ein Kollege (Windows Fraktion) mit einem USB Stick: Da drauf eine 8GB große XML mit einem kompletten Produktkatalog. Da drin sollten in Zeile 212556 ein paar Worte geändert werden. Alle Windows Editoren versagten kläglichst. Datei teilen, ändern, zusammenfügen wäre eine Option. Oder: vim brauchte 30s zum laden der Datei, 212556G Rblabla<esc> ZZ 30s warten, fertig. vim ist auch mit Binärdateien nicht zu erschrecken (wenn diese auch seltsam aussehen), man kann sie editieren. vi (und vor allem sein Erben vim etc.) ist eine Liebe auf den dritten Blick, die es aber Wert ist. LG. Hans
Hans Müller schrieb: > Da drin sollten in Zeile 212556 ein paar Worte geändert werden. Kenner verwenden dafür "sed". ;-)
A. K. schrieb: > Hans Müller schrieb: >> Da drin sollten in Zeile 212556 ein paar Worte geändert werden. > > Kenner verwenden dafür "sed". ;-) "ed is the UNIX text editor" :-)
A. K. schrieb: > Andi schrieb: >> Tatsächlich habe ich in meinem Umkreis noch nie >> jemanden gehabt der seine Tastatur remappt. > > Ich habe auf dem Netbook die rechte Shift-Taste zu PgDn gemacht. Eine > der wichtigsten Funktionen, sonst nur umständlich über Fn+Down > erreichbar. Ich habe mal auf einem Notebook Strg und Fn getauscht. Es gab dort eine Fn-Taste ganz links unten im Eck, neben Strg. Nun ist mein linker kleiner Finger gewöhnt, dass Strg die ganz äußere Taste ist und kam deshalb nicht damit klar. Offenbar war ich aber nicht der einzige mit dem Problem, denn es gab im BIOS-Setup des Rechners extra die Möglichkeit, die Funktionalität der beiden Tasten zu tauschen. Das würde außerhalb auch nicht gehen, da die Fn-Taste direkt vom Tastaturcontroller ausgewertet wird und das Betriebssystem sie gar nicht sieht. > Am Desktop in der Firma habe ich die Tastenkappe von ShiftLock > abgezogen. Eine der ärgerlichsten Tasten überhaupt. Müsste ja auch ein CapsLock sein, was es unter Linux auch ist.
:
Bearbeitet durch User
Rolf M. schrieb: > Müsste ja auch ein CapsLock sein, was es unter Linux auch ist. Wäre auch nicht besser, ich latsche da zu oft ungewollt drauf. Die Cap ist jedenfalls ab.
Rolf M. schrieb: > Offenbar war ich aber nicht der einzige mit dem Problem, denn es gab im > BIOS-Setup des Rechners extra die Möglichkeit, die Funktionalität der > beiden Tasten zu tauschen. Thinkpad, metoo. :) Die älteren Versionen haben die BIOS-Funktion noch nicht.
Hans Müller schrieb: > vi (und vor allem sein Erben vim etc.) ist eine Liebe auf den dritten > Blick, die es aber Wert ist. Nee, das ist mit Recht nicht mehr eines Blickes würdig. Du wie viele andere hier protzen mit vim o.ä. Die Wenigsten kennen doch den richtig alten vi nicht. Anfang der der 90' ziger hatte ich CAD Weiterbildung auf SUN- Workstations. Dazu auch Grundlagen in C und UNIX. Der Dozent sagte nach 3h Einweisung in VI, so nun habt ihr ihn kennengelernt, und vergesst sofort, dass es ihn gibt. Verwendet wurde da VIS(?), mit Copy u. Paste und Mausmarkierung. Man muß sich sowas nicht antun: Befehl xxxxx löscht im dritten Wort die letzten drei Zeichen rückwärts usw. Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur Brust nehmen. Ist der gleiche Müll. Findet man in LINUX eigentlich noch den Ur-VI? Unter KNOPPIX schon mal nicht.
michael_ schrieb: > Der Dozent sagte nach 3h Einweisung in VI, so nun habt ihr ihn > kennengelernt, und vergesst sofort, dass es ihn gibt. Das hat der gesagt, weil er wusste, das ein Schnell/Billig-Einführung nicht geht.
jede IDE hat doch Befehle zum Editieren von Text Löschen von Zeilen etc. Und vim hat mit Sicherheit nicht die schlimmsten key bindings. Zumal diese key bindings quasi überall verwendet werden können (notfalls per Plug-In. Oder meinetwegen, die von emacs. Aber irgendwas muss man doch nehmen.)
zitter_ned_aso schrieb: > Wieviel Tausend Zeilen Code schreibt ihr denn pro Tag? Es wird dich wahrscheinlich überraschen, aber man kann Tastaturen nicht nur fürs Programmieren verwenden.
rbx schrieb: > Das hat der gesagt, weil er wusste, das ein Schnell/Billig-Einführung > nicht geht. Doch! Du kriegst eine Liste mit Befehlen. Fertig. Wenn du so ein Experte bist, dann zeig sie hier.
michael_ schrieb: > Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur > Brust nehmen. > Ist der gleiche Müll. Nein. Dem fehlt vor allem eins: reguläre Ausdrücke. (Auch sonst ist es eher ein mickriger Ableger von dem, was ein ed oder ex kann, und vi, also den "visual mode" kann er meiner Erinnerung nach gleich gar nicht.) Reguläre Ausdrücke sind zwar write-only, aber ihre Flexibilität ist so groß, dass es schlicht kein Stück GUI gibt, was auch nur annähernd so viel in der Suchfunktion kann. (Es gibt natürlich GUIs, bei denen man die Suchbegriffe auch optional als reguläre Ausdrücke interpretieren lassen kann.) > Findet man in LINUX eigentlich noch den Ur-VI? Nö, unter BSD auch nicht, dafür war dessen Quellcode zu lange proprietär. Linux hat vim, BSD hat nvi.
Jörg W. schrieb: >> Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur >> Brust nehmen. >> Ist der gleiche Müll. > > Nein. Dem fehlt vor allem eins: reguläre Ausdrücke. (Auch sonst ist es > eher ein mickriger Ableger von dem, was ein ed oder ex kann, und vi, > also den "visual mode" kann er meiner Erinnerung nach gleich gar nicht.) Für mich waren beide extrem abschreckend. Was verstehst du unter "visual mode"? Nur weil er in einem Fenster einer grafischen Oberfläche läuft? Jörg W. schrieb: > Nö, unter BSD auch nicht, dafür war dessen Quellcode zu lange > proprietär. Linux hat vim, BSD hat nvi. Vielleicht hat jemand ein Bsp. für den Ur-VI, damit man damit rumspielen kann. Und dann ohne Bildschirm, nur mit einem Typenraddrucker als Ausgabe :-)
michael_ schrieb: > Was verstehst du unter "visual mode"? "vi" und "ex" sind zwei Namen für das gleiche Programm. Als "vi" startet es im visual mode für Terminals wie VT100, als "ex" für command line bei Teletypes. Der "ex" Modus steckt im visual mode hinter den ":" commands.
:
Bearbeitet durch User
Gott bewahre! Ich benutze lieber eine richtige IDE. Und für die paar Configdateien in der Konsole reicht nano um Längen und ist auch wesentlich bequemer. Für komplexere Sachen starte ich auch gerne kate. vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw. direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu verlassen. Die Grundkommandos kenne ich. 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 gegen eine richtige IDE kann vim in der Standardeinstellung sowieso nicht anstinken und wenn man erst die Konfiguration ändern muss, kann man es auch gleich bleiben lassen und die IDE nehmen.
Nano schrieb: > Gott bewahre! Laß' mich mal da 'raus, bitte. > Ich benutze lieber eine richtige IDE. > Und für die paar Configdateien in der Konsole reicht nano um Längen und > ist auch wesentlich bequemer. > Für komplexere Sachen starte ich auch gerne kate. 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... Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren Bedienung merken muß, sondern einen Killer wie n?vim? oder Emacs hat, der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting, Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das Wichtigste, den Code, nicht mit drölfzig Einstellungs- und Ausgabefenstern verdeckt. > vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw. > direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu > verlassen. Systemweite Einstellungen für Benutzerpräferenzen sind meistens keine gute Idee. > 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. GUI-Editoren können genau so viel oder wenig wie n?vim? oder Emacs, nicht mehr und nicht weniger. Aber reine GUI-Editoren können eines nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort mal schnell etwas auf einer Remote-Maschine ändern möchte... Nicht selten ist es auch so, daß man die Aufgabe mit einem kleinen, schnellen Editor wie n?vim?, Emacs, oder meinetwegen auch Nano bereits erledigt hat, bevor so eine GUI-Software überhaupt gestartet und einsatzbereit ist... ;-) > Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso > nicht anstinken und wenn man erst die Konfiguration ändern muss, kann > man es auch gleich bleiben lassen und die IDE nehmen. Dafür kann man so eine n?vim?-Konfiguration wunderbar zwischen Maschinen sogar unterschiedlicher Betriebssystemfamilien hin und her kopieren. Den Konfigurationsaufwand macht man sich also nur einmal, danach holt man die Konfig einfach aus dem Repo und gut ist... ;-)
Na endlich geht der Thread in die Richtung die sich der TE gewünscht hat.
Sheeva P. schrieb: > Aber reine GUI-Editoren können eines nicht: mir einen schnellen Zugriff > auf die Dateien meiner Maschinen geben, wenn ich auf einem Boot in > Kroatien oder sonstwo sitze und dort mal schnell etwas auf einer > Remote-Maschine ändern möchte. Wobei sowas vermutlich nur einen Bruchteil der Leserschaft interessiert – und diejenigen musst du schätzungsweise nicht weiter davon überzeugen, warum man auch im Zeitalter von 4K-Monitoren zumindest hin und wieder im reinen Textterminal manche Arbeit (sehr viel schneller) erledigt bekommt als in der GUI. :)
Jörg W. schrieb: > Wobei sowas vermutlich nur einen Bruchteil der Leserschaft interessiert Was wohl auf die meisten technischen Diskussionsthemen zutrifft. Nur bei Politik fühlt sich jeder angesprochen. ;-)
Hallo, Jörg W. schrieb: > ...zumindest hin und wieder im reinen Textterminal manche Arbeit > (sehr viel schneller) erledigt bekommt als in der GUI. :) Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe, extrem leistungsfähige und universell anwendbare Programme sind, deren immensen Vorteile aber nur dem nutzt und erschließt, der täglich (stündlich?) intensiv damit arbeitet. Für Profis eben. ...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen Nutzung steht. rhf
Roland F. schrieb: > ...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der > Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen > Nutzung steht. Das soll bitte jeder für sich selbst entscheiden. Ich habe aber erstaunlicherweise noch nie von jemandem gehört der sich in vim eingearbeitet hat und das danach für unverhältnismäßig hielt. Unwahrscheinlich, dass das nur an falsch verstandenem Stolz liegt.
Roland F. schrieb: > Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe, Der ursprüngliche "vi" lief auf einer 16-Bit Maschine und war für heutige Verhältnisse geradezu winzig. Emacs ist ein anderes Thema. Der ist von Haus aus sowieso mehr Lisp-Interpreter mit Library als Editor.
Yes, vi is a religion. More than that, it's a cult religion. It started out as a UNIX editor and has now become a Ubiquitous editor. Unlike, say, Microsoft Word, it can also give the illusion of magic. Watching a vi guru doing some heavy editing on a file, as her fingers fly over the keys and textual transformations sweep across the screen, one could believe that one is in the presence of supernatural powers. "Awesome", the audience murmur to themselves. Maybe. http://www.guckes.net/vi/mirror/vi.html
michael_ schrieb: > Findet man in LINUX eigentlich noch den Ur-VI? Zumindest in Arch-Linux wird er defaultmäßig installiert. Ein POSIX-konformes Betriebssystem, das für die interaktive Nutzung vorgesehen ist, sollte die Option POSIX2_UPE unterstützen und damit auch einen Vi mitbringen. Siehe hier: http://www.open-std.org/JTC1/SC22/WG15/docs/options.htm Hier ist eine Liste der zu POSIX2_UPE gehörenden Tools (zweimal nach POSIX2_UPE suchen), darunter auch Ex und Vi: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html michael_ schrieb: > Vielleicht hat jemand ein Bsp. für den Ur-VI, damit man damit rumspielen > kann. Was meinst du mit "Bsp."? Oben habe ich den Link zum Quellcode gepostet: Yalu X. schrieb: > https://github.com/n-t-roff/heirloom-ex-vi michael_ schrieb: > Nee, das ist mit Recht nicht mehr eines Blickes würdig. Doch nicht? Ja was denn nun? Nano schrieb: > Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso > nicht anstinken und wenn man erst die Konfiguration ändern muss, kann > man es auch gleich bleiben lassen und die IDE nehmen. Auch die meisten IDEs müssen konfiguriert und mittels Plug-Ins erweitert werden, wenn man damit mehr als einen speziellen Aufgabentyp erschlagen will. So unterstützt bspw. Eclipse von Hause aus nur Java-Entwicklung. Für alles andere (bspw. C++) muss zusätzlich (mindestens) ein Plug-In installiert werden. Das ist zwar meist kein allzu großes Problem, ist es bei Vim aber auch nicht.
Da viel über remote gearbeitet wird, nutze ich den vi(m) ab und an zur Konfiguration. Manchmal gibt es einfach keine Alternative (z.B. Firewall oder sehr schlanke virtuelle Systeme). Sofern möglich, installiere ich aber den Midnight Commander nach, der in vielen Distrubutionen verfügbar ist.
Roland F. schrieb: > Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe, > extrem leistungsfähige und universell anwendbare Programme sind, deren > immensen Vorteile aber nur dem nutzt und erschließt, der täglich > (stündlich?) intensiv damit arbeitet. Für Profis eben. > > ...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der > Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen > Nutzung steht. Angenommen, das träfe zu, so wäre das der rationale Gesichtspunkt. Aber im Laufe der Jahre sind mir auch schon ein paar Menschen begegnet, die wohl zu diesen 95% zählen würden, und, nunja... das treibt schon seltsame Blüten. Da gibt es zum Beispiel die junge Dame, die Videos für ihren Youtube-Auftritt zusammenschneiden, mit Übergängen versehen und ein bisschen Text darauflegen will. Natürlich geht so etwas nicht mit einer freien oder wenigstensmoderat bepreisten Software, nein, es MUSS eine teure "Profi"-Lösung sein, von deren Funktionen sie, grob geschätzt, etwa 5 bis 10 Prozent nutzt. Oder der ältere Herr, der UNBEDINGT Adobe Photoshop braucht, als ob er seine Urlaubsbilder nicht mit Paint Shop Pro oder The GIMP skalieren könnte. Diesen Sermon kann ich bei Bedarf noch endlos fortsetzen und bin sicher, solche Fälle sind hier vermutlich jedem schon begegnet -- auch in diesem Forum gibt es ja eine signifikante Anzahl von Menschen, für die es keine Alternativen zu Altium oder Eagle gibt... Insofern denke ich, viele Leute wollen Profisoftware, damit sie sich wie Profis fühlen und für den noch so unwahrscheinlichen Fall, daß sie einmal eine besondere Funktion benötigen, kein neues Programm lernen müssen. Nur sind die meisten Profiprogramme so komplex bei der Funktionalität, oft aber auch in der Bedienung und Usability, daß dieselben Nutzer mit der Software eher schlecht bis gar nicht umgehen können. Übrigens, sehr lustig: häufig haben auch Softwarediskussionen, gern auch um "IDE vs. n?vim?/Emacs", das Niveau: "Aber meine IDE kann XY, ätsch" -- und enden dann oft bei "das ist ja super -- das können n?vim?/Emacs schon seit dreißig Jahren. Wann und wie oft hast Du diese Funktion zuletzt genutzt?" Sorry, aber... ich finde das mittlerweile nur noch zum Totlachen. ;-)
michael_ schrieb: > Hans Müller schrieb: >> vi (und vor allem sein Erben vim etc.) ist eine Liebe auf den dritten >> Blick, die es aber Wert ist. > > Nee, das ist mit Recht nicht mehr eines Blickes würdig. Ach, das entscheidest neuerdings Du? Gut zu wissen. > Du wie viele andere hier protzen mit vim o.ä. Natürlich benutzen die Leute den vi nur, um damit zu protzen. Wie muß ich solche Aussagen jetzt verstehen? Nur weil Du nicht damit umgehen kannst, dann kann er kein gutes Werkzeug sein? Du entscheidest was eine gute Software ist, und wer was anderes benutzt, tut das nur zum Angeben? > Die Wenigsten kennen doch den richtig alten vi nicht. Na und? Es gibt ja genug Klone mit demselben Bedienkonzept.
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. Ich muss also nicht einmal meine IDE verlassen, wenn ich so etwas dringen machen muss. > Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren > Bedienung merken muß, sondern einen Killer wie n?vim? Denkfehler! Nano und kate erschließen sich intuitiv, da muss man keine Lernwoche einplanen, wie bei vim. Und was die IDE betrifft, in der sollte man ohnehin Zuhause sein. Zum Entwicklen kann vim da ohnehin nicht mithalten. > oder Emacs hat, > der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting, > Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das > Wichtigste, den Code, nicht mit drölfzig Einstellungs- und > Ausgabefenstern verdeckt. Von Haus aus kann vim das erst einmal nicht. Du musst das alles einrichten. 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. >> vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw. >> direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu >> verlassen. > > Systemweite Einstellungen für Benutzerpräferenzen sind meistens keine > gute Idee. Ich hätte mich da besser ausdrücken sollen. Ich meine damit die individuellen Einstellungen pro Benutzeraccount. > Aber reine GUI-Editoren können eines > nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen > geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort > mal schnell etwas auf einer Remote-Maschine ändern möchte... Nicht > selten ist es auch so, daß man die Aufgabe mit einem kleinen, schnellen > Editor wie n?vim?, Emacs, oder meinetwegen auch Nano bereits erledigt > hat, bevor so eine GUI-Software überhaupt gestartet und einsatzbereit > ist... ;-) Deswegen und dafür habe ich ja auch nano. > >> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso >> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann >> man es auch gleich bleiben lassen und die IDE nehmen. > > Dafür kann man so eine n?vim?-Konfiguration wunderbar zwischen Maschinen > sogar unterschiedlicher Betriebssystemfamilien hin und her kopieren. Den > Konfigurationsaufwand macht man sich also nur einmal, danach holt man > die Konfig einfach aus dem Repo und gut ist... ;-) Das geht bei einer IDE genauso.
Yalu X. schrieb: > Nano schrieb: >> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso >> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann >> man es auch gleich bleiben lassen und die IDE nehmen. > > Auch die meisten IDEs müssen konfiguriert und mittels Plug-Ins erweitert > werden, wenn man damit mehr als einen speziellen Aufgabentyp erschlagen > will. Die Änderungen halten sich bei einer IDE in Grenzen. Fakt ist, bei der IDE ist der Debugmodus mit Ansichtfenster für die Variablen standardmäßig verfügbar. > So unterstützt bspw. Eclipse von Hause aus nur Java-Entwicklung. > Für alles andere (bspw. C++) muss zusätzlich (mindestens) ein Plug-In > installiert werden. Das ist zwar meist kein allzu großes Problem, ist es > bei Vim aber auch nicht. Das stimmt nicht. Es gibt von Eclipse eine extra C/C++ Version. Die kann C und C++ von Haus aus.
Nano schrieb: > Zum Entwicklen kann vim da ohnehin nicht mithalten. Hust, hust – lass dich besser nicht auf diese Diskussion ein. Dass er für dich nicht dafür taugt, ist außer Zweifel¹. Du solltest aber nicht von dir auf andere schließen. ¹ Nicht, weil ich dich für unfähig halten würde, sondern weil du diesen Fakt ja klar und deutlich so artikuliert hast.
:
Bearbeitet durch Moderator
Hallo, JJ schrieb: > Ich habe aber erstaunlicherweise noch nie von jemandem gehört der sich > in vim eingearbeitet hat und das danach für unverhältnismäßig hielt. Was nicht unbedingt meiner Behauptung widerspricht. Diese "Jemande" können ja Profis sein, für die ein Texteditor zur Grundausstattung ihres Arbeitsumfeld gehört. Und ich kann mir gut vorstellen das es dann sinnvoll ist ein Universalwerkzeug einzusetzen, ich zitiere mal: 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... > > Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren > Bedienung merken muß, sondern einen Killer wie n?vim? oder Emacs hat, > der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting, > Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das > Wichtigste, den Code, nicht mit drölfzig Einstellungs- und > Ausgabefenstern verdeckt. > Aber reine GUI-Editoren können eines > nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen > geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort > mal schnell etwas auf einer Remote-Maschine ändern möchte... Wenn man in einem solchen Arbeitsumfeld tätig, in der man 100% aller Editiertätigkeiten mit einem Werkzeug erledigen kann, müsste man schon mit dem Klammerbeutel gepudert sein, wenn man mit einer 80%-Prozentlösung zufrieden gibt. Wie gesagt, für den weniger intensiven "Gebraucher" von Texteditoren halte ich Vi, EMACS und Konsorten für eher weniger geeignet, da der Aufwand zum Erlernen der Bedienung in keinem Verhältnis zum Nutzen steht. rhf
Jörg W. schrieb: > Auch ein Emacs hat aus historischen Gründen seine eigenen Kommandos zur > Navigation (C-P, C-N), aber ich kann mich nicht dran erinnern, wann ich > die das letzte Mal benutzt hätte. Wenn ich Emacs verwende, dann nehme ich immer C-P, C-N. Der Weg mit den Fingern ist einfach kürzer als zu den Pfeiltasten. Und deshalb nehme ich beim vi auch h,j,k,l. Es gibt aber noch einen Grund: Gerade früher bei den seriellen Terminals passierte es desöfteren, dass die Escape-Sequenzen, die z.B. durch die Pfeiltasten erzeugt wurden, vom vi "zerhackt" wurden. Das liegt an den Timeouts, die nicht immer griffen, um ESC-Sequenzen von der ESC-Taste zu unterscheiden. Denn per ESC-Taste kommt man ja wieder in den Kommando-Modus. Meiner Meinung nach war das ein großer Design-Fehler beim vi. Denn fast jede Editiertaste (im VT100/220-Modus) beginnt mit ESC. Beispiel: Pfeil runter ist <ESC>[B. Wenn man dann mal länger die Pfeil-runter-Taste drückte, hatte man dann nachher desöfteren [B[B[B[B[B[B[B[B[B[B[B[B[B[B in der Text-Datei stehen. Von daher habe ich mir schnell h,j,k,l angewöhnt. Dasselbe dann auch mit C-P, C-N beim Emacs. P.S. Den Lieblingseditor, den ich unter "x"-Systemen verwende, ist ein von mir selbstgeschriebener Clone des VAX/VMS-Editors "EDT" - mit vielen Erweiterungen. Da werden sämtliche Tasten des separaten Nummernfeldes als Editier- und Navigationstasten verwendet. Da sie alle eng beieinander liegen, kann man damit ungemein schnell innerhalb der Text-Dateien navigieren. Die Pfeiltasten gehen zwar auch, werden aber wegen der besseren Alternativen durch die EDT-Nummernblocktasten-Navigation fast überflüssig. Und selbstverständlich ist auch die "GOLD"-Taste implementiert ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > Den Lieblingseditor, den ich unter "x"-Systemen verwende, ist ein von > mir selbstgeschriebener Clone des VAX/VMS-Editors "EDT" - mit vielen > Erweiterungen. Hihi. Als wir auf RSX-11 (exakter: OS-RW) endlich den EDT hatten, waren wir alle ziemlich froh. Zuvor gab's nur den EDI … Aber heute könnte ich EDT vermutlich nicht mehr bedienen. ;-)
Jörg W. schrieb: > Aber heute könnte ich EDT vermutlich nicht mehr bedienen. ;-) Zur Auffrischung die Belegung des Nummernblocks ;-)
1 | +-----------------+------------------+------------------+------------------+ |
2 | | PF1 | PF2 | PF3 | PF4 | |
3 | | | Schrittw. Suche | Suche nach ... | Zeile einfügen | |
4 | | GOLD | Hilfe | Suche weiter | Zeile löschen | |
5 | +-----------------+------------------+------------------+------------------+ |
6 | | Kommando ... | | Ersetzen | Wort einfügen | |
7 | | Nächste Seite | Blättern v/z | Anhängen Zw.-Sp. | Wort löschen | |
8 | +-----------------+------------------+------------------+------------------+ |
9 | | Textende | Textanfang | Zw.-Sp. einfügen | Zeichen einfügen | |
10 | | Vorwärts | Rückwärts | Zwischenspeicher | Zeichen löschen | |
11 | +-----------------+------------------+------------------+------------------+ |
12 | | | Lösch.Rest Zeile | | Ersetzen und | |
13 | | Wort vor/zurück | Zeilenende v/z | Rollen Zeile | Weitersuchen | |
14 | +-----------------+------------------+------------------+ | |
15 | | Leerzeile | Mark. aufheben | Enter mit Indent | |
16 | | Zeilenanfang vor/zurück | Markieren | | |
17 | +------------------------------------+------------------+------------------+ |
v/z = vor/zurück, viele Tasten sind abhängig von der eingestellten Richtung. Die Tasten sind alle doppelt belegt, als Vorschalt-Taste dient "GOLD". Funktioniert noch heute im PuTTY, auf der Linux-Console und in jeder xterm-Emulation. Lediglich die "Zeichen einfügen/löschen"-Taste gibts auf der PC-Tastatur nicht (auf dem VT100 aber sehr wohl), weil die Plus-Taste den doppelten Platz einnimmt. Hier muss man sich hier mit Entf/Einfg behelfen. Da alles kompakt auf dem Nummernblock liegt und man diesen blind bedienen kann, ist man unheimlich flott damit.
:
Bearbeitet durch Moderator
Oh jeh, jetzt wirds aber nostalgisch... Ich muss aber gestehen, dass ich den Pfunktionstasten und Datenfreigabe nicht sehr hinterhertrauere. XEDIT war es bei mir damals wohl...
JJ schrieb: > Oh jeh, jetzt wirds aber nostalgisch... Kann man so oder so sehen. Mein Clone-EDT kann mehrere Fenster, kann C-Highlightning, kann UNIX-Befehle (z.B. "make") direkt starten und den Output in ein Editierfenster übernehmen, kann direkt zu fehlerhaften Zeilen im C-Code springen, kann Editier-Macros und auch Scripts in einer (selbst entwickelten) Programmiersprache ausführen. Damit kann er dann auch "Türme von Hanoi", "Pangolins" und andere Spielchen direkt im Textbuffer ausführen ;-) Solche Sachen hatte ich damals dem (Gosling-)Emacs abgeschaut und dann neu implementiert. Lisp fand ich einfach zu grausig. Und weil er eine besondere Art der Speicherverwaltung benutzt (nix verkettete Pointer auf Zeilen), kann er Textdateien bearbeiten, die bis zu 2 GB groß sein können - mit ganz normaler Bearbeitungsgeschewindigkeit. Außerdem lädt er solche großen Dateien schneller als jeder andere Editor. Da macht dann Notepad++, den ich unter Windows gern benutze, ziemlich schnell schlapp. Auch weil die curses- und ncurses-Implementationen damals so grottig waren, hatte ich auch eine neue Curses-Lib geschrieben (damals auch in Teilen in der iX veröffentlicht), welches die Scrolling-Regions und Editierbefehle von Terminals besser nutzte und so die Ausgabe gerade auf seriellen Terminals wesentlich beschleunigte. Ich nutze den Editor auch noch heute, schreibe mit ihm immer noch meine C-Programme - IRMP und eine Menge anderes Zeugs. Außerdem bringe ihm ab und zu auch noch ein paar neue Gimmicks bei. Im wesentlichen besteht der Clone aus der Zusammenfassung der besten Features von EDT, Emacs und vi. Und damit ist der auch heute noch hochaktuell.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Nano schrieb: >> Zum Entwicklen kann vim da ohnehin nicht mithalten. > > Hust, hust – lass dich besser nicht auf diese Diskussion ein. > > Dass er für dich nicht dafür taugt, ist außer Zweifel¹. Du solltest aber > nicht von dir auf andere schließen. > > ¹ Nicht, weil ich dich für unfähig halten würde, sondern weil du diesen > Fakt ja klar und deutlich so artikuliert hast. Nun, das liegt in der Natur der Sache. Vim ist in erster Linie ein Texteditor, keine IDE. Eine IDE ist weit mehr als ein Texteditor und auf die Softwareentwicklung optimiert. Bei der Nutzung von GUI Toolkits, kann man bspw. die GUI mit der IDE zusammenklicken und den Kontrolcode dann anschließen eintragen. Mit vim geht das meines Wissens nach nicht. Deswegen bin ich der Meinung, das vim mit einer IDE nicht mithalten kann. Die IDE ist für ihren Aufgabenzweck optimiert, vim ist auch für Latex und Textdateien da, nicht nur für die Softwareentwicklung. Insofern ist die Optimierung auf einen bestimmten Aufgabenzweck eine andere, bei vim liegt es eher auf das generelle Editieren von Dateien die als Text in diversen Formaten vorliegen, die Spezialisierung einer IDE hat er nicht.
Nano schrieb: > Vim ist in erster Linie ein Texteditor, keine IDE. Die Grenzen sind fließend. Ich bin mit Vim zu wenig bewandert, bin mir aber trotzdem ziemlich sicher, dass der eine vollwertige IDE aufbauen kann. Zumindest mache ich das mit Emacs exakt so (auch den würdest du sicher als "in erster Linie ein Texteditor bezeichnen"¹), und der größte Vorteil dabei ist, dass ich zwar innerhalb der letzten knapp drei Jahrzehnte alles Mögliche an Entwicklungsarbeit erledigt habe, aber trotz der massiv unterschiedlichen Aufgabenfelder in all den Jahren nie meine IDE grundlegend wechseln musste. ;-) Unix-Programmierung, FreeBSD-Kerneldebugging (mit remote GDB), LaTeX, Python, Perl, AVR, ARM – alles in der gleichen IDE, mit der gleichen Tastenbelegung. :) ¹) Wie oben bereits erwähnt worden ist, ist das ohnehin eine falsche Wahrnehmung: Emacs ist seit Jahrzehnten in erster Linie ein Lisp-Interpreter, der halt sehr viele "einfache" Tasten auf den Befehl "self-insert" abbildet, sodass sie das entsprechende Zeichen im aktiven Puffer einfügen.
Nano schrieb: > Vim ist in erster Linie ein Texteditor, keine IDE. Das ist reine Ansichtssache. Dieses http://vim.habermann-net.de/vim-als-ide/ https://dev.to/allanmacgregor/vim-is-the-perfect-ide-e80 und vieles mehr findet man bei google, wenn man dort nach "vim als IDE" sucht.
Lasst doch den armen vi endlich ruhen! Diese Leichenfledderei ist ja nicht auszuhalten.
Jörg W. schrieb: > Nano schrieb: >> Zum Entwicklen kann vim da ohnehin nicht mithalten. > > Hust, hust – lass dich besser nicht auf diese Diskussion ein. Er hat aber Recht, vim ist nun mal ein Editor und keine IDE, kann da also nicht mithalten.
Jörg W. schrieb: > Zumindest mache ich > das mit Emacs exakt so (auch den würdest du sicher als "in erster Linie > ein Texteditor bezeichnen"¹), Emacs: "a great operating system, lacking only a decent editor"
Der vi wird uns alle überleben… Der wird noch laufen, wenn es keine Computer mehr gibt. Notfalls auf einem Toaster.
Jörg W. schrieb: > Emacs ist seit Jahrzehnten in erster Linie ein > Lisp-Interpreter, der halt sehr viele "einfache" Tasten auf den Befehl > "self-insert" abbildet, Perfekte Beschreibung ;-) P.S. https://www.gnu.org/fun/jokes/gnuemacs.acro.exp.html
:
Bearbeitet durch Moderator
Jörg W. schrieb: > dass der eine vollwertige IDE aufbauen kann. Eine halbwertige vielleicht, einen blassen Schatten von einer IDE, das aber auch erst dann wenn man zwölfunddreißig Plugins und Zusatztools installiert hat und dann noch ein Plugin um die Plugins zu verwalten (das ist überhaupt das schärfste) und dann 4 Wochen damit verbringt diesen ganzen Moloch zu konfigurieren. Da kann man ja sogar Eclipse noch einfacher zum Mitspielen bewegen als das mit vim und tausend Plugins in monatelanger Kleinarbeit geschaffene Plugin-Monster, und das will wirklich was heißen! Vim ist ein Editor für den schnellen Edit zwischen Tür und Angel auf der Konsole. Dafür ist er gut. Man sollte ihn soweit lernen daß man eine Datei damit bearbeiten und wieder speichern kann so daß man nicht da steht wie der Ochs vorm Berg wenn nur ein vim verfügbar ist, das reicht. Für alles andere was darüber hinaus geht gibt es heute weitaus besser geeignete Software.
:
Bearbeitet durch User
Frank M. schrieb: > Nano schrieb: >> Vim ist in erster Linie ein Texteditor, keine IDE. > > Das ist reine Ansichtssache. > > Dieses > > .... > > und vieles mehr findet man bei google, wenn man dort nach "vim als IDE" > sucht. Ich habe mir durchaus solche Artikel angesehen, selbst Videos auf Youtube zum Thema VIM und IDE habe ich mir angesehen. Auch habe ich versucht mit VIM zu arbeiten. Aber nichts davon hat mich wirklich davon überzeugt. Das Kernproblem bleibt. VIM muss alles über den Zeichensatz darstellen, damit ist er in der Darstellung einer grafischen IDE schon einmal unterlegen. Auch das navigieren mit Maus kann bei Entwicklungen, die man sowieso mit der Maus testen muss, ein Vorteil sein. Bei VIM ist die Maus allerdings eher ein Fremdkörper, es soll schließlich alles per Tastatureingaben möglich sein und man muss nicht zwischen Maus und Tastatur wechseln. Mit diesem Merkmal wird vim auch immer beworben, sobald man aber eine Anwendung mit GUI entwickelt, ist das hinfällig. GUI Oberflächen zusammenklicken geht mit VIM meines Wissens nach nicht, die beiden Links zeigen diesbezüglich auch nichts, dass das irgendwie möglich wäre. Es macht auch keinen Sinn, da vim auch im Textmodus funktionieren muss und die GUI Toolkits eine grafische Oberfläche erwarten. Wenn man die ausprobieren will und sehen will, wie die aussehen, braucht man also ohnehin den grafischen Modus. Beim Debuggen ist er auch im Nachteil, was auch an den Einschränkungen beim Darstellen liegt. Soll vim bspw. eine Linie Zeichen, dann muss er dazu den Zeichensatz fester breite bemühen und dieses Zeichen ist dann gleich mal ein paar Pixel breit. Ob sichtbar oder nicht, dieser Platz wird dann immer verschwendet. Bei einer grafischen IDE kann man auch eine Linie haben, die nur einen Pixel breit ist und die Pixel links und rechts daneben, sind für andere Sachen verwendbar. Aber wenn ihr mit vim (oder emacs) glücklich seid, dann ist das für mich okay. Ich würde auch niemandem an seinem Arbeitsplatz zum Arbeiten mit einer IDE zwingen, solange er mit vim die Arbeit in der gleichen Zeit hinkriegt.
Nano schrieb: > Auch habe ich versucht mit VIM zu arbeiten. > Aber nichts davon hat mich wirklich davon überzeugt. mich schon. WEnn man C-Libs verwendet, dann hat man unter Eclipse keine Autoverfollständigung. Dort hat man diese Option nur bei Klassen. Ich benutze you-complete-me-Plugin. Und dort wird alles ergänzt / aufgelistet.
zitter_ned_aso schrieb: > bis eclipse gestartet ist, ist vim mit coc schon fertig ;-) Bis Du Dein coc so konfiguriert hast daß es alles kann was Eclipse auch kann (was wahrscheinlich niemals der Fall ist) hab ich mit Eclipse schon das verbleibende Arbeitspensum bis zur Rente abgerissen und sitze im Schaukelstuhl hinter dem Haus und rauch gemütlich ein Pfeifchen.
zitter_ned_aso schrieb: > WEnn man C-Libs verwendet, dann hat man unter Eclipse keine > Autoverfollständigung. Blödsinn.
Frank M. schrieb: > Jörg W. schrieb: >> Emacs ist seit Jahrzehnten in erster Linie ein >> Lisp-Interpreter, der halt sehr viele "einfache" Tasten auf den Befehl >> "self-insert" abbildet, > > Perfekte Beschreibung ;-) Etwas schmerzlich ist mir das mal klar geworden, als ich irgendwann Anfang der 1990er Jahre an einer Datei editiert habe, die einen riesigen {}-Funktionsblock enthielt (irgendein Kernel-Treiber). Im C-Modus wird die schließende geschweifte Klammer ja durch den Befehl "c-electric-brace" überschrieben, und der musste nun intern den ganzen langen Block zurück wandern, um das passende Einrückungsniveau zu finden, auf das er die Klammer setzen soll. Das dauerte gefühlt eine Ewigkeit, und ich habe mir für das Editieren dieser Funktion dann angewöhnt, "C-Q }" zu tippen (Control-Q erzwingt ein "quote", also ein literales Einfügen des nächsten Zeichens unter Aufhebung der sonstigen Tastenbindung). Das dürfte noch auf einem i80368SX / 16 MHz gewesen sein, als der Joke mit den "Eight Megabyte" zumindest noch für ein müdes Lächeln reichte. Heute wäre mancher wohl froh, wenn seine IDE mit Eight Gigabyte flüssig liefe. :-) Bernd K. schrieb: > Er hat aber Recht, vim ist nun mal ein Editor und keine IDE, kann da > also nicht mithalten. Auch du wirst nur durch "Er hat Recht!"-Rufen die Realität bloß nicht ändern. Frank hatte vor dir schon schnell ergugelte Beispiele gepostet, die deine (und Nanos) Behauptungen ziemlich deutlich widerlegen.
Da wir beim Thema vim und IDE sind. Wie sieht's eigentlich mit der Integration von UML in vim inkl Codegenerierung und Darstellung von UML Diagrammen aus? :)
Jörg W. schrieb: > Auch du wirst nur durch "Er hat Recht!"-Rufen die Realität bloß nicht > ändern. Frank hatte vor dir schon schnell ergugelte Beispiele gepostet, > die deine (und Nanos) Behauptungen ziemlich deutlich widerlegen. Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen intregiert ist. Auch fehlt ein Beispiel, wie man die GUI zusammenklickt.
Nano schrieb: > VIM muss alles über den Zeichensatz darstellen Ich gehe stark davon aus, dass diejenigen, die Vim als IDE benutzen, dessen Grafikvariante benutzen und ihn nicht im Textterminal laufen lassen. Zumindest läuft bei mir der Emacs zu weit mehr als 90 % im GUI-Modus (Textmodus eigentlich nur, wenn ich über ssh und ein langsames Netz arbeite). Ich gebe zu, dass ich schon auch über manche Dinge im Emacs hin und wieder überrascht bin, bspw. als ich mal mehr aus Versehen eine PDF-Datei damit geöffnet habe. :-)
Bernd K. schrieb: > Blödsinn. Endlich habe ich einen Experten erwischt, der mir helfen kann. Hier hat sich bis jetzt keiner mit einer Lösung gemeldet: Beitrag "Eclipse CDT: Autocomplete-Funktion bei C-Programmen" Bitte mal hier knowledge droppen ;-)
Nano schrieb: > Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen > intregiert ist. Ja, das müsste jemand zeigen, der Vim wirklich aktiv benutzt.
Jörg W. schrieb: > Nano schrieb: >> VIM muss alles über den Zeichensatz darstellen > > Ich gehe stark davon aus, dass diejenigen, die Vim als IDE benutzen, > dessen Grafikvariante benutzen und ihn nicht im Textterminal laufen > lassen. Zumindest läuft bei mir der Emacs zu weit mehr als 90 % im > GUI-Modus (Textmodus eigentlich nur, wenn ich über ssh und ein langsames > Netz arbeite). Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in einem grafischen Fenster. D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit Textzeichen darstellen. > Ich gebe zu, dass ich schon auch über manche Dinge im Emacs hin und > wieder überrascht bin, bspw. als ich mal mehr aus Versehen eine > PDF-Datei damit geöffnet habe. :-) Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß.
also ich benutze neovim und die sagen seblst: https://neovim.io/charter/ Non-goals - Turn Vim into an IDE - Limit third-party applications (such as IDEs!) built with Neovim - .... Und das ist doch absolut in Ordnung. Dafür gibt es ja die Plugins. Und ein Debugger wird da auch nie integriert sein. Das haben sie selbst geschrieben. Aber sie wollen Schnittstellen anbieten dass man in einer IDE (neo)vim als Editor einbinden kann. Ober bei Firefox/Chrom/etc..
Angehängte Dateien:
-
emacs.png
100 KB
Nano schrieb: > Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in > einem grafischen Fenster. > D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit > Textzeichen darstellen. Für Texte: ja, na klar, wie jeder andere Texteditor einer IDE auch. Ansonsten: siehe Anhang. > Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß. Naja, wenn hier über Eclipse und dergleichen geredet wird, da ist Emacs ein Winzling. Wenn du ihn mit "nano" vergleichst, würde ich zustimmen, aber es wurde ja hier immer die Leistungsfähigkeit von IDEs in den Vordergrund gerückt, nicht die Kleinheit des Editors.
Jörg W. schrieb: > Nano schrieb: > >> Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in >> einem grafischen Fenster. > >> D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit >> Textzeichen darstellen. > > Für Texte: ja, na klar, wie jeder andere Texteditor einer IDE auch. Wenn man mehrere Ebenen hat, die man mit einem Rahmen trennen will, dann braucht der Zeichenmodus mehr Platz. Ebenfalls muss man Hinweisgeber immer mit Zeichen machen. > Ansonsten: siehe Anhang. Das ist jetzt nur ein Bildbetrachtermodus. Ich meinte aber Fensterlogik. > >> Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß. > > Naja, wenn hier über Eclipse und dergleichen geredet wird, da ist Emacs > ein Winzling. Wenn du ihn mit "nano" vergleichst, würde ich zustimmen, Ja, ich vergleiche vi(m) und emacs eher mit anderen Editoren.
Angehängte Dateien:
-
emacs2.png
9,4 KB
Nano schrieb: > Wenn man mehrere Ebenen hat, die man mit einem Rahmen trennen will, dann > braucht der Zeichenmodus mehr Platz. Ja, aber siehe Screenshot oben: das ist dann einfach eine komplette Statuszeile, was natürlich anderweitig sinnvoll ist. > Ebenfalls muss man Hinweisgeber immer mit Zeichen machen. Tooltips gibt's beispielsweise, die funktionieren dann natürlich nur im Grafikmodus, nicht im Text-Pendant. Auch die Breakpoint-Markierung ist ein grafisches Symbol, und farbliche Hervorhebung geht natürlich sogar im Textmodus – allerdings im Grafikmodus mit feineren Nuancen. Habe mal einen Screenshot eines Ausschnitts angehangen. Der rote Punkt ist ein Breakpoint in der aktuellen Debuggersitzung. Die etwas dunkleren Bereiche sind hard <TAB>s. Die wollen wir normalerweise vermeiden, daher werden sie markiert (aber das hier ist 3rd-party code, deshalb bleiben sie drin). Die auffällige gelbe Markierung ist whitespace am Ende der Zeile, den wollen wir auch vermeiden. ;-) Bei sonst üblichen IDEs habe ich immer nur eine Funktion gefunden, mir alle Sonderzeichen (TABs, Spaces) hervorheben zu lassen, was ich deutlich störender fand als hier nur die, die ich eigentlich vermeiden will. > Ja, ich vergleiche vi(m) und emacs eher mit anderen Editoren. Dafür wurde aber hier verdammt viel mit IDEs wie Eclipse argumentiert. ;-)
zitter_ned_aso schrieb: > Bernd K. schrieb: >> Blödsinn. > > Endlich habe ich einen Experten erwischt, der mir helfen kann. Hier hat > sich bis jetzt keiner mit einer Lösung gemeldet: > > Beitrag "Eclipse CDT: Autocomplete-Funktion bei C-Programmen" > > Bitte mal hier knowledge droppen ;-) Gib mal den richtigen Link, denn in dem Thread den Du verlinkt hast scheinen alle Fragen beantwortet zu sein und das angebliche Problem > "WEnn man C-Libs verwendet, dann hat man unter Eclipse keine > Autoverfollständigung" kommt darin auch nicht zur Sprache. Kann vim eigentlich mittlerweile bedingte includes parsen oder nicht parsen (je nachdem welche Symbole definiert sind) und das bei der Autovervollständigung berücksichtigen? Kann vim den code der innerhalb von unerfüllten #ifdef steht ausgrauen so daß man mehr Übersicht darüber hat welcher Code benutzt wird und welcher nicht? kann vim Makros expandieren oder Funktionssignaturen und Dokumentation anzeigen wenn man die Maus drüber hält (oder den stechenden Blick drauf richtet falls keine Maus existiert)? Kann es Aufrufer- und Aufrufbäume anzeigen?
:
Bearbeitet durch User
Noch eine Ergänzung zur Diskussion vi(m) versus IDE: Einen vim als IDE aufzuziegeln würde ich mir tatsächlich nicht antun wollen. Aber umgekehrt, die Möglichkeit eine IDE mit einem vim-editor zu ergänzen nutze ich gerne. Zumindest bei Eclipse und VSC funktioniert das sogar sehr gut. Natürlich sind dabei einige Einschränkungen in Kauf zu nehmen, aber bei den wichtigsten Funktionen fühle ich mich zuhause ;)
Andi schrieb: > Zumindest bei Eclipse und VSC funktioniert das sogar sehr gut. Der Witz ist, dass manche VSC-Nutzer wahrscheinlich das gleiche Tool benutzen, wie die vim-Nutzer mit dem ycm-Plugin. Nämlich clangd. Und dann aktivieren einige wahrscheinlich noch vim's keybindings. Aber vim, nein das geht natürlich nicht ;-) https://clang.llvm.org/extra/clangd/Installation.html
Jörg W. schrieb: > Die auffällige gelbe Markierung ist whitespace am Ende der > Zeile, den wollen wir auch vermeiden. ;-) Moderne Editoren verfügen über eine Option beim Speichern der Datei Whitespace am Ende einer Zeile einfach zu entfernen. Ich habe so eine Option immer an, insofern muss ich das nicht extra anzeigen.
Nano schrieb: > Moderne Editoren verfügen über eine Option beim Speichern der Datei > Whitespace am Ende einer Zeile einfach zu entfernen. Das ist anders K*cke. Wenn ich in einer Datei eine Zeile bearbeite, dann möchte ich nicht, dass ggf. noch 25 andere Zeilen „unter der Hand“ verändert werden. Das bläht sinnlos die Diffs im VCS auf und obfuscated das, was tatsächlich geändert worden ist – ganz zu schweigen davon, dass es das Einpflegen von Updates an Code, der 3rd-party ist, massiv behindern kann. Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein Tool auf meinem Computer. Daher ist es wichtig, dass ich sehe, was ich im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder <TAB>-Zeichen, die ich vielleicht gar nicht haben wollte).
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Nano schrieb: >> Moderne Editoren verfügen über eine Option beim Speichern der Datei >> Whitespace am Ende einer Zeile einfach zu entfernen. > > Das ist anders K*cke. Wenn ich in einer Datei eine Zeile bearbeite, dann > möchte ich nicht, dass ggf. noch 25 andere Zeilen „unter der Hand“ > verändert werden. Das bläht sinnlos die Diffs im VCS auf und obfuscated > das, was tatsächlich geändert worden ist – ganz zu schweigen davon, dass > es das Einpflegen von Updates an Code, der 3rd-party ist, massiv > behindern kann. Bei eigenen VCS kann man sich darauf einigen, dass das jeder so macht. Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur Speicherplatz belegen und den Parser des Compilers verlangsamen. Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug auch beenden. Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass Whitespace am Ende von Zeilen erhalten bleiben. > Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein > Tool auf meinem Computer. Das kannst du durch, die Einstellung musst du schließlich selber vornehmen. Natürlich wäre es wünschenswert, dass so eine Einstellung standardmäßig eingestellt ist, dann würden weitaus mehr Textdateien ohne Whitespace am Zeilenende existieren und sich mehr Leute damit abfinden. > Daher ist es wichtig, dass ich sehe, was ich > im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder > <TAB>-Zeichen, die ich vielleicht gar nicht haben wollte). Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der gleichen Begründung ja auch nicht entfernen.
Bernd K. schrieb: > Kann vim eigentlich mittlerweile bedingte includes parsen oder nicht > parsen (je nachdem welche Symbole definiert sind) und das bei der > Autovervollständigung berücksichtigen? Ja. Das YCM-Plug-In wurde schon ein paar mal angesprochen. Es verwendet clangd und damit den C/C++-Parser und weitere Teile von Clang. Damit sind eine ganze Reihe semantischer Aktionen möglich. Hier gibt es eine Übersicht: https://github.com/ycm-core/YouCompleteMe#quick-feature-summary Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde.
:
Bearbeitet durch Moderator
Bernd K. schrieb: >> und was noch viel wichtiger ist -und >> was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten >> zu lassen ( am besten die Pfeiltasten remappen ). >> Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu >> den Pfeiltasten zucken;-) > > Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV. Diese > Tastenbelegung stammt noch aus einer Zeit als man noch elektrische > Schreibmaschinentastaturen in Terminals eingebaut hat. Die EDV Welt ist sehr wohl kompatibel zu vim und dessen forks - bis auf die Windowswelt - aber die ist ja zu Glück nicht die EDV-Welt ;-)
Nano schrieb: > Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur > Speicherplatz belegen und den Parser des Compilers verlangsamen. LOL! Wie viele Millionen unnötige Whitespaces hast du denn typischerweise in deinem Quellcode, wenn du dadurch tatsächlich Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst und das sogar dein größtes Problem ist? > Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug > auch beenden. Unfug sind Commits, die an allen möglichen Stellen Änderungen am Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als nerviges Rauschen bemerkbar. > Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass > Whitespace am Ende von Zeilen erhalten bleiben. Ein langjähriger Bug von Microsofts Mail- und Newsgroups-Software war, dass vor dem Versenden ungefragt und nicht abstellbar alle Whitspaces an Zeilenenden entfernt wurden. Das war deshalb ein Problem, weil der übliche Signaturtrenner eine Zeile ist, die aus "-- " besteht, also mit einem Space am Ende, damit man immer noch innerhalb des Textes ein "--" machen kann, ohne dass das fälschlicherweise als Signaturtrenner erkannt wird. So ziemlich jede Software hat das benutzt, um beim Antworten automatisch die Signatur des ursprünglichen Posts zu entfernen. Und ich hatte auch schon File-Formate, die ähnlich wie CSV waren, aber wo die Felder durch TAB getrennt waren. Die Zahl der Felder pro Zeile war fix, aber der Inhalt eine Feldes konnte durchaus auch leer sein. Das heißt, es konnten auch am Zeilenende TABs stehen, die zwingend erforderlich waren. Da ist es ziemlich doof, wenn der Editor die einfach wegwirft. >> Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein >> Tool auf meinem Computer. > > Das kannst du durch, die Einstellung musst du schließlich selber > vornehmen. Dann ist das ja ok. Wenn man das erst einschalten muss, damit das passiert oder man es manuell antriggern muss, ist das vollkommen ok. Die Software soll aber nicht eigenmächtig und quasi heimlich irgendwas am Code ändern. >> Daher ist es wichtig, dass ich sehe, was ich >> im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder >> <TAB>-Zeichen, die ich vielleicht gar nicht haben wollte). > > Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der > gleichen Begründung ja auch nicht entfernen. Er will nur sehen dass sie da sind, damit er selbst entscheiden kann, ob er sie entfernt. Was er nicht will, ist, dass die Software das von selbst tut.
:
Bearbeitet durch User
Rolf M. schrieb: >> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur >> Speicherplatz belegen und den Parser des Compilers verlangsamen. > > LOL! Wie viele Millionen unnötige Whitespaces hast du denn > typischerweise in deinem Quellcode, Vor zig Jahren war es auf IBMs Mainframes üblich, Textfiles in festem Zeilenformat zu speichern, quasi wie Lochkartenstapel. Jede Zeile hatte ihre 80 Zeichen, egal ob was drin stand oder nicht.
Rolf M. schrieb: >> Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der >> gleichen Begründung ja auch nicht entfernen. > > Er will nur sehen dass sie da sind, damit er selbst entscheiden kann, ob > er sie entfernt. Was er nicht will, ist, dass die Software das von > selbst tut. So ist es. Noch schlimmer als TABs und trailing whitespace sind Werkzeuge, die glauben, „klug“ sein zu müssen und ungefragt Dinge tun. > Wenn man das erst einschalten muss, damit das passiert oder man es > manuell antriggern muss, ist das vollkommen ok. Nur, dass man dann nicht nur keine Änderungen hat, sondern auch keine Kennzeichnung, dass da etwas ist, was man vielleicht gar nicht haben will. Nano schrieb: > Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug > auch beenden. Soso. Du meinst, es interessiert Atmicrochip irgendwie, dass wir die TABs in den von ihnen gelieferten Treibern als „Unfug“ ansehen, und deshalb wären sie sofort bereit, all ihren Kram umzuschreiben? Ein wenig weltfremd kommt mir das schon vor.
Rolf M. schrieb: > Unfug sind Commits, die an allen möglichen Stellen Änderungen am > Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als > nerviges Rauschen bemerkbar. Es sei denn, man schaltet "ignore whitespaces" für den diff ein. Es nervt mich auch wenn durch entfernte whitespaces ein diff kaum noch lesbar ist. Allerdings ist das auch nur einmal, danach passt es ja wieder. So dramatisch ist es nun auch wieder nicht. Wenn man im Code einen Block eine Ebene tiefer einrücken muss, hat man das Problem ja auch. Ich lasse mir den diff auch immer mit einem grafischen Tool farbig anzeigen. Dann kann man trotz entfernter whitespaces einigermaßen erkennen, was man sehen möchte. Ich nutzte keinen vi, höchstens mal nano für config Dateien. In meiner Eclipse IDE lasse ich immer alle trailing whitespaces entfernen. Aber nicht des Speicherplatzes wegen ;)
:
Bearbeitet durch User
Yalu X. schrieb: > Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im > krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde. Neovim ist noch schneller! ...und einfacher zu konfigurieren - die .vimrc wird in die ~/.config/nvim/init.vim uebernommen. Die meisten Dinge die jeder in der .vimrc hat, wie set nocompatible sind im Neovim default und werden in der init.vim somit nur aus historischen Gründen gesetzt Ein :checkhealth sagt einem dann im nvim auch, wo es denn klemmt - wenn irgendwas mal falsch gesetzt ist.
Ich weiß nicht, warum so ein Bohei um die Trailing Whitespaces gemacht wird. Da macht man einmal ein
1 | :1,$s/\s\s*$//g |
und der Drops ist gelutscht. Das geht nicht nur im vi(m), sondern in jedem (vernünftigen) Editor, der reguläre Expressions beherrscht. Wenn ein Editor die Trailing Spaces beim Speichern "abstreifen" kann - auch gut. Aber nur, wenn man das für die jeweiligen Dateitypen ab-/einschalten kann. Bei C-Dateien ist es sinnvoll, aber nicht bei strukturierten Dateien, die zum Beispiel feste Satz-/Feldlängen haben.
:
Bearbeitet durch Moderator
Frank M. schrieb: > und der Drops ist gelutscht Es geht ja darum, sie bereits bei Editieren sehen zu können. Dass man sie global wegwerfen kann, ist einfach. :)
Jörg W. schrieb: > Es geht ja darum, sie bereits bei Editieren sehen zu können. Finde ich ein gutes Feature, werde ich in meinem Editor einbauen :-) Beim Lesen von fremden Code ist das übrigens für mich ein Qualitätskriterium. Sehe ich da Massen von Trailing Spaces, zeugt das nicht unbedingt von besonderer Sorgfalt.
:
Bearbeitet durch Moderator
Frank M. schrieb: > 1,$s/\s\s*$//g Danke, sehr nett. Das spart mir das elendige Zusammensuchen dieser Zeichenkette für Editoren, die das Entfernen nicht beherrschen :) Jörg W. schrieb: > Es geht ja darum, sie bereits bei Editieren sehen zu können. Weshalb möchtest du diese sehen? Also im Quellcode?
:
Bearbeitet durch User
900ss D. schrieb: > Weshalb möchtest du diese sehen? Damit ich gleich weiß, wenn ich was falsch mache. Aber wie oben genannt, fremde Codezeilen sind beim Editieren tabu, daher kein pauschales Entfernen aller trailing whitespaces. (Ausnahme: wir einigen uns explizit im Team, dass irgendwas so schlimm missraten ist, dass man mit einem Rundumschlag irgendwas ändert.)
...und auch dann ist es nett, wenn man funktionale Änderungen von "ich hab die Datei sowieso angefasst und deswegen mal die ganzen Trailing Whitespaces gelöscht" zumindest in zwei separaten Commits ins VCS einchecken kann. Könnte man natürlich auch, wenn der Editor beim Öffnen automatisch alle Trailing Whitespaces entfernt, aber das muss man merken, Speichern, committen und sich dann noch daran erinnern, warum man die Datei überhaupt geöffnet hat ;) MfG, Arno
900ss D. schrieb: > Weshalb möchtest du diese sehen? Also im Quellcode? Wenn hinter einem \ wahlweise ein Leerzeichen oder ein [CR]LF steht.
Frank M. schrieb: > Beim Lesen von fremden Code ist das übrigens für mich > ein Qualitätskriterium. Wieso? > Sehe ich da Massen von Trailing Spaces, zeugt das > nicht unbedingt von besonderer Sorgfalt. Wieso? Wo ist da der Zusammenhang? Ich schreibe Texte blind im 10-Finger-System; daher habe ich mir angewöhnt, auch am Zeilenende immer ein Leerzeichen zu machen, damit die Worte nicht zusammen- kleben, wenn ich den Umbruch ändere. Diese Angewohnheit kann ich natürlich beim Programmieren nicht selektiv abschalten; das bedeutet, dass auch meine Quelltexte als letztes Zeichen jeder Zeile ein Leerzeichen haben. Wieso ist das jetzt ein Zeichen mangelnder Sorgfalt?
Angehängte Dateien:
-
emacs3.png
90 KB
Das ist ja zumindest konsistent. Aber sowas hier sieht doch einfach nur hingeschludert aus. (Ich habe mir jetzt einfach wahllos eine Datei aus irgendwelchem 3rdparty-Code rausgegriffen, bei der ich per grep besonders viel trailing whitespace gefunden habe – dass es gerade diese ist, hat also keine weitere Bedeutung.)
A. K. schrieb: > Wenn hinter einem \ wahlweise ein Leerzeichen oder ein [CR]LF steht. Oh ja, stimmt.... in makefiles ist das auf nicht so hübsch mit trailing Spaces ;) Ich falle zu selten auf die Klappe deshalb waren mir die Situationen nicht eingefallen. Wenn ich dann mal Falle, brauch ich auch immer bis ich darauf komme. Und dann "klatsch" vor die Stirn :) Jörg W. schrieb: > Aber wie oben genannt, fremde Codezeilen sind beim Editieren tabu Hmm.... das ist aber auch eine Philosophiefrage ;)
:
Bearbeitet durch User
Egon D. schrieb: > Ich schreibe Texte blind im 10-Finger-System; daher habe ich mir > angewöhnt, auch am Zeilenende immer ein Leerzeichen zu machen, damit die > Worte nicht zusammen- kleben, wenn ich den Umbruch ändere. Wie das Leerzeichen, welches ich in Deiner Formulierung
1 | "zusammen- kleben" |
sehe? Du machst also vorsorglich hunderte bis tausende Trailing Spaces in den Quellcode, damit Du nicht nicht eines nachträglich einfügen musst, wenn Du mal den Umbruch änderst? Wie verfährst Du dann bei mehrzeiligen C-Makros, wo das Backslash als letztes Zeichen in der Zeile stehen muss, wie A.K. bereits schrieb? Da lässt Du sie dann inkonsequenterweise weg? Aber zu Deiner ursprünglichen Frage: Ich meinte es so, wie Jörg es darstellte, nämlich die inkonsistente Anwendung. Bei globalen Ersetzungen können solche eingestreuten Trailing Spaces im Fall von Regular Expressions schon mal zum Stolperstein werden...
:
Bearbeitet durch Moderator
Egon D. schrieb: > Ich schreibe Texte blind im 10-Finger-System; daher > habe ich mir angewöhnt, auch am Zeilenende immer ein > Leerzeichen zu machen, damit die Worte nicht zusammen- > kleben, wenn ich den Umbruch ändere. Da wir hier im Vi-Thread sind: Der Vi fügt automatisch ein Leerzeichen ein, wenn zwei oder mehr Zeilen mit J zu einer einzigen verbunden werden. Da muss man die Leerzeichen nicht schon prophylaktisch ans Ende jeder Zeile schreiben.
Yalu X. schrieb: > Der Vi fügt automatisch ein Leerzeichen ein, wenn zwei oder mehr Zeilen > mit J zu einer einzigen verbunden werden. Stimmt! Schon 1000mal genutzt und niemals über diese "Selbstverständlichkeit" nachgedacht, sondern immer einfach so hingenommen. > Da muss man die Leerzeichen > nicht schon prophylaktisch ans Ende jeder Zeile schreiben. Ja, das ist wirklich praktisch.
Frank M. schrieb: > Du machst also vorsorglich hunderte bis tausende Trailing > Spaces in den Quellcode, damit Du nicht nicht eines > nachträglich einfügen musst, wenn Du mal den Umbruch > änderst? Nein. (Man merkt, dass Du nicht blind schreibst...) Ich versuch's nochmal neu und von Anfang an: Ich schreibe überwiegend natürlichsprachliche Texte; Programmquelltexte sind in der Unterzahl. Blindschreiben haben ich primär dafür erlernt, natürlichsprachliche Texte flüssig schreiben zu können. (Blindschreiben schadet beim Programmieren nicht, hilft aber auch nicht viel.) In natürlichsprachlichen (in meinem Fall: deutschsprachigen) Texten folgt auf jedes Wort ein Leerzeichen. Ich muss also OHNEHIN nach jedem Wort ein Leerzeichen tippen! Es ist daher für mich eine merkbare zusätzliche Anstrengung, alle soundsoviele Worte eine AUSNAHME zu machen und das (eigentlich unnötige) Leerzeichen am Ende der Zeile zu unterdrücken. Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte außerdem eine Reihe von Nachteilen: Manche Programme (wie z.B. "Write" unter Windows, das ich eine Weile lang benutzt habe), bieten automatischen Umbruch. In diesem Falle weiss ich sowieso nicht, welches das "letzte" Leerzeichen auf der Zeile ist -- und kann es also auch nicht weglassen. Auch bei manuellem Umbruch ist es lästig, bei Änderungen dauernd nachträglich Leerzeichen einfügen zu müssen. In der Summe ist es für mich seit 30 Jahren am praktikabelsten, einfach nach jedem Wort ein Leerzeichen zu machen und mich nicht darum zu scheren, ob dieses Wort am Zeilenende steht oder nicht. > Wie verfährst Du dann bei mehrzeiligen C-Makros, wo das > Backslash als letztes Zeichen in der Zeile stehen muss, > wie A.K. bereits schrieb? Da lässt Du sie dann > inkonsequenterweise weg? Ja, muss ich ja. Was bleibt anderes übrig? Das sind die Stellen, die ich dreimal kontrolliere, damit auch WIRKLICH KEIN Leerzeichen dasteht... > Aber zu Deiner ursprünglichen Frage: Ich meinte es so, > wie Jörg es darstellte, nämlich die inkonsistente > Anwendung. Bei globalen Ersetzungen können solche > eingestreuten Trailing Spaces im Fall von Regular > Expressions schon mal zum Stolperstein werden... Okay... so ist das nachvollziehbar.
Egon D. schrieb: > Ich schreibe überwiegend natürlichsprachliche Texte; Programmquelltexte > sind in der Unterzahl. Okay, das sind zwei vollkommen unterschiedliche Anwendungen. Ich bezog mich auf Quellcode, nicht auf Romantexte.
Frank M. schrieb: > Egon D. schrieb: >> Ich schreibe überwiegend natürlichsprachliche Texte; >> Programmquelltexte sind in der Unterzahl. > > Okay, das sind zwei vollkommen unterschiedliche > Anwendungen. Ich bezog mich auf Quellcode, nicht auf > Romantexte. Wenn Du mehr als die ersten vier Zeilen gelesen hättest, wüsstest Du, dass ich AUCH von Quelltexten rede. Ist aber nicht so wichtig.
Yalu X. schrieb: > Da muss man die Leerzeichen nicht schon prophylaktisch > ans Ende jeder Zeile schreiben. Ich schreibe es ja nicht prophylaktisch an das Ende jeder Zeile -- ich lasse nur das ohnehin jedem Wort folgende Leerzeichen nicht ausnahmsweise am Zeilenende weg!
Egon D. schrieb: > Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte > außerdem eine Reihe von Nachteilen: Manche Programme (wie > z.B. "Write" unter Windows, das ich eine Weile lang benutzt > habe), bieten automatischen Umbruch. Vim auch. Du tippst einfach munter darauf los, mit einem Leerzeichen nach jedem Wort. Ist die Zeile voll (die Textbreite ist ein änderbarer Parameter), hüpft das letzte Wort automatisch an den Anfang der nächsten Zeile, und das nun überflüssige Leerzeichen davor wird gelöscht. Du kannst auch einen ganzen Textblock (oder den gesamten Text neuformatieren, wenn nach dem Löschen von Text nicht mehr alle Zeilen die Textbreite ausfüllen. /* * Dieses Umformatieren funktioniert auch in Quelltextkommentaren wie * bspw. diesem hier. Die Sternchen am Anfang jeder Zeile bleiben dabei * erhalten, ggf. werden auch neue hinzugefügt. */ # In Python und Bash-Skripten (mit der Raute als Kommentarsyntax) # funktioniert das ebenso.
Yalu X. schrieb: > Egon D. schrieb: >> Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte >> außerdem eine Reihe von Nachteilen: Manche Programme (wie >> z.B. "Write" unter Windows, das ich eine Weile lang benutzt >> habe), bieten automatischen Umbruch. > > Vim auch. Du tippst einfach munter darauf los, mit einem > Leerzeichen nach jedem Wort. Ist die Zeile voll (die > Textbreite ist ein änderbarer Parameter), hüpft das letzte > Wort automatisch an den Anfang der nächsten Zeile, und das > nun überflüssige Leerzeichen davor wird gelöscht. Sehr hübsch. Das bedeutet letztlich, dass vim etwas intelligenter ist als Microsoft "write" oder mcedit -- was ja nicht wirklich überrascht :) Mal sehen. Vielleicht wage ich doch das Abenteuer meines Lebens und wechsele vom mcedit auf irgendwas anderes...
Yalu X. schrieb: > Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im > krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde. Das würde ich von einem Editor auch erwarten. Ich achte grundsätzlich darauf, dass sich auch GUI Editoren schnell öffnen lassen. Ich mache deswegen sogar den gewählten Editor vom verwendeten Desktop Environment abhängig. Denn GUI Bibliotheken, die schon im Speicher liegen, müssen nicht erst geladen werden. Unter KDE sind das bspw. qt und die kde libs, also muss es ein Editor sein, der auf solchen Bibliotheken basiert, damit der schnell da ist, wenn man ihn braucht. Unter Mate, das gtk verwendet, würde ich daher bspw. kein Kate verwenden. Bei der IDE ist das aber alles nicht wichtig, denn die startet man am Morgen einmal und beendet sie am Abend. Die Startzeit ist daher bei dieser gar nicht so wichtig.
Nano schrieb: > Bei der IDE ist das aber alles nicht wichtig, denn die startet man am > Morgen einmal und beendet sie am Abend. Du meinst, sowas hier:
1 | $ ps aux | fgrep emacs |
2 | j 1568 0.0 0.1 206172 40236 - S 14Nov19 25:04.06 emacs (emacs-26.1) |
3 | j 57361 0.0 0.0 6652 2556 6 S+ 18:00 0:00.00 fgrep emacs |
4 | j 77204 0.0 0.1 153336 40652 11 S 21Nov19 24:09.24 emacs (emacs-26.1) |
Aber immerhin, das System wurde schon am 1. September gebootet, aus irgendeinem Grund wurden die Emacse erst im November (neu) gebootet. ;-)
Rolf M. schrieb: > Nano schrieb: >> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur >> Speicherplatz belegen und den Parser des Compilers verlangsamen. > > LOL! Wie viele Millionen unnötige Whitespaces hast du denn > typischerweise in deinem Quellcode, wenn du dadurch tatsächlich > Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst > und das sogar dein größtes Problem ist? Du kannst mir gerne einen Gegenbeweis liefern, warum man Whitespace am Zeilenende unbedingt benötigt. Für mich ist das Verschwendung von Ressourcen, die mit einer einfachen Einstellung im Editor behoben werden kann und keinerlei weiteren Aufwand kostet. > >> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug >> auch beenden. > > Unfug sind Commits, die an allen möglichen Stellen Änderungen am > Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als > nerviges Rauschen bemerkbar. Sie treten nicht auf, wenn andere sich daran halten würden ihren Editor so einzustellen, dass sie die Whitespaces am Ende entfernen. > >> Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass >> Whitespace am Ende von Zeilen erhalten bleiben. > > Ein langjähriger Bug von Microsofts Mail- und Newsgroups-Software war, > dass vor dem Versenden ungefragt und nicht abstellbar alle Whitspaces an > Zeilenenden entfernt wurden. Das war deshalb ein Problem, weil der > übliche Signaturtrenner eine Zeile ist, die aus "-- " besteht, also mit > einem Space am Ende, damit man immer noch innerhalb des Textes ein "--" > machen kann, ohne dass das fälschlicherweise als Signaturtrenner erkannt > wird. So ziemlich jede Software hat das benutzt, um beim Antworten > automatisch die Signatur des ursprünglichen Posts zu entfernen. Schön, das ist aber ein Mailprogramm, kein Texteditor. Und es ist nur ein einziges Whitespace. Es würde auch nichts dagegen sprechen, wenn man alle Whitespaces entfernt, bis auf eines. Dann wäre das eigentliche Problem auch entschäft und das mit der Signatur würde trotzdem funktionieren. > Und ich hatte auch schon File-Formate, die ähnlich wie CSV waren, aber > wo die Felder durch TAB getrennt waren. Die Zahl der Felder pro Zeile > war fix, aber der Inhalt eine Feldes konnte durchaus auch leer sein. Das > heißt, es konnten auch am Zeilenende TABs stehen, die zwingend > erforderlich waren. Da ist es ziemlich doof, wenn der Editor die einfach > wegwirft. Tabs sind keine Whitespacezeichen.
Jörg W. schrieb: > Nano schrieb: >> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug >> auch beenden. > > Soso. Du meinst, es interessiert Atmicrochip irgendwie, dass wir die > TABs in den von ihnen gelieferten Treibern als „Unfug“ ansehen, und > deshalb wären sie sofort bereit, all ihren Kram umzuschreiben? > > Ein wenig weltfremd kommt mir das schon vor. Hast du Atmicrochip schonmal gefragt? Vielleicht ist das denen gar nicht klar, aber einleuchtend. Vielleicht wären sie sogar dankbar, für den Hinweis, weil sie selbst noch nie daran gedacht haben. Von nichts kommt jedenfalls nichts. Mit Stillstand kriegst du da nie etwas geändert.
Nano schrieb: > Tabs sind keine Whitespacezeichen. Doch eigentlich schon. Zumindest in den meisten gängigen Sprachen.
Egon D. schrieb: > Mal sehen. Vielleicht wage ich doch das Abenteuer meines > Lebens und wechsele vom mcedit auf irgendwas anderes... Da du oft natürlichsprachliche Texte schreibst, würde dir sicher auch die automatische Einrückung (auch nach Neuformatierung) von Strichlisten und Aufzählungen durch Vim gefallen: - Dieses ist der erste Eintrag in der Strichliste. Wenn das Zeilenende erreicht ist, wird automatisch umgebrochen und die nächsten Zeilen passend eingerückt. 1. Dasselbe geschieht auch in Aufzählungen. Auch hier wird am Ende der Zeile automatisch umgebrochen und passend eingerückt. Kurz: Vim ist keine IDE wie Eclipse, kein Textverarbeitungsprogramm wie Word und kein Betriebssystem wie Emacs ;-), hat aber ein Bisschen von allem. Deswegen ist er für mich das Allround-Tool für die Eingabe und Bearbeitung sämtlicher Texttypen, darunter auch meine Forenbeträge hier. Anmerkung: Die obigen Einrückungen werden von der Forensoftware nur auf gewöhnlichen PCs und Laptops korrekt dargestellt, Für Mobilgeräte wird statt des Monospace- ein Proportional-Font verwendet, die Einrückungen werden dabei entfernt.
Nano schrieb: > Hast du Atmicrochip schonmal gefragt? Nein. Es gibt schließlich kein Gesetz, welches die Benutzung von <TAB> verbieten würde, und in vielen Umgebungen ist das durchaus gängig. Sie nicht zu verwenden, ist rein unsere eigene Konvention (die allerdings natürlich auch eine ganze Menge anderer Entwickler nutzen), aber irgendein Grund zur Beanstandung ist es nun wirklich nicht. Wenn du schon mit eingesparten Zeichen argumentierst: ein <TAB> spart 4 oder 8 (je nach Konvention, da ist man sich halt noch viel weniger einig) Leerzeichen. Das wäre also eher ein Argument pro <TAB>. :)
Egon D. schrieb: > > Wieso ist das jetzt ein Zeichen mangelnder Sorgfalt? Es ist schlechter Programmierstil. Der Parser des Compilers muss unnötig ein paar Zeichen mehr durchwandern, braucht also länger. Auf moderner Hardware merkt man das zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren Teil zum CO2 beitragen. Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim Übertragen ohne Komprimierung die Datenmenge. Gut möglich, dass es auch den Codeparser der IDE bzw. des Editors ausbremst. Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen keinerlei nutzen. Sollte es eine Programmiersprache geben, wo man das braucht, dann ist mir die nicht bekannt.
Frank M. schrieb: > Da macht man einmal ein:1,$s/\s\s*$//g > und der Drops ist gelutscht. 1,$s ist viel zu kompliziert. %s reicht auch ;-) Nano schrieb: > Rolf M. schrieb: >> Nano schrieb: >>> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur >>> Speicherplatz belegen und den Parser des Compilers verlangsamen. >> >> LOL! Wie viele Millionen unnötige Whitespaces hast du denn >> typischerweise in deinem Quellcode, wenn du dadurch tatsächlich >> Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst >> und das sogar dein größtes Problem ist? > > Du kannst mir gerne einen Gegenbeweis liefern, warum man Whitespace am > Zeilenende unbedingt benötigt. Es gibt auch noch etwas zwischen "nichts ist schlimmer" und "das braucht man zwingend". Zum Beispiel: "stört überhaupt keinen". Abgesehen davon habe ich dir ein Beispiel genannt, wo ich das benötigt habe. > Tabs sind keine Whitespacezeichen. Doch, natürlich sind sie das.
Nano schrieb: > Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen > keinerlei nutzen. Sollte es eine Programmiersprache geben, wo man das > braucht, dann ist mir die nicht bekannt. Whitspace ist eine davon: https://de.wikipedia.org/wiki/Whitespace_(Programmiersprache) Bei dieser Sprache erhöht Syntax-Highlighting die Lesbarkeit enorm, weswegen Vim sie natürlich unterstützt. Aus Whitespace wird dann Red-/Greenspace :)
:
Bearbeitet durch Moderator
Nano schrieb: > Der Parser des Compilers muss unnötig ein paar Zeichen mehr > durchwandern, braucht also länger. Auf moderner Hardware merkt man das > zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn > deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren > Teil zum CO2 beitragen. Das ist doch Unsinn. Die zusätzliche Zeit zum Parsen im Compiler wird vermutlich im Nanosekundenbereich liegen, oder zumindest mal weeeeeit unterhalb der Grenze des Messbaren. Das ist so, als ob du Sprit sparen willst, indem du das Auto öfters aussaugst, weil du dann 5 Gramm weniger Dreck durch die Gegend fährst. > Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim > Übertragen ohne Komprimierung die Datenmenge. Auch hier ist das nicht signifikant. Wäre das ein Problem, dann müsstest du auch deine Funktionsnamen besonders kurz wählen (was im übrigen sicherlich auch die Compilezeit deutlich stärker reduziert als ein paar weniger Whitspaces). > Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen > keinerlei nutzen. Aber produziert auch keinerlei signifikanten Schaden.
Jörg W. schrieb: > Nano schrieb: >> Bei der IDE ist das aber alles nicht wichtig, denn die startet man am >> Morgen einmal und beendet sie am Abend. > > Du meinst, sowas hier: > >
1 | > $ ps aux | fgrep emacs |
2 | > j 1568 0.0 0.1 206172 40236 - S 14Nov19 |
3 | > 25:04.06 emacs (emacs-26.1) |
4 | > j 57361 0.0 0.0 6652 2556 6 S+ 18:00 |
5 | > 0:00.00 fgrep emacs |
6 | > j 77204 0.0 0.1 153336 40652 11 S 21Nov19 |
7 | > 24:09.24 emacs (emacs-26.1) |
8 | > |
> > Aber immerhin, das System wurde schon am 1. September gebootet, aus > irgendeinem Grund wurden die Emacse erst im November (neu) gebootet. ;-) Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher ihren Ursprung darin hat, bei manchen, insbesondere alten Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen. Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn die schlecht geschrieben wurden. Suspend to Disk oder irgendein anderer Modus (z.b. Standby) nutze ich nur, wenn ich weiß, dass ich sowieso in sagen wir mal ner Stunde wieder an den Rechner gehe.
Nano schrieb: > Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach > dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher > ihren Ursprung darin hat, bei manchen, insbesondere alten > Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen. > Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn > die schlecht geschrieben wurden. Wer aus der Windows-Ecke kommt, ist das ja gewöhnt. Es hat anscheinend Jahre gedauert, bis jemand gemerkt hat, dass Windows 95 nach knapp 50 Tagen reproduzierbar abstürzt. Das hat einfach nie einer so lange laufen lassen ;-) In der Unix-Ecke dagegen war man eher gewöhnt, dass die Maschinen eigentlich niemals ausgeschaltet und höchstens mal alle paar Jahre neu gebootet wurden. Da war allerdings ein Reboot dann auch schon mal mit einem größeren Aufwand verbunden.
:
Bearbeitet durch User
Rolf M. schrieb: >> Da macht man einmal ein:1,$s/\s\s*$//g >> und der Drops ist gelutscht. > > 1,$s ist viel zu kompliziert. %s reicht auch ;-) :g/\ $/s///g Viele Wege führen nach Rom ;)
Rolf M. schrieb: > Nano schrieb: >> Der Parser des Compilers muss unnötig ein paar Zeichen mehr >> durchwandern, braucht also länger. Auf moderner Hardware merkt man das >> zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn >> deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren >> Teil zum CO2 beitragen. > > Das ist doch Unsinn. Die zusätzliche Zeit zum Parsen im Compiler wird > vermutlich im Nanosekundenbereich liegen, Dann ist es kein Unsinn, denn auch Nanosekunden sind eine Einheit für eine Zeitdauer. > oder zumindest mal weeeeeit > unterhalb der Grenze des Messbaren. Das ist so, als ob du Sprit sparen > willst, indem du das Auto öfters aussaugst, weil du dann 5 Gramm weniger > Dreck durch die Gegend fährst. Nunja, das Absaugen kostet Energie. Bei Whitespaces multipliziert sich der Energieverbrauch wenn es viele Nutzer und viele Compilevorgänge gibt. Nimm mal den Linuxkernel als Beispiel. Wer weiß schon, wie oft, von Millionen von Leuten der in den letzten 30 Jahren compiliert wurde. Da summieren sich viele Nanosekunden. Gut möglich, dass es schon Jahre sind. Durch den Skalierungseffekt geht das recht schnell. Und 1 Jahr nen Rechner betreiben, das ist dann durchaus messbar und in Liter verbranntem Erdöl umrechenbar. Die Zeit ist jedenfalls nicht 0, daher sind diese Parserschritte nicht umsonst. >> Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim >> Übertragen ohne Komprimierung die Datenmenge. > > Auch hier ist das nicht signifikant. Wäre das ein Problem, dann müsstest > du auch deine Funktionsnamen besonders kurz wählen (was im übrigen > sicherlich auch die Compilezeit deutlich stärker reduziert als ein paar > weniger Whitspaces). Naja, das eine hat einen Nutzen zwecks besserer Lesbarkeit, das andere ist durch wenig Aufwand vermeidbar und hat in den meisten Programmiersprachen keinen Nutzen. Da sollte man schon abwägen. >> Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen >> keinerlei nutzen. > > Aber produziert auch keinerlei signifikanten Schaden. Ich benutze manchmal die Cursor nach rechts Taste um in die nächste Zeile an den Zeilenanfang zu kommen. Wenn da noch Dutzende Whitespacezeichen sind, dann dauert das deutlich länger. Es kostet also sogar noch reale Arbeitszeit.
Rolf M. schrieb: > Nano schrieb: >> Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach >> dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher >> ihren Ursprung darin hat, bei manchen, insbesondere alten >> Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen. >> Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn >> die schlecht geschrieben wurden. > > Wer aus der Windows-Ecke kommt, ist das ja gewöhnt. Es hat anscheinend > Jahre gedauert, bis jemand gemerkt hat, dass Windows 95 nach knapp 50 > Tagen reproduzierbar abstürzt. Das hat einfach nie einer so lange laufen > lassen ;-) > In der Unix-Ecke dagegen war man eher gewöhnt, dass die Maschinen > eigentlich niemals ausgeschaltet und höchstens mal alle paar Jahre neu > gebootet wurden. Da war allerdings ein Reboot dann auch schon mal mit > einem größeren Aufwand verbunden. Das ist nicht der Grund. Es ist einfach so, dass Früher die Rechner weder Suspend to Disk noch Standby kannten und man sie Zwecks Energiesparen oder weil die Lüfter lärmten, während man schlafen wollte, ausschaltete.
Beitrag #6101070 wurde vom Autor gelöscht.
Rolf M. schrieb: > Es hat anscheinend Jahre gedauert, bis jemand gemerkt hat, dass Windows > 95 nach knapp 50 Tagen reproduzierbar abstürzt. Es stürzte nicht ab, es war nur nicht mehr bedienbar. :) (Weil der Mauszeiger sich nicht mehr bewegte, wimre.) Ich glaube, das war im Jahr 2000, dass der Bugfix dafür kam. Nano schrieb: > keine Leichen im RAM zu haben bzw. Platz zu benötigen Die einzig nennenswerte Leiche heutzutage ist Firefox. Den muss man öfter mal neu booten, da er sich aufbläht. Meine Workstation zu Hause ist eh zugleich Server für alles Mögliche. Der Laptop ist das natürlich nicht, aber suspend to RAM genügt mir da völlig, von da aus ist er in wenigen Sekunden wieder „am Leben“, und zwar exakt so, wie ich ihn vorher verlassen habe. Der Energieverbrauch im Suspend-Modus ist hinreichend gering, dass ich das nicht als nennenswertes Problem sehe.
Rolf M. schrieb: > Da war allerdings ein Reboot dann auch schon mal mit > einem größeren Aufwand verbunden. Und zwar weil beispielsweise die AIX Systeme von IBM beim Start endlose Tests durchführten. Deren x86-Server starteten nicht minder zäh. Einen virtuellen LAMP-Server kannst du im Betrieb neu starten, ohne dass die meisten Anwender das merken, weils nur den Bruchteil einer Minute dauert. Schieb ihn auf Blech und es dauert 5 Minuten.
:
Bearbeitet durch User
Andi schrieb: > Viele Wege führen nach Rom ;) Ein weiterer: 1,$ lässt sich als % abkürzen, also :%s/...
:
Bearbeitet durch User
Egon D. schrieb: > In natürlichsprachlichen (in meinem Fall: deutschsprachigen) > Texten folgt auf jedes Wort ein Leerzeichen. Schon mit diesem Satz widerlegst du dich selbst.
Egon D. schrieb: >> Vim auch. Du tippst einfach munter darauf los, mit einem >> Leerzeichen nach jedem Wort. Ist die Zeile voll (die >> Textbreite ist ein änderbarer Parameter), hüpft das letzte >> Wort automatisch an den Anfang der nächsten Zeile, und das >> nun überflüssige Leerzeichen davor wird gelöscht. > > Sehr hübsch. > Das bedeutet letztlich, dass vim etwas intelligenter ist > als Microsoft "write" oder mcedit -- was ja nicht wirklich > überrascht :) vim intelligenter als write? keine Ahnung - Aber wenn man die Anwender vergleicht, wird es eindeutig;-)
A. K. schrieb: > Andi schrieb: >> Viele Wege führen nach Rom ;) > > Ein weiterer: 1,$ lässt sich als % abkürzen, also :%s/... Du hast offenbar nicht gesehen, dass das die Antwort darauf war: Rolf M. schrieb: > 1,$s ist viel zu kompliziert. %s reicht auch ;-)
Beitrag #6101224 wurde vom Autor gelöscht.
Uhu U. schrieb: > Egon D. schrieb: >> In natürlichsprachlichen (in meinem Fall: deutschsprachigen) >> Texten folgt auf jedes Wort ein Leerzeichen. > > Schon mit diesem Satz widerlegst du dich selbst. Faszinierend. Enorm kleinkariert -- aber faszinierend. Ich spreche Dir meine Anerkennung aus und überreiche Dir den Sonderpreis für gute Beobachtungsgabe.
Yalu X. schrieb: > michael_ schrieb: >> Findet man in LINUX eigentlich noch den Ur-VI? > > Zumindest in Arch-Linux wird er defaultmäßig installiert. > > Ein POSIX-konformes Betriebssystem, das für die interaktive Nutzung > vorgesehen ist, sollte die Option POSIX2_UPE unterstützen und damit auch > einen Vi mitbringen. Siehe hier: > > http://www.open-std.org/JTC1/SC22/WG15/docs/options.htm > > Hier ist eine Liste der zu POSIX2_UPE gehörenden Tools (zweimal nach > POSIX2_UPE suchen), darunter auch Ex und Vi: > > https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html +1 Koppix hätte ich jetzt nicht empfehlen wollen, ich fand die Version von 2006 aus dem ct-Heft mit am Besten. Die Frage, die offen bleibt, ist, welche vi version auf Windows 10 dabei ist. Vermutlich Vim+Vimtutor - bzw. nicht die schlechteste Variante, weil Vim mehrere Undoschritte erlaubt - die sozusagen wie Stützräder für den Anfänger funktionieren. Die braucht man normalerweise auch.
Auf vi zurückzugreifen ist oft notwendig wegen der userfeindlichen Linux-Eigenheiten: es gibt zwar auf jedem System userfreundliche Editoren, aber in bester Linux-Tradition wird deren Name vor einem Neu-User geheimgehalten: einen editor nano zu nennen ist nicht nur blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester Linux-Tradition. In einer Anleitung zu einem Linux-Programm stand mal der Satz: "die Hilfe wird mit J aufgerufen - Hehe, kleiner Scherz von mir, weil Help garkein J enthält." Ja, genauso macht man das als Linux-Programmierer. Wer intuitive Programme schreibt wird in der Linux-Szene nur verachtet. Georg
Georg schrieb: > einen editor nano zu nennen ist nicht nur > blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester > Linux-Tradition. Mitnichten. Der Vorgänger hiess "pico". ;-)
Georg schrieb: > einen editor nano zu nennen ist nicht nur > blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester > Linux-Tradition. Naja, also wem der nano kein Begriff ist der wird den vi(m) wohl auch eher nicht kennen bzw. mit ihm umgehen können.
Georg schrieb: > Auf vi zurückzugreifen ist oft notwendig wegen der userfeindlichen > Linux-Eigenheiten: es gibt zwar auf jedem System userfreundliche > Editoren, aber in bester Linux-Tradition wird deren Name vor einem > Neu-User geheimgehalten: einen editor nano zu nennen ist nicht nur > blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester > Linux-Tradition. Blödsinn! vi war und ist der Standard aller unixoiden Betriebssysteme. Egal ob man auf FreeBSDs, OpenBSD, NetBSD, Solaris, Minix, OSX, MacOS oder eben auch Linux unterwegs ist. Linux spielt da eh nur eine Nebenrolle, genau wie Windows.
Egon D. schrieb: > Faszinierend. > Enorm kleinkariert -- aber faszinierend. > > Ich spreche Dir meine Anerkennung aus und überreiche Dir den > Sonderpreis für gute Beobachtungsgabe. Danke, ich revanchiere mich mit dem Alice-Schwarzer-Preis für Humorlosigkeit ;-)
Echt unglaublich, mit wie viel Liebe ihr am vim hängt :-)
Hier ein paar technische Info über die Anzahl an Sourcecode Lines
verschiedener vi Varianten (und anderer Open Source Editoren):
Kilo: 1298
Unix_V7_ed: 1762
Sandy: 2159
Readline-WinEditLine: 3782
Readline-linenoise: 4773
vi-neatvi: 6475
Plan9-sam-with-extensions: 15572
Brainchild: 29389
vi-WinVi: 31191
Readline-Tecla: 31212
Kakoune: 34842
vi-vis: 42059
Readline-gnu_readline: 43826
Readline-libedit: 45217
PDCurses: 46241
Notepad2: 55996
HexEdit20: 58110
Joe: 72012
HexEdit121: 82713
vi-BSD_4_4_nvi.1.43: 94195
vi-nvi-Berkely_vi: 121728
Scintilla: 131640
Editra: 140782
vi-Elvis: 149560
Neatpad: 157648
Atom: 183710
MadEdit: 196159
Geany: 209771
Notepad++: 254831
notepad2-mod-4.2.25.998: 258226
Programmers_Notepad: 282755
vi-vim: 726514
Emacs: 2142385
Ich schätze, in 5-10 Jahren hat vim den Emacs überholt!
> [überflüssiger whitespace] Rolf M. schrieb: > Aber produziert auch keinerlei signifikanten Schaden. Jedoch sieht es unaufgeräumt und schlampig aus, manch ordnungsliebender Geist mag das durchaus bereits als signifikante Beschädigung empfinden.
joe ist ganz nett, den hab ich mal ne Zeit lang benutzt. Das funktionierte aber auch nur deshalb so gut weil ich in der Jungsteinzeit der Homecomputerei auf dem C64 lange Zeit eine Assembler-IDE benutzt habe deren Editor exakt die selben Tastenkombinationen wie Joe benutzte und mir dann viele viele Jahre später als mir zufällig Joe über den Weg lief dessen Bedienung auf seltsame, fast schon unheimliche Weise vertraut vorkam.
Bernd K. schrieb: > Das funktionierte aber auch nur deshalb so gut weil ich in der > Jungsteinzeit der Homecomputerei auf dem C64 lange Zeit eine > Assembler-IDE benutzt habe deren Editor exakt die selben > Tastenkombinationen wie Joe benutzte Joe hat viele Tastenkombinationen von Wordstar und Emacs übernommen. Beide – insbesondere aber Wordstar – waren auch in den 80er Jahren die Vorbilder für viele andere Texteditioren, so dass sich vermutlich auch die von dir auf dem C64 genutzte Assembler-IDE daran orientiert hat. Mit "jstar" und "jmacs" kann man Joe auch in einem puren Wordstar- bzw. Emacs-Modus starten.
A. K. schrieb: > Georg schrieb: >> einen editor nano zu nennen ist nicht nur >> blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester >> Linux-Tradition. > > Mitnichten. Der Vorgänger hiess "pico". ;-) Pico war mein Standardeditor unter Linux in der Kommandozeile, bis irgendwann dann nano kam.
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. >> Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren >> Bedienung merken muß, sondern einen Killer wie n?vim? > > Denkfehler! Leider befürchte ich, daß der Denkfehler vielmehr auf Deiner Seite liegt. > Nano und kate erschließen sich intuitiv, da muss man keine Lernwoche > einplanen, wie bei vim. Das ist zweifellos absolut richtig. Aber Kate gibt es nur auf Rechnern mit GUI, Nano ist hinsichtlich seiner Funktionalität sehr begrenzt... und ob Nano intuitiv ist, darüber ließe sich zwar streiten, aber: geschenkt. > Und was die IDE betrifft, in der sollte man ohnehin Zuhause sein. Wenn man denn eine IDE benutzt... aber das muß man ja nicht. Und ich denke, daß ebendies Dein Denkfehler ist: die weit verbreitete, dennoch aber irrige Annahme, daß man unbedingt eine IDE bräuchte. Es geht auch ohne, wenn man seine Werkzeuge beherrscht -- und zwar genauso effizient und komfortabel, und häufig obendrein auch noch flexibler. > Zum Entwicklen kann vim da ohnehin nicht mithalten. Au contraire, mein Lieber. Ganz im Gegenteil kenne ich eine lange Reihe von sehr fähigen Profis, die mit dem n?vim? arbeiten. Ich persönlich habe mir solche IDEs immer mal wieder angeschaut und werde mit den Dingern einfach nicht warm. Und die ausufernden Bereiche, Menüs, Symbolleisten und was-nicht-alles verstellen mit den Blick auf das mit Abstand Wichtigste: meinen Code. Die einzige Ausnahme (bei mir!) sind Qt und Ähnliche, bei denen man schnell mal GUIs malen kann -- aber auch da schreibe ich meinen Code dann wieder mit meinem Editor. Und das SQL, die Elasticsearch-Suche, die Konfigurationsdateien, meine Dokumentation und Präsentation in Markdown und LaTeX... Wobei, mittlerweile entwickle ich nur noch sehr wenig klassische GUIs, sondern eher Webapplikationen. Diesen Trend gibt es schon seit einigen Jahren, weil Webapplikationen viel einfacher zu deployen und zu pflegen sind, und ich wähne mich in guter Gesellschaft: die PostgreSQL-Entwickler haben ihr Fatclient-GUI Pgadmin3 mittlerweile eingestellt und setzen für Pgadmin4 auf eine webbasierte Lösung -- auch für lokale Installationen. Schon die meisten nicht vollkommen trivialen Webapps benötigen aber eine Sprache, um die Handler zu implementieren, dazu eine Template-Sprache für HTML, Ecmascript und CSS, häufig SQL, in meinem speziellen Fall oft auch JSON, YAML (schon für Docker Compose), Dockerfiles, Konfigurationsdateien für WSGI, Apache, ... das kann ich alles mit einem einzigen Editor machen, und zwar mit allen klassischen IDE-Features und ja, auch über eine dünne Verbindung von der Marina Frapa. 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? 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? 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! ;-) Aber, klar, das ist meine persönliche Sicht auf die Dinge. Jemand, der weniger oft unterwegs ist und nicht mit Verbindungsproblemen zu tun hat, oder wer im Wesentlichen nur in einer Sprache entwickelt, klar, der kann natürlich zu einem anderen Schluß kommen. Kein Problem, ich will niemand bekehren -- aber andererseits verbitte ich mir Versuche, mich zu bekehren oder meine Werkzeuge als "falsch" oder Ähnliches abzuqualifizieren. (Das ist im Übrigen auch hochgradig unprofessionell und dumm, IMHO.) > 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 -- meistens aufgerufen über ein Makefile. Klar ist es ganz nett, mit einem Druck auf $Funktionstaste einen Debug-Build anzustoßen und den dann gleich im Debugger zu starten, keine Frage. Aber dann habe ich wieder dieses Thema, 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. Ob das so viel komfortabler ist als ein M+Tab und zweimal die Pfeiltaste zu betätigen? Für mich nicht. > 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 der in ein GUI-Programm eingebettet sein muß? Keine Ahnung, sorry, und in etlichen Diskussionen über das Thema hat mir leider auch noch kein Mensch ein überzeugendes Argument geliefert, warum diese hohe Integration von verschiedenen Werkzeugen in ein GUI nötig oder für mich nützlich sein sollte. Ich halte an meiner Arbeitsweise ja nicht zwanghaft fest, ganz im Gegenteil ändere ich mich gerne, wenn ich meine Arbeit dadurch besser (im Sinne von: komfortabler, schneller, ...) machen kann. Vielleicht bist Du derjenige, der mich überzeugen kann? Nur zu, viel Erfolg! ;-)
Sheeva P. schrieb: > 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? 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? > 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! ;-) Das ist aber beim besten Willen kein Alleinstellungsmerkmal von vim... Visual studio code kann genauso syntax highlight für die meist verbreiten sprachen, und mit Plugins gehen dann auch erweiterte Funktionen wie Syntax Vervollständigung, Debugging und Code Analyse. Das gleiche gilt für IDEs wie intellJ IDEA da kann man auch quasi alle verbreiteten Sprechen sinnvoll benutzen. Selbst mit Eclipse würde das gehen, auch wenn das da vermutlich etwas Arbeit ist und es auch ansonsten eine ziemlich lahme Gurke ist...
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, Codegenerator laufen lassen. Nein, nicht integriert -- aber trotzdem nicht weniger komfortabel -- und häufig mit deutlich mehr Kontrolle über den generierten Code. [1] https://de.wikipedia.org/wiki/Dia_(Software)
vim ist ein Texteditor und keine IDE. Man kann mit plug-ins jede Menge erreichen aber eben nicht alles. Wie kann man etwas mit vim vergleichen was 10-20 mal größer ist als vim?
Nano schrieb: > Auch fehlt ein Beispiel, wie man die GUI zusammenklickt. GUIs klickt man mit einem GUI-Zusammenklick-Programm zusammen. Die klugen Leute von QT haben das verstanden und bieten neben der IDE Creator auch den GUI-Builder Designer an. ;-)
Jörg W. schrieb: > Nano schrieb: >> Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen >> intregiert ist. > > Ja, das müsste jemand zeigen, der Vim wirklich aktiv benutzt. 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. Aber das ist de facto nicht richtig und widerspricht natürlich auch der guten alten UNIX-Philosphie, daß jedes Programm idealerweise nur genau eine Aufgabe erledigt, die aber richtig gut. ;-)
Mit NerdTree hat man den Überblick über seine Verzeichnissbäume - den Windowmanager braucht man eigentlich nur für den Browser ... und wenn man klug ist, nimmt man einen Tiling WM und navigiert in dessen Fenstern mit hjkl - genau wie im tmux
Egon D. schrieb: > In natürlichsprachlichen (in meinem Fall: deutschsprachigen) > Texten folgt auf jedes Wort ein Leerzeichen. Verzeihung, aber nein, und dafür ist Dein eigener Text ein gutes Beispiel: hinter "Fall", "deutschsprachigen" und "Leerzeichen" folgt eben kein Leer-, sondern jeweils ein Satzzeichen. ;-)
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 … Ich meinte eigentlich, wie eine Debug-Sitzung mit einem Vim so aussieht. Ich könnte sie für den Emacs zeigen, aber das ist ja gerade nicht das Thema hier.
Sheeva P. schrieb: > Verzeihung, aber nein, und dafür ist Dein eigener Text ein gutes > Beispiel:hinter "Fall", "deutschsprachigen" und "Leerzeichen" folgt > eben kein Leer-, sondern jeweils ein Satzzeichen. ;-) Alle Achtung! Du bist ja fast so ein scharfer Hund wie Uhu. Nur dass dieser denselben Sachverhalt schon 1 Tag früher aufgedeckt hat :) Damit Egon nicht dieselbe Antwort zweimal schreiben muss: Egon D. schrieb: > Faszinierend. > Enorm kleinkariert -- aber faszinierend. > > Ich spreche Dir meine Anerkennung aus und überreiche Dir den > Sonderpreis für gute Beobachtungsgabe.
Max H. schrieb: > Das ist aber beim besten Willen kein Alleinstellungsmerkmal von vim... Nein, das stimmt... aber ich bin ein Emacs-User. ;-) > Visual studio code kann genauso syntax highlight für die meist > verbreiten sprachen, und mit Plugins gehen dann auch erweiterte > Funktionen wie Syntax Vervollständigung, Debugging und Code Analyse. Visual Studio Code ist ja auch keine IDE, sondern ein Editor -- wie n?vim? oder Emacs auch. Und mit entsprechenden Konfigurationen und Plugins können die das auch alle. Ich finde es übrigens ausgesprochen spannend, daß es mittlerweile sogar wieder Bewegung im Bereich der Editoren gibt. Über Jahre hinweg wurden Monolithen und IDEs in den Markt gedrückt, und die wohl höchstentwickelten Editoren für Windows waren aus meiner (sehr beschränkten) Sicht UltraEdit und Notepad++. Aber seit einigen Jahren tut sich wieder etwas: Atom und Sublime haben den Markt betreten, und sogar Microsoft selbst baut nach den vielen Jahren, in denen Visual Studio als das Maß aller Dinge gepriesen würde, mit Visual Studio Code wieder etwas, das im Prinzip "nur" ein leistungsfähiger Editor ist. > Das gleiche gilt für IDEs wie intellJ IDEA da kann man auch quasi alle > verbreiteten Sprechen sinnvoll benutzen. Für viele verbreitete Programmiersprachen stimmt das, aber auch für YAML, Markdown, JSON, Dockerfiles? Zudem ist IDEA leider GUI-only, also wird es mit meiner dünnen Connection im Wattenmeer leider auch nichts... Und dann, und das ist mein wesentlicher Punkt: IDEA ist nach allem, was ich davon gesehen habe, ein wirklich feines Werkzeug, aber: es ist halt kommerzielle Software, und ich habe ehrlich gesagt überhaupt keine Lust, Geld für ein Werkzeug auszugeben oder meinen Chef von dieser Ausgabe zu überzeugen, wenn ich die Funktionen mit einem OSS-Werkzeug abdecken kann, bei dem ich sogar mitarbeiten und meine Bugfixes und Erweiterungen beitragen kann. > Selbst mit Eclipse würde das gehen, auch wenn das da vermutlich etwas > Arbeit ist und es auch ansonsten eine ziemlich lahme Gurke ist... Einer meiner Entwicklerkollegen, die -- mit einer Ausnahme -- allesamt Eclipse benutzen, hat vor einigen Wochen 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. Ich möchte mir anhanddessen kein Urteil über IDEs im Allgemeinen, Eclipse im Besonderen oder gar IDEA erlauben, aber... "\(".)/"
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?
coolman schrieb: > 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. Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem Jahre 1990. Scheint mir aber trotzdem eine akademische Erscheinung zu sein. Ich kann mir kaum vorstellen, dass vim in der Industrie viel genutzt wird. Das gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an Universitäten und Forschungseinrichtungen. Selbst an Fachhochschulen kennt man das nicht. Ich war vor 20 Jahren der einzige, der damit seine Diplomarbeit geschrieben hat. Als Editor hatte ich übrigens emacs. Alle anderen Leute hatten Word genommen.
3.14 schrieb: > Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem > Jahre 1990. > Scheint mir aber trotzdem eine akademische Erscheinung zu sein. Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und verbinden zu müssen. Es gibt Kollegen die wechseln nun zu Neovim. Aber ich kann nicht bestätigen, dass es weniger geworden wäre. 3.14 schrieb: > Das > gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an > Universitäten und Forschungseinrichtungen. > [...] Ich war vor 20 Jahren der einzige, der damit seine > Diplomarbeit geschrieben hat. Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem. In nicht-Forschungs Firmen hast du andere Tools bzw. PR-Abteilungen welche die Dokumente für dich "schön" machen.
Nano schrieb: > Kommentarzeichen A propos Kommentare: Wenn man einen längeren Kommentaren editiert (etwas hinzufügt oder löscht), sieht dieser hinterher meist ziemlich zerfranst aus. Beispiel:
1 | /*
|
2 | * Lorem ipsum
|
3 | * dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
|
4 | * eirmod tempor invidunt
|
5 | * ut labore et dolore magna aliquyam erat, sed diam
|
6 | * voluptua.
|
7 | *
|
8 | * At vero eos et
|
9 | * accusam et justo duo dolores et ea rebum. Stet clita kasd
|
10 | * gubergren, no sea takimata sanctus est
|
11 | * Lorem ipsum dolor sit amet.
|
12 | */
|
13 | |
14 | int main(void) { |
15 | return 0; |
16 | }
|
Statt die Zeilen mühevoll manuell zu verbinden, neu umzubrechen und die Sternchen dabei wieder an die richtige Stelle zu setzen, kann man in Vim auch einfach gqap eingeben oder alternativ den neu umzubrechenden Ausschnitt des Kommentars markieren und gq eingeben. Danach sieht der Kommentar wieder aufgeräumt aus:
1 | /*
|
2 | * Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
|
3 | * eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
|
4 | * voluptua.
|
5 | *
|
6 | * At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd
|
7 | * gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
|
8 | */
|
9 | |
10 | int main(void) { |
11 | return 0; |
12 | }
|
Das funktioniert natürlich auch bei Kommentaren mit // oder #.
Rolf M. schrieb: > 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. Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022 haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt wurden. Hast du schon einmal in das Menü von bspw. Notepad++ geguckt? Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer jemals brauchen wird.
Nano schrieb: > Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022 > haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt > wurden. Süß … du weißt aber schon, dass der Thread mit einer Info zu einem neuen Major-Release vom Vim wieder ins Leben gerufen worden ist, und dass Major-Releases üblicherweise ein Zeichen für Weiterentwicklung sind? Frag ja nur – bei dir liest’s sich so, als wäre die Entwicklung vor dreißig Jahren eingeschlafen. Nano schrieb: > Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer > jemals brauchen wird. Nein.
:
Bearbeitet durch User
Johannes O. schrieb: > Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen > auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen > oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und > verbinden zu müssen. Aber für diesen Zweck braucht man doch nicht so ein kompliziertes Werkzeug wie vim. Da reicht auch ein nano, der ebenfalls überall installiert ist.
Jack V. schrieb: > Ist in der Tat schon erschreckend, wenn jemand den Nano so anbetet ... Ja kann man so sehen. Aber Mein Gott, es gibt Schlimmeres und ob der Nick wirklich vom gleichnamigen Editor herrührt weis nur der Nano selbst. Viel erschreckender finde ich da hingegen Leute, die sich sofort angepisst fühlen, wenn man bezüglich ihrer Lieblingsspielzeuge, egal OS, Programme (z.B. vi/vim) oder what ever, eine andere Meinung vertritt als sie selbst. Das hat schon eher was Religiöses bzw. Sektenhaftes. Jack V. schrieb: > ich nehm’ dich sowieso nicht mehr ernst Das beruht dann wohl auf Gegenseitigkeit. Leute die ihre Werkzeuge verteidigen wie eine Wölfin die Jungen, kann man eh nicht wirklich ernst nehmen. Jack V. schrieb: > 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. Da können die Mitleser aber wirklich froh sein das Du ihnen jetzt ein Werkzeug in die Hand gibst, mit dem sie meine Beitäge ordentlich bewerten können. Hoffentlich sind sie von soviel Erleuchtung nicht geblendet. Du hast wirklich keine anderen Probleme.
Jack V. schrieb:> > 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 Wie schon gesagt, du musst einfach auch mal den Thread lesen. Das setzt natürlich Leseverständnis voraus. Also nochmal kurz für dich, für Configdateien und kurzen Notizen werde ich kein Vim üben, weil ich da für das Bisschen keine leistungsfähigen Editorfeatures brauche und da wo es interessant werden könnte, nämlich beim Programmieren, da versagt er gegenüber einer IDE bei der Debuggerintegration. Warum soll ich mir das dann also antun? Oben habe ich eine Frage gestellt zu diesem youcompleteme. Anstatt die Frage mal zu beantworten, suchst du wieder Streit. Und anstatt ne Vim Config mit Debuggerübersicht zu liefern, was ich ja als Kritikpunkt erwähnt habe, machst du mit deinen persönlichen Angriffen nur so weiter, und das nicht nur vorgestern und gestern, sondern auch heute schon wieder. Wie das Kommentar auf Zeno zeigt, ich habe deine heutigen persönlichen Angriffe wieder fett markiert: Jack V. schrieb: > 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. Quelle: Beitrag "Re: Vi Editor ausgestorben?" All das zeigt, Jack V., du hast ein Problem mit dir selbst und das haben hier schon viele erkannt und dir versucht mitzuteilen, aber du willst nicht daraus lernen. Auch wurde dir bereits gesagt, dass dein Verhalten fanatisch religiöse Züge annimmt, was man in der Tat so unterschreiben kann, aber auch das bringt dich nicht zum Umdenken, du machst gerade so weiter fanatisch radikalisiert alle anzugreifen, die vim nicht nutzen wollen und bspw. andere Editoren haben, mit denen sie die genannten Problemstellungen lösen können. Und wenn sie dir dann sagen, wie sie mit den anderen Editoren diese Probleme lösen, insbesondere deine von dir gestellten Aufgaben, dann passt es dir nicht dass es mit den anderen Editoren auch geht und du greifst sie wieder an, was dein obiges Kommentar eindrucksvoll zeigt. Und auch hier, man achte mal auf die unsachlichen Wertungen und Wörter in deiner Antwort. Ich habe sie ebenso nochmal fett hervorgehoben: Jack V. schrieb:> > – 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. Wir haben hier also als Liste: - irrationale Zwang - krampfhaft - Absurditäten - Orgie - fully bloated - hochreißen - rumstochern Und das alles wieder bespickt mit deinen religiös getriebenen Vorwürfen, wie dass ich krampfhaft versuchen würde dir zu beweisen, dass nano genauso leistungsfähig wäre wie dein vim. Dabei muss ich das nicht (Anmerkung: wie du weißt, nutze ich nano für Configs und einfache Sachen) und war auch gar nicht der Fall, sondern du hast mich gefragt, wie man dies und jenes Problem in nano lösen kann und ich habe es dir lediglich beantwortet. Und die Antwort, dass das mit nano geht, das ist das, was dich in deinem reliögsen Wahn so stört und auf die Palme bringt, die gefällt dir nicht, vermutlich weil du davon dein vim angegriffen fühlst, in das du so viel Zeit und Aufwand reingesteckt hast und dann können andere ähnliche Probleme ohne nennenswerten Aufwand lösen und deswegen greifst du nun wieder, wie man es oben sehen kann, persönlich an und unterstellst mir wieder einen Zwang und sonstiges krampfhaftes Verhalten. Und das ist nicht nur bei mir so, denn auch Zeno hast du angegriffen. Womit wir wieder bei der Erkenntnis sind, das du ein Problem mit dir selbst hast und daran arbeiten solltest. > 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? Wen interessiert was du machst? Du hast mich gefragt, wie ich das löse und ich habe dir die Antwort gegeben. Und daraus machst du jetzt wieder ein Problem. Genau das, was ich oben gerade beschrieben habe. Niemand will wissen, wie du deine Probleme mit vim löst, keiner hat dich gefragt und auch du wurdest nicht gefragt, denn deine Frage hast du nicht an dich selbst gestellt, sondern an mich gestellt, aber das was du anderen hier vorwirfst, dass die krampfhaft versuchen würden, ihren Editor zu verteidigen, das machst du hier selbst mit deinem vim. Das sieht man hier deutlich, wenn ich dir sage, dass ich eine solche Aufgabe mit awk löse und du dann ungefragt und krampfhaft darauf hinweisen musst, warum vim besser sei als das CLI Tool awk sei und das obwohl dich keiner danach gefragt hat. Dieses krampfhafte Wettstreit vim gegen den Rest der Welt, der entsteht ausschließlich in deinem Kopf. Also guck mal in den Spiegel und schließe nicht immer von dir auf andere.
Johannes O. schrieb: > Es gibt Kollegen die wechseln nun zu Neovim. Worin liegt eigentlich der Unterschied zwischen Vim und Neovim? Was macht Neovim anders? Wer kann die Frage objektiv und sachlich (Jack V., du bist nicht gefragt) beantworten? Ich glaube oben wurde schonmal "unterstützt das Language Server Protokoll out of the box", erwähnt, aber wie geht es weiter?
Nano schrieb: > Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022 > haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt > wurden. Das erste, was ich auf einem neuen System baue, ist ein File .vimrc mit "syntax off" darin, damit ich das Zeug noch lesen kann. Irgendein komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten in einem dunklem Rot vor schwarzem Hintergrund zu verstecken. Sowie zu Neuheiten. ;-) Wie schon jemand oben benutze ich vi/vim seit zig Jahren, aber praktisch nur im Kontext von Systemtechnik, nicht als Programmierplattform. Da ist es ziemlich Banane, ob vi, vim oder neovim. Man kann das also trennen. Ernsthafte Programmierung läuft anders ab. Und vi* ist halt drauf.
:
Bearbeitet durch User
Nano schrieb: > 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 Ja, das geht mir auch so. Deswegen nehme ich für solche (wie auch für alle anderen) Dinge Vim. Der erste Start dauert im Textmodus 0,2s im Grafikmodus unter X11 1,2s. Das ist zwar etwas länger als bei Nano oder Vi, aber diesen Zeitnachteil habe ich beim Editieren ganz schnell wieder aufgeholt :) > 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. Beim wiederholten starten von Vim (egal ob im Text- oder Grafikmodus) ist praktisch kein Zeitverzug erkennbar (also <0,1s). 3.14 schrieb: > Johannes O. schrieb: >> Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen >> auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen >> oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und >> verbinden zu müssen. > > Aber für diesen Zweck braucht man doch nicht so ein kompliziertes > Werkzeug wie vim. Natürlich wäre es Unfug, sich nur für das Editieren von Config-Dateien in Vim einzuarbeiten. Wenn man aber Vim sowieso schon kennt, weil man ihn auch für andere Dinge einsetzt, wäre es fast genauso unsinnig, sich in Nano einzuarbeiten, selbst wenn dort die Einarbeitung nur eine Viertelstunde dauert.
Nano schrieb: > Worin liegt eigentlich der Unterschied zwischen Vim und Neovim? > Was macht Neovim anders? Neovim wird von einer Community ziemlich offen entwickelt und ist daher deutlich agiler in der Entwicklung, als Vim, bei dem die Entwicklung in einer einzelnen Person zusammenläuft. Das hat unter Anderem zu nativem SLP-Kram geführt, und auch dazu, dass zum Scripten Lua zum Einsatz kommen kann. Daneben gibt es noch eine Latte an Details, die alle aufzuführen hier nicht zielführend sein wird. Nano schrieb: > Jack V., du bist nicht > gefragt Interessiert mich nicht. Sachliche Fragen bekommen sachliche Antworten – im Gegensatz zu dem, was du dir einzubilden scheinst, habe ich nichts gegen dich. Deine komische Textwüste weiter oben, mit den wilden Vermutungen und Unterstellungen, bei gleichzeitigen Rechtfertigungsversuchen der eigenen Irrationalität – naja, da sehe ich mich wirklich nicht mehr gefragt. Das ist mir dann doch zu absurd :)
(prx) A. K. schrieb: > rgendein > komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten > in einem dunklem Rot vor schwarzem Hintergrund zu verstecken. background=dark als Konfigurationsoption ist bekannt?
Nano schrieb: > nano > bietet das Entfernen oder Setzen von Kommentarzeichen mit der Taste ALT > + 3 an. Oh, das kannte ich noch nicht. Bei Bashscripten und C-Files funktioniert es perfekt. Beim Mac muß man übrigens Shift+Option+3 drücken.
Jack V. schrieb: > background=dark als Konfigurationsoption ist bekannt? Das Kernproblem sind nicht die Farbspiele diverser Tools, sondern meine Gene. Ist bei LEDs nicht anders, jenen, die für rund 90% der männlichen Bevölkerung gebaut sind und vom Rest verflucht werden.
:
Bearbeitet durch User
Nano schrieb: > Denn Notepad++ nutzt direkt > die WinAPI und ist damit auch sehr schnell geladen. Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile bevorzuge ich da aber PSPad. Bei diesem kann man links eine Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem anderen Rechner verbinden und durch dessen Verzeichnisstruktur navigieren.
Jack V. schrieb: > 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. Tja bei Dir ist es genau anders herum. Du konstruierst eben einfach etwas, um nachzuweisen das es ohne Dein Lieblingsspielzeug nicht geht.
Johannes O. schrieb: > Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs > Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor > allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei > größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen > Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem. Ich habe mich lange Zeit mit LaTeX schwer getan. Wenn ich allerdings eine richtig ordentliche Dokumentation erstellen will, dann benutze ich das mittlerweile gern, weil man ein ordentliches in sich konsistentes Ergebnis erhält.
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. Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es einigermaßen beherrscht? Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um statt in der Kreisklasse in der Verbandsliga zu spielen? Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen, wenn einem mal langweilig ist: https://www.youtube.com/watch?v=KuLy5LzHEzU (Kommentare dazu lesen, ist auch gar nicht so schlecht)
rbx schrieb: > Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es > einigermaßen beherrscht? Hast du schon versucht, eine derart komplizierte Tätigkeit in einem Alter zu erlernen, in dem du bereits lesen konntest? Vielleicht geht es sogar leichter, wenn man es nicht kann. ;-)
rbx schrieb: > Wieviele Stunden muss man ein Tischtennisbuch lesen, um > statt in der Kreisklasse in der Verbandsliga zu spielen? Gar keines, da muß man nur üben bis der Arzt kommt. Und ja ein bissel Talent wird wohl auch dabei sein.
Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu verändern. Etwas vergleichbar mit dem Tastendruck R, nachdem man den vi mit -b gestartet hat. Ich konnte da in der Hilfe nichts finden…
rbx schrieb: > Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es > einigermaßen beherrscht? gar keins rbx schrieb: > Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um > statt in der Kreisklasse in der Verbandsliga zu spielen? vermutlich auch keines, man braucht nur viel Übung. Aber du willst doch die Bedienung eines Editors hoffentlich nicht als Selbstzweck sehen wie ein Sportler seine Sportart? rbx schrieb: > Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen, > wenn einem mal langweilig ist: > https://www.youtube.com/watch?v=KuLy5LzHEzU Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es mitlerweile einiges.
3.14 schrieb: > Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es > mitlerweile einiges. Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da oben? Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber ganz schön ein. Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv) auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht allzugroße Sorgen machen. Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff open:MINT) kann man doch noch verstehen oder?
Zeno schrieb: > Nano schrieb: >> Denn Notepad++ nutzt direkt >> die WinAPI und ist damit auch sehr schnell geladen. > Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile > bevorzuge ich da aber PSPad. Bei diesem kann man links eine > Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem > anderen Rechner verbinden und durch dessen Verzeichnisstruktur > navigieren. Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7 auf 10) von PSPad zu Notepad++ gewechselt. Der Grund war allerdings nur, weil ich Notepad++ mal ausprobieren wollte und das geht am besten, in dem man ihn installiert und die anderen Editoren nicht zur Verfügung hat. Also habe ich PSPad nicht installiert und Notepad++ ist jetzt halt drauf. Gefehlt hat bis jetzt nichts, anderseits mache ich meine Arbeitssachen überwiegend nur noch unter Linux, weswegen ich unter Windows kaum dazu komme, da einen Editor zu benötigen. Deswegen habe ich den da einfach drauf gelassen.
Norbert schrieb: > Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus > wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch > beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu > verändern. Keine Ahnung, aber ich habe das auch nie gebraucht und unter DOS, wo man das per EINF Taste einstellen konnte, hat mich so etwas immer gestört. Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.
Ich habe hier eine gerade mal 64MiB große Textdatei.
1 | ~/tmp$ l -h XXX |
2 | -rw------- 1 norbert norbert 64M Jul 3 20:02 XXX |
Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:
1 | PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command |
2 | 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi XXX |
Wenn ich die mit nano öffne, dann werden ca 5.1GiB Speicher benötigt:
1 | PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command |
2 | 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX |
Das ist grob der 14-15 fache Speicherplatz im RAM. Und der dreifache CPU Resourcen Verbrauch. Macht nano da etwas ganz Besonderes? Wie lautete die Eingangsfrage noch gleich…
Norbert schrieb: > Macht nano da etwas ganz Besonderes? Er ist bloss neuer, von 1999 statt 1991, und konnte sich das leisten.
(prx) A. K. schrieb: > Norbert schrieb: >> Macht nano da etwas ganz Besonderes? > > Er ist bloss neuer, von 1999 statt 1991, und konnte sich das leisten. Stimmt. Neuer is' besser. Sieht man doch… ;-)
Zum Bearbeiten von Dateien verwende ich echo und sed, wenn kein ed da ist.
Norbert schrieb: > Wie lautete die Eingangsfrage noch gleich… Die lautet: Openbsd schrieb: > Arbeitet von euch noch jemand mit dem vim? [...] > Wenn nein, warum nicht? Und die hat nano eigentlich gemäß der Fragestellung beantwortet, seitdem sieht er sich aber starken Missionierungstendenzen ausgesetzt. Und da er selber auch etwas schwierig ist, die Fanboys nicht ignorieren kann sondern das letzte Wort haben muss sind wir nun wieder in einer Diskussion angekommen die zusammen mit dem usenet eigentlich in der Versenkung hätte verschwinden sollen.
:
Bearbeitet durch User
Nano schrieb: > Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7 > auf 10) von PSPad zu Notepad++ gewechselt. Der Notepad++ ist schon klasse. Der bietet alles was man braucht. Gerade wenn man an großen Projekten arbeitet mit vielen Dateien und Verzeichnissen arbeitet hat das Teil schon seine Stärken, z.B. Suchen und Ersetzen in allen göffneten Dateien oder auch im gesamten Verzeichnis. Auskommentieren von Zeilen oder ganzen Bereichen passend zum geöffneten Dateityp funktioniert natürlich auch. Also ich nehme das Teil immer noch sehr gerne. Da ich derzeit an meinem Wetterserver und der zugehörigen Homepage arbeite kommt mir aber die FTP-Funktionalität des PSPad sehr gelegen. Der bietet zwar nicht die Vielfalt wie Notepad++, ist aber für meine aktuellen Arbeiten völlig ausreichend.
Le X. schrieb: > Norbert schrieb: >> Wie lautete die Eingangsfrage noch gleich… > Die lautet: > Openbsd schrieb: >> Arbeitet von euch noch jemand mit dem vim? [...] >> Wenn nein, warum nicht? Le.X: Warum lügst du so dreist? Und ja, eine Auslassung wesentlicher Teile kommt einer Lüge gleich! Hier die wahre Fragestellung: > Arbeitet von euch noch jemand mit dem vi? > Wenn ja, warum? Was sind die > ultimativen Vorzuege dieses Editors? > Wenn nein, warum nicht?
Da nano nicht mit vim arbeitet sind die von mir im Zitat mit [...] ersetzten Fragen nicht relevant, erst die letzte wieder. Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den Buckl runterrutschen, da musst dir 'nen andren suchen.
:
Bearbeitet durch User
Le X. schrieb: > Da nano nicht mit vim arbeitet sind die vob mir mit [...] > ersetzten > Fragen nicht relevant, erst die letzte wieder. > > Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den > Buckl runterrutschen, da musst dir 'nen andren suchen. Ich würde die Wahrheit jetzt nicht als Wortklauberei bezeichnen. Das mag für dich und deine ›gefühlte Wahrheit‹ natürlich durchaus so sein. So lebt halt ein jeder in seiner Welt.
So grob kann man den Vi und auch Vim mit der guten Bedienung vom Emu Emax2 vergleichen. Beim Emax2 wird man gewissermaßen mit leichter Gewalt dazu gezwungen, gleich von Anfang an Multisamples zu erstellen. Das hört sich furchtbar an, ist es aber nicht, weil man sonst Gefahr läuft, zu einer Art Samplefragment-Messi zu verkommen, und das behindert die Kreativität auch ganz schön, trotz der freien Zuordnung, die man aber später noch ausrichten muss. Beim Vi wie auch beim Vim wird man in ähnlicher Weise dazu gezwungen, eine "alte" aber bewährte Tastaturbedienung zu lernen. Das ist dann aber eher analog zum Minimoog. Und meinen konnte ich damals recht günstig bekommen, weil viele Leute irrtümlich dachten, das wäre der letzte Schrott von Gestern. Wer den Minimoog kennt, der weiß auch, dass das Improvisieren mit dem Ding einen Riesenspaß machen kann.
rbx schrieb: > Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da > oben? > Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens > einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber > ganz schön ein. > Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv) > auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht > allzugroße Sorgen machen. > > Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff > open:MINT) kann man doch noch verstehen oder? Sach mal was hast du denn geraucht? Argwohn gegen Unis? Nur weil ich gesagt habe, dass nur dort vi und LaTeX benutzt wird und eher nicht in der Industrie? Gehts noch? Und wo habe ich geschrieben, dass ich kein Englisch kann? Und wenns so wäre, ginge es dich auch nichts an. Und ja das Hörverstehen ist bei mir verbesserungswürdig und mit Prosa von Shakespeare tue ich mich auch etwas schwer. Wenn du unbedingt Streit suchst, bist du bei mir an der falschen Adresse. Da mache ich nicht mit und antworte dir Streithahn einfach nicht mehr. Hast wohl selber noch keine höhere Lehranstalt von innen gesehen, was?
3.14 schrieb: > Sach mal was hast du denn geraucht? Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich geschmacksbefreit allerdings, da fragt man sich, ob das früher zur Zichorienzeit (als Kaffeeersatz) auch schon so fade geschmeckt hatte. Und wenn wir schon dabei sind. Ich stehe nicht sonderlich auf Plattitüden, oder sich absichtlich sehr dumm stellen. Wenn man Pflanzen, Kräuter oder Blumen bestimmen oder besser, unterscheiden muss, hilft nicht immer ein Buch weiter, dafür aber die Nase. Auch dieses wurde uns abgewöhnt, obwohl es (das Erschnuppern) für die Menschen früher überlebenswichtig war, und oft auch schwierige Dinge ganz einfach macht.
rbx schrieb: > Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich > geschmacksbefreit allerdings, Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt nennt?
(prx) A. K. schrieb: > Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt > nennt? Und dann auch noch von einem bestimmten Unternehmen.. Tatsächlich hatte ich nicht viel erwartet. Aber Reformhäuser sind bei uns im Kreis alle weg, auch im größeren Bereich. Ich dachte schon daran, Hoffnung in eine etwas höhere Qualität zu setzen. Bevor ich mein Glück bei einer Apotheke versuche, könnte ich noch schauen, ob man bei uns in einer Supermarktecke mit Allnatura-Produkten noch etwas anständige(er)s erwischen kann. Aber die Geruchswelt von damals wird schon noch eine andere gewesen sein, teilweise wohl auch deswegen, weil die Leute auch oft hungern mussten, und soviel Fleisch wie heutzutage auch nicht auf den Tisch kam. Gibt es eigentlich in Wien in diesen Kaffeehäusern guten Zichorienkaffee? Bzw. gibt es die Kaffeehäuser überhaupt noch? Die kleine Kneipe gibt es bei uns schon lange nicht mehr. Und wo früher unser recht großer Dorfsupermarkt war, ist jetzt (in den alten Supermarkträumlichkeiten) ein großes Beerdigungsinstitut.
Walter K. schrieb: > Nano schrieb: >> … >> Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor. > > LOL Wieso LOL? Das ist nunmal die Aufgabe eines Hexeditors, der ist für Binärdateien da. Ein normaler Editor muss nur Text können, denn er heißt nunmal Texteditor und nicht Binäreditor. Falls du das bspw. nicht weißt, aber ein UTF-8 Zeichen kann bis zu 4 Bytes lang sein. In der Textansicht im Editor steht da also nur 1 solches Zeichen, das intern aber 4 Bytes groß ist. Im Hexeditor sieht man jedes der 4 Byte. Manche Texteditoren erlauben es auch in den Hexeditormodus umzuschalten, dann kannst du das auch auf Binärebene ändern, während die Daten dann in Hexansicht und daneben in normaler Zeichenansicht angezeigt werden. Das ist aber kein muss für einen Texteditor so etwas zu können.
Norbert schrieb:> > Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt: >
1 | PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ |
2 | > Command |
3 | > 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi |
4 | > XXX |
vi oder vim? 350 MiB sind für vi ziemlich viel, wenn man bedenkt, dass er aus einer Zeit stammt, als die Rechner weniger RAM hatten als die Disketten Speicherplatz boten. Da musste man also noch direkt auf Disketten operieren können, weil man längere Textdateien gar nicht ins RAM bekam. Hat sich das jetzt bei vi verschlechtert? Eine Rückentwicklung? Nano wurde später entwickelt, da hatte man schon üppig RAM zur Verfügung und dicke Bücher, wie bspw. die Bibel konnte man bereits komplett in das RAM laden. Da war bereits das direkte Arbeiten auf dem Datenträger keine Anforderung von Editoren mehr.
Nano schrieb: > Das > ist aber kein muss für einen Texteditor so etwas zu können. Trotzdem können das moderne Texteditoren - zumindest unter Windows.
Nano schrieb: > vi oder vim? vi ist bei debian ein symlink (über Umwege) auf vim. Also ja, es ist natürlich vim dahinter. Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend nicht mehr unter den Fingerkuppen. Selbst in Debian Hamm (die Älteren werden sich erinnern) war schon vim drin. Also, hmm, vi? Könnte Sinix oder Xenix oder SCO gewesen sein. Ganz sicher aber auf dem UNIX einer Perkin-Elmer. > 350 MiB sind für vi ziemlich viel, Ja, schon. Der Traditionelle hat sich immer nur ein Häppchen genommen. Aber der Punkt ist ein anderer: 5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp 80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung erklären. Oder einer massiv fehlerhaften Implementation. Der Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300% der Zeit braucht.
Norbert schrieb: > Aber der Punkt ist ein anderer: > 5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp > 80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das > lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung > erklären. Oder einer massiv fehlerhaften Implementation. Der > Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300% > der Zeit braucht. Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch auf eine 3,5 DD Diskette passen. Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im Arbeitsspeicher (Windows Taskmanager). Das Installationsprogramm von gvim verbraucht auch nicht unbedingt viel mehr Speicherplatz, so 10 MB. Vieviel Speicher der jetzt nach der Installation belegt, oder wieviel Arbeitsspeicher im Betrieb, kann ich nicht sagen, aber allzuviel mehr wird das auch nicht sein. https://www.vim.org/download.php Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich bei der "Recherche" schon ein wenig schmunzeln: https://superuser.com/questions/938093/nano-alternative-for-windows-powershell https://nano-editor.org/dist/win32-support/
Openbsd schrieb: > Wenn ja, warum? Weil neovim offensichtlich die Antwort auf die Frage nach dem Leben, dem Universum und dem ganzen Rest ist.
1 | :: Starting full system upgrade... |
2 | Packages (50) borg-1.2.1-1 [...] neovim-0.7.2-2 [...] |
3 | [...] |
4 | (42/50) upgrading neovim [##################################################] 100% |
5 | [...] |
Norbert schrieb: > Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend > nicht mehr unter den Fingerkuppen. Die gibt's auch kaum noch, weil der vi-Sourcecode lange Zeit nicht als Opensource verfügbar war. So haben die BSDs halt schon vor 30 Jahren auf nvi gesetzt, der sich zwar vom feature set weitgehend am Original orientiert (außer dass man im Insert-Mode mit den Cursortasten navigieren kann ;-) aber eben trotzdem ein Rewrite ist.
rbx schrieb: > Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der > Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch > auf eine 3,5 DD Diskette passen. > Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im > Arbeitsspeicher (Windows Taskmanager). Die Anzeigen bezüglich der RAM-Belegung: Da kann ich mit 100% Sicherheit einen Fehler ausschließen. Sowohl ›top‹ als auch ›htop‹ als auch die graphische Systemüberwachung sind sich da einig. Da gab's auch noch nie Probleme. Vielleicht war ich aber auch etwas unklar: Der nano belegt die zig-zig-zig-fache Menge an Speicher. Der vi verhält sich hingegen tadellos.
Norbert schrieb: > Ich habe hier eine gerade mal 64MiB große Textdatei. > ... > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi XXX > ... > 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX Das sieht schon heftig aus, allerdings kann ich das bei mir nicht ganz nachvollziehen:
1 | PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command |
2 | 8778 yalu 20 0 164M 98M 18648 S 0.0 1.7 0:00.23 vim big1 |
3 | 8183 yalu 20 0 151M 147M 3116 S 0.0 2.5 0:00.53 nano big1 |
Die Zahlenwerte sowohl für RES als auch für TIME sind also deutlich kleiner als bei dir. Der Speicherverbrauch hängt aber auch etwas vom Inhalt der Datei ab. Die Datei big1 enthält 1048576-mal die Zeile
1 | 012345678901234567890123456789012345678901234567890123456789012 |
jeweils mit einem LF am Ende, also 64 Byte/Zeile. Die Gesamtgröße der Datei ist damit wie bei dir 64 MiB. Welchen Inhalt hat bei dir die Datei XXX?
Yalu X. schrieb: > Welchen Inhalt hat bei dir die Datei XXX?
1 | head -c64M /dev/zero | tr "\000" "\n" >XXX |
Nochmal getestet, Werte bleiben etwa gleich.
Man kann dem ›nano‹ sogar in ›htop‹ beim Ackern zusehen. Diesmal hat er keine 7.3 Sekunden gebraucht, er war in 7.06 Sekunden fertig.
Ich verwende vim ganz gerne. Allerdings brauche ich nur ein kleines Subset der Features, das kann man in 15 Minuten lernen. Im Laufe der Zeit habe ich immer mehr Kürzel vergessen... Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features nicht gut funktionieren, wie finden der Funktionsdefinition oder debuggen. Auch gibt es keine einfache Projektverwaltung. Und schlimmer: man kann mit keiner IDE mehr arbeiten, wenn man die vim Kürzel erst mal gewohnt ist... Der vim ist aber auch ein Code-Monster mit schlechter Doku und mehr Sourcecode Zeilen als der Emacs und grauslicher Script Sprache. Dazu Bloat ohne Ende, aber OK - er funktioniert und stürzt nicht ab, die Windows Integration ist sehr bescheiden.
Norbert schrieb: > head -c64M /dev/zero | tr "\000" "\n" >XXX Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :) Nano scheint also in seiner internen Datenrepräsentation einen riesigen zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte bei Vim).
Norbert schrieb: > Der nano belegt die zig-zig-zig-fache Menge an Speicher. > Der vi verhält sich hingegen tadellos. Nicht nur das: den Vi oder gvim oder neovim usw. gibt es auch für Windows, reichlich problemlos. Der Watcom-Compiler hatte bei dem Übersetzungsversuch der Nano-Quellen trotz mehrerer Versuche und Ansätze mit zigfachen Fehlermeldungen abgebrochen. Da ist man wohl tatsächlich besser dran, wenn man erstmal ein minimales Cygwin (s.o.) für nano nutzt. (abgesehen davon, dass der VMware Player auch so ein tolles Programm ist) (Früher konnte man bei Cygwin eine Art Fullinstall machen, die maximale Menge war 4 GB. Aktuell gibt es bis zu 150 GB an Software, da muss man sich vor dem Installieren dann wohl auf Empfehlungen verlassen. Früher hatte ich nur den Compiler als Programm, das brauchte auch nicht viel Speicher, also eher vergleichbar mit dem, was heute typischerweise mit MinGW-Setups läuft.)
Yalu X. schrieb: > Norbert schrieb: >> head -c64M /dev/zero | tr "\000" "\n" >XXX > > Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :) > > Nano scheint also in seiner internen Datenrepräsentation einen riesigen > zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte > bei Vim). Und das da oben ist noch eine ›Spielzeugdatei‹ Hatte - blauäugig wie ich bin - mal eine unserer echten Messreihen mit ›nano‹ geöffnet. Die braucht normalerweise gerade mal 20 Sekunden zum öffnen. (Für 180E6 Zeilen, ~4GB) Konnte gerade noch schnell genug ein zweites Terminal aufmachen und bei ca. 20GiB RAM Nutzung ein freundliches kill -9 an den ›nano‹ senden. Noch bevor die wilde Swap-Orgie starten konnte. Wäre aber sicherlich gut für eine autoexec.bat oder config.sys zu gebrauchen… (Nee ich nehme das zurück, das war böse)
Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir im Büro für Java EE Anwendungen.
Stefan ⛄ F. schrieb: > Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir > im Büro > für Java EE Anwendungen. Möchte jemand anderes AHA sagen, oder soll ich das machen?
rbx schrieb: > Der vi verhält sich hingegen tadellos. Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen. Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM für eine Bildschirm-Seite braucht...
udok schrieb: > Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den > Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen. müsste man man schauen, was neovim diesbezüglich macht. Beim Watcom-Vi hatte ich eine ca 30 MB große Pdf Datei geladen - Speicherverbrauch des ganzen lag bei 32 MB. Wenn man allerdings eine Pdf im Reader läd, und dann auf den Taskmanager schaut, dann grabscht sich dieser Reader eine ganze Menge Speicherplatz selbst nach dem Beenden. Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als dieser grottige Dos-Editor Edlin. Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe übersehen müssen.
rbx schrieb: > Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich > bei der "Recherche" schon ein wenig schmunzeln: > > https://superuser.com/questions/938093/nano-alternative-for-windows-powershell Es gibt mehrere Möglichkeiten nano unter Windows zu installieren. Ich selbst installiere immer Git for Windows, da ist er dann neben der Bash und weiteren wichtigen Tools automatisch dabei und das wurde auch in deinem Link vorgeschlagen. https://gitforwindows.org/ Bei der Lösung über den Chocolatey package manager fehlte bei meiner letzten Recherche vor ein paar Jahren über Chocolatey noch das Vertrauen in die Pakete, weil es damals dort keinerlei Signierung gab. Keine Ahnung ob das inzwischen besser gelöst ist.
Es gibt unter Windows auch noch den WinVi, leider wird der nur sehr selten geupdated.
Norbert schrieb: > Yalu X. schrieb: >> Welchen Inhalt hat bei dir die Datei XXX? > >
1 | head -c64M /dev/zero | tr "\000" "\n" >XXX |
> > Nochmal getestet, Werte bleiben etwa gleich. Was du da produziert hast, ist vieles, aber keine Textdatei, wie du anfangs behauptet hast. Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles modifiziert, was kein Teil einer Textdatei ist. Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner. Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine Arbeit. Für Binärdateien nimm einen Hexeditor, wie ich es anfangs schon sagte.
udok schrieb: > Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features > nicht gut funktionieren, wie finden der Funktionsdefinition oder > debuggen. Auch gibt es keine einfache Projektverwaltung. Die Erfahrung habe ich auch gemacht, deswegen habe ich mich mit vim damals nicht mehr weiter beschäftigt und vim nach ca. 1 Woche Testzeit zu den Akten gelegt. Und für Configs brauch ich vim nicht, die sind so klein, da komme ich mit jedem Editor zurecht. Aber das sagte ich schon.
udok schrieb: > rbx schrieb: >> Der vi verhält sich hingegen tadellos. > > Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den > Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen. > > Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM > für eine Bildschirm-Seite braucht... 4 Byte pro Zeichen sprechen für eine interne Unicode UTF-32 Verarbeitung. Etwas anderes würde ich bei neuen Editoren nicht erwarten. Früher wären es UTF-16, also 2 Byte pro Zeichen gewesen. Was nano betrifft, hätte ich neben der ebenfalls UTF-32 Verarbeitung noch folgende Vermutung: Möglicherweise wird bei nano beim Laden eine Wörterbuchsuche mit Zeilennummern angelegt, das würde dann die Suche beschleunigen, aber auch die notwendige Datenmenge im RAM erhöhen. Also nichts weltbewegendes.
Nano schrieb: > Was du da produziert hast, ist vieles, aber keine Textdatei, wie du > anfangs behauptet hast.
1 | $ file XXX |
2 | XXX: ASCII text |
rbx schrieb: > Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus > bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als > dieser grottige Dos-Editor Edlin. EDLIN.COM wurde ab MS-DOS 5.0 ja durch EDIT.EXE ersetzt und DR DOS hatte schon von Anfang an mit EDITOR.EXE einen besseren Editor als EDLIN.COM im Programm. > Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf > die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe > übersehen müssen. Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen intuitiven Editoren auch bereits pico zur Verfügung. Und pico hat meistens gegen joe gewonnen, so war es auch bei mir. nano kam dann später und hat pico ersetzt. Und nano hatte keine lizenzrechtlichen Fragen mehr und war kurze Zeit später so beliebt, dass er in allen gängigen Distributionen vorinstalliert wurde.
Yalu X. schrieb: > Nano schrieb: >> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du >> anfangs behauptet hast. > $ file XXX > XXX: ASCII text Ich habe schon mal mit sort und uniq eine mehrere GB große Wörterliste sortiert und auf einen Eintrag pro Wort begrenzt, so sollte es sein, mit kleiner Datenmenge habe ich die Kommandos auch vorher entsprechend getestet, aber das Ergebnis war etwas ganz anderes. Entweder sort oder uniq haben sich herhaspelt, d.h. die Wörter kamen immer noch doppelt vor, und deswegen glaube ich nicht, dass eine pipe und tr die richtige Vorgehensweise ist um sehr große Binärdatei zu bearbeiten.
Nano schrieb: > Was du da produziert hast, ist vieles, aber keine Textdatei, wie du > anfangs behauptet hast. Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht. Gut, kann man ein bisschen als corner case ansehen. Statistik nach dem Laden der Datei (Ubuntu):
1 | VSZ RSS |
2 | vi: 350496 343320 |
3 | nano: 5252636 5246748 |
4 | Emacs (GUI): 790164 129796 |
5 | Emacs (TUI): 289072 100728 |
Emacs ist vorsichtig und fragt lieber erstmal nach, ob er so eine große Datei denn wirklich laden soll. ;-) Aber da dir die Daten ja nicht gefallen haben, probieren wir es mit einer Menge an 5stelligen Zufallszahlen:
1 | $ jot -r 11500000 10000 99999 > XXX |
2 | $ wc XXX |
3 | 11500000 11500000 69000000 XXX |
Sind jetzt ein paar MB mehr als vorher, aber nur noch 11,5 Millionen Zeilen.
1 | VSZ RSS |
2 | vi: 129808 122972 |
3 | nano: 908136 902160 |
4 | Emacs (GUI): 792220 131716 |
5 | Emacs (TUI): 290920 102700 |
Nano steht jetzt deutlich besser dar als im pathologischen Fall von nur Newlines, aber es fällt immer noch auf, dass er praktisch fast den gesamten allozierten VM einmal "anfasst", sodass er komplett auch als resident set im Speicher benutzt wird. vi(m) macht das auch, aber auf deutlich niedrigerem Niveau, bei Emacs ist eine große Differenz (viel mehr VM angefordert als tatsächlich erstmal benutzt). vi(m) gewinnt ebenfalls gegenüber dem pathologischen Fall, Emacs zeigt keine nennenswerten Unterschiede. [Edit: einige Aussagen korrigiert, die offensichtlich inkorrekt waren.]
:
Bearbeitet durch Moderator
Nano schrieb: > Was du da produziert hast, ist vieles, aber keine Textdatei, wie du > anfangs behauptet hast. Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte bedarf. > Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles > modifiziert, was kein Teil einer Textdatei ist. Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile. > Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner. Du meine Güte… ehrlich jetzt? > Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine > Arbeit. Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen absondern. Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich völlig überfordern. Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt). Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen, dann ist das kein Grund panisch zu reagieren. Das ist unser Tagesstandard. Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen dauert länger. Einen Glitsch in den Messdaten beseitigen, Fingerschnippen. Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch. Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei. Vielleicht noch ein kleiner Tipp: Nicht immer den eigenen Horizont als Maßstab für alles andere nehmen. Nur weil man selbst nur mit Dateien in Spielzeuggröße zu tun hat, bedeutet das nicht automatisch das alle anderen das auch tun. Ich verweise nochmal auf die ursprüngliche Frage und die Antwort lautet: Man nimmt den vi für Aufgaben denen kaum ein andere Editor gewachsen ist. Die bewältigt er mit Bravour. Und darum wird er auch nicht aussterben! Aus hoffentlich offensichtlichen Gründen kann ich hier keine Messdaten zur Verfügung stellen. Ein Upload einer 3.8GB TEXTDATEI würde vermutlich nicht gerne gesehen. Aber bau dir ruhig selber eine, genau so ist das Format: VORSICHT 3.8GB
1 | #!/usr/bin/python3
|
2 | import sys |
3 | import random |
4 | N = 4 * 3600 * 10000 # Vier Stunden lang, 100µs pro Messung |
5 | print(f'Zeilen:{N}') |
6 | offset_µs = 8_500_972_123 # µs Zeitstempel |
7 | with open('file.testfile', 'w') as fr: |
8 | for n in range(N): |
9 | fr.write(f'{offset_µs + n:12d} {random.randrange(0,4095):4d} {random.randrange(0,4095):4d} {random.randrange(0,4095):4d}\n') |
und sieh' selbst was nano alles nicht kann und was ein richtiger Editor problemlos kann.
Speichernutzung geht von ~7GB auf ~12GB Ladezeit: knapp 18 Sekunden die Eingabe von 100000000<Enter> springt zur 100 Millionsten Zeile in einem Wimpernschlag.
Jörg W. schrieb: > Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht. > Gut, kann man ein bisschen als corner case ansehen. Könnte man einzeln betrachtet so sehen, aber es dient auch nur dazu zu zeigen das nano enorme Probleme hat wenn es um richtige Arbeit geht. Die Probleme sind selbstverständlich auch in anderen großen Textdateien (mit mehr 0x20…0x7e) vorhanden.
Nano schrieb: > Es gibt mehrere Möglichkeiten nano unter Windows zu installieren. Die eigentlich einzig sinnvolle ist: Gar nicht. Gilt allerdings für vi unter Windows genauso. Oliver
Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut): Für jede Textzeile wird eine solche Struktur angelegt:
1 | typedef struct linestruct { |
2 | // Größe in Byte
|
3 | char *data; // 8 |
4 | ssize_t lineno; // 8 |
5 | struct linestruct *next; // 8 |
6 | struct linestruct *prev; // 8 |
7 | short *multidata; // 8 |
8 | bool has_anchor; // 4 |
9 | } linestruct; |
Gesamtgröße inkl. Padding: 48 Byte Dazu kommt der Malloc-Chunk, auf den data zeigt. In 64-Bit-Linux ist die minimale Chunk-Größe 32 Byte. Auch für Leerzeilen, die außer dem LF keine weiteren Zeichen enthalten, werden diese 32 Byte benötigt. Eine Leerzeile belegt also 48 + 32 =qa80 Byte. Entsprechend belegen die 64 Mi Zeilen der Datei XXX 80 · 64 MiB = 5120 MiB. Norbert schrieb: > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command > 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX Das passt also sehr gut. Die verbleibende 3 MiB in RES werden vom Programmcode und weiteren Daten belegt. Andere Editoren wie bspw. Vim und erst recht Emacs gehen weit weniger verschwenderisch mit dem Speicher um, wie man an den Testergebnissen von Norbert und Jörg sehen kann.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Hier ist die Erklärung, Wow, du gibst dir ja richtig Mühe. Alle Achtung! Mit Emacs hab ich das nie probiert. Die beiden Parteien (vi, Emacs) haben sich ja früher immer gegenseitig angefrozzelt. ;-) Könnte mir aber gut vorstellen das der auch keine Probleme hätte. Gut abgehangene Software eben (beide ;-) ).
rbx schrieb: > (Früher konnte man bei Cygwin Heute kann man unter Windows das WSL2 installieren und damit direkt originale Ubuntu-Pakete installieren und nutzen. Kein Bedarf mehr für Cygwin und Co.
Stefan ⛄ F. schrieb: > Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir im Büro > für Java EE Anwendungen. Hm, merkwürdig... In anderen Sprachen kenne ich eine Menge Profis, die "einfache" Editoren wie Atom, Sublime, vi(m), Emacs, UltraEdit, Notepad++, Kate, Programmer's Notepad und Ähnliche benutzen. Nur unter Java scheinen alle auf irgendeine IDE zu setzen, woran liegt das? Hat dazu jemand -- im Gegensatz zu mir -- eine Idee?
Norbert schrieb: > Man muss halt Werkzeuge für Erwachsene nehmen Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer. Das wirkt nur überheblich. Norbert schrieb: > Mit Emacs hab ich das nie probiert. Er lädt das auch einigermaßen schnell (beide brauchen so um die 9 Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen. Aber zum anderen Ende der Datei zu navigieren, dauert bei Emacs eine gefühlte Ewigkeit, während es bei vi(m) ratz-batz geht.
Jörg W. schrieb: > Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer. > Das wirkt nur überheblich. Ja, das war wohl die Reaktion auf das grausame und völlig faktenlose Geschreibsel das sich zuvor in meine Netzhaut brannte. Normalerweise versuche ich das zu vermeiden, aber manchmal geht's halt nicht… Grundsätzlich gebe ich dir aber Recht.
Jörg W. schrieb: >
1 | > VSZ RSS |
2 | > nano: 5252636 5246748 |
3 | > Emacs (GUI): 790164 129796 |
4 | > |
> >
1 | > VSZ RSS |
2 | > nano: 908136 902160 |
3 | > Emacs (GUI): 792220 131716 |
4 | > |
Interessant: sogar die grafische Version des Emacs genehmigt sich in beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano. Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal sagen...
Jörg W. schrieb: > Er lädt das auch einigermaßen schnell (beide brauchen so um die 9 > Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen. Ach, solange es ohne swappen in den Speicher passt, dafür isser ja da.
Ein T. schrieb: > Interessant: sogar die grafische Version des Emacs genehmigt sich in > beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano. > Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen > des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal > sagen... In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt wohl auf ewig ein Rätsel. Glücklicherweise installiert man ein Debian System meistens nur einmal und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich. Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-)
Ein T. schrieb: > Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen > des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal > sagen... Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal "leichter verdaulich" als ein vi. Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie einen vi dann doch auf Dauer bevorzugen.
Norbert schrieb: > Nano schrieb: >> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du >> anfangs behauptet hast. > > Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte > bedarf. Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern enthält ist KEINE Textdatei und da kannst du so viel auf dem Boden herumstampfen wie du willst, daran wird sich nichts ändern. Dein Beispiel mit lauter Newline Zeichen, also Zeichen, die lediglich dem Editor sagen, dass eine neue Zeile beginnt ist kein Text und somit ist das auch keine Textdatei. Labere also jemanden anderen voll mit deinem Blödsinn! > Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten > prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile. Und dann noch mehr Zeit mit deinem Blödsinn verschenken? Nein danke! Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten und wenn dein \000 Code nicht durch ein Newline ersetzt wird, dann hast du am Ende eine ziemlich miese Eingabe in den Editor, insbesondere die Abwesenheit von Text. > Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du > verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen > absondern. Das hat Yalu X. hier schon getan: Beitrag "Re: Vi Editor ausgestorben?" Und da macht nano alles im üblichen Rahmen. Auf UTF-32 und ein Wörterbuchdictionary zwecks schnellerer Suche habe ich bereits verwiesen und ja, so etwas darf ein Editor machen ohne das man ihm das negativ ankreiden darf, wie du es hier machst. > Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen > Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich > völlig überfordern. Eine Datei aus Newlinezeichen ist keine Textdatei, siehe oben. Und wenn du solche große Dateien hast und sie mit einem Texteditor anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine weitere Datenverarbeitung aufbereitest. Die Bearbeitung von GB Weise Daten gehört nämlich ganz gewiss nicht in das Aufgabenspekturms eines Texteditors, der zum Bearbeiten von Configdateien, Programmiersprachencode, Skriptcode oder HMTL Text da ist. > Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt > mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor > er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt). Dann beschwer dich bei den Entwicklern von nano was denen einfällt, den nano zum Bearbeiten von Configdateien und Programmiersprachencode zu entwickeln und deinen Anwendungsfall aus lauter Newlinezeichen zu vergessen. Hörst du dir eigentlich mal selbst beim Reden zu? > Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für > Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro > Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen, > dann ist das kein Grund panisch zu reagieren. Das ist unser > Tagesstandard. Dann schreibt man dafür aber auch ein entsprechendes Programm, dass die Daten entsprechend aufbereitet und verarbeitet und frickelt darin nicht händisch mit einem Texteditor herum der nie für solche Datenmengen entwickelt wurde. Und dann noch etwas, wenn ich so große Datenmengen zu verarbeiten hätte, dann würde ich mir an deiner Stelle mal Gedanken über Binärdateien machen. Die können Computer nämlich weitaus besser verarbeiten und ja, für die nimmst du dann das entsprechend dafür geschrieben Programm zum aufbereiten, was du aber ohnehin brauchst, siehe oben. > Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen > dauert länger. Einen Glitsch in den Messdaten beseitigen, > Fingerschnippen. Ein Mensch der Endanwender ist und in Messdaten gucken will, möchte in der Regel einen Messzeitpunkt oder Messzeitbereich angeben, da springt er ganz gewiss nicht in Zeilen herum, sondern erwartet ein Programm bzw. eine Oberfläche, in das er einen Zeitpunkt oder Zeitpunktbereich eingeben kann und dann bereitet ihm eine entsprechend programmiertes Programm das auf und zeigt es auf einer Oberfläche an und gibt die Daten da aus. Nix da mit Zeilennummer eingeben. Verlange doch gleich, dass er mit dem Debugger Addresszeilen im RAM eingeben soll um sein Messdaten zu finden. Und auf so viel Gestümper bist du auch noch stolz und schwärmst darüber, dass vim damit klar kommt? Lachhaft! > Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch. > Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei. Dann würdest du das umsetzen, was ich hier dir gerade geschrieben habe und nicht vom Kunden erwarten, dass er mit VIM in deinen Messdaten herumwühlen soll. > und sieh' selbst was nano alles nicht kann und was ein richtiger Editor > problemlos kann. Nano ist ein richtiger Editor. Er ist zum Bearbeiten von Textdateien, Skripten, Programmcode und Konfigurationsdateien da und das kann er.
Yalu X. schrieb: > Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich > viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut): > > Für jede Textzeile wird eine solche Struktur angelegt: > >
1 | > typedef struct linestruct { |
2 | > // Größe in Byte |
3 | > char *data; // 8 |
4 | > ssize_t lineno; // 8 |
5 | > struct linestruct *next; // 8 |
6 | > struct linestruct *prev; // 8 |
7 | > short *multidata; // 8 |
8 | > bool has_anchor; // 4 |
9 | > } linestruct; |
10 | >
|
> > Gesamtgröße inkl. Padding: 48 Byte Danke und so etwas darf ein Texteditor, der zum Editieren von Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist, auch. Also kein Fehler des Programms. Wenn Norbert anderes erwartet, dann ist das Problem vor dem Bildschirm.
Übrigens für die nicht Programmierer hier. So ein struct das als Liste benutzt wird beschleunigt das Tauschen, Einfügen und Entfernen von Zeilen erheblich, also eine Hauptaufgabe von Editoren und da es algorithmisch eine Liste mit Zeiger zum vorherigem und nächstem Listenelement ist, darf diese Liste beliebig lange werden, solange der Rechner genug RAM an. Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist, sondern er seinem Rechner zu wenig RAM verpasst hat. Und ja, wenn man andere Anforderungen hat, dann kann man als Entwickler einer Anwendung die Daten speichertechnisch auch anders organisieren, z.B. die Zeilen zu Blöcken zusammenfassen und mit Blöcken arbeiten, das bedeutet dann beim Entfernen und Einfügen von Zeilen dann aber erheblich mehr Aufwand und reorganisation der Daten.
Nano schrieb: > Danke und so etwas darf ein Texteditor, der zum Editieren von > Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist, > auch. Ist er denn als solcher irgendwo deklariert?
1 | DESCRIPTION |
2 | nano is a small and friendly editor. … |
Das ist das einzige Auftreten des Worts "small" in der ganzen man page. Also es steht zumindest nicht da, dass er nur für "small files" da sei … > Also kein Fehler des Programms. Aber zumindest ungeschickt programmiert. Nano schrieb: > Und wenn du solche große Dateien hast und sie mit einem Texteditor > anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine > weitere Datenverarbeitung aufbereitest. Wer legt das fest? Du? In aller Regel muss man in der Praxis einfach mal mit dem leben, was einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor. Nano schrieb: > Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist, > sondern er seinem Rechner zu wenig RAM verpasst hat. Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch dem Nano zur Verfügung steht.
:
Bearbeitet durch Moderator
Norbert schrieb: > Glücklicherweise installiert man ein Debian System meistens nur einmal > und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich. So ist das mit einem vi(m) oder Emacs ja auch: die Konfigurationsdatei meines Emacs ist zum größten Teil schon über zwanzig Jahre alt, in den letzten Jahren sind da nur ein paar ELPA-Pakete für Dockerfiles und Kubernetes-Deployments hinzu gekommen. Das ist auch so eine schöne Eigenschaft von alter, gut abgehangener Software -- wenn ich sehe, wie viel Aufwand die Kollegen bisweilen betreiben müssen, um ihre IDEs wieder lauffähig zu machen, wenn sie die aktualisiert haben oder auf einen neuen Computer gewechselt sind, finde ich das schon ein bisschen erschreckend. > Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere > ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-) ;-)
Nano schrieb leider schon wieder im Beitrag #7117082: > eine Menge Gequirltes… Und er erklärt schon wieder was andere machen sei falsch. Ohne auch nur den geringsten Schimmer einer Ahnung zu haben… Jörg W. schrieb: > Ohne … Tja Jörg, schau es dir an und erkläre wie man mit Menschen umgehen soll die sich ihre eigene Realität schaffen. ;-) Ignorieren? Ja, das ist ein Plan!
Norbert schrieb: > Ein T. schrieb: >> Interessant: sogar die grafische Version des Emacs genehmigt sich in >> beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano. >> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen >> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal >> sagen... > > In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt > wohl auf ewig ein Rätsel. Für jemand der programmieren kann und Informatikvorlesungen, insbesondere die Fächer Algorithmen und Datenstrukturen besucht hat ist das Verwalten von Daten als Liste kein Rätsel, sondern je nach Aufgabenstellung eine sinnvolle Lösung der Aufgabenstellung. In deinem Fall tippe ich also mal auf Umschuler, der in das Programmieren von Python so nebenbei reingerutscht ist. Kein Wunder, dass du Gigabyteweise Messdaten als Textdaten ablegen willst, anstatt dir Gedanken über ein effizientes Binärformat zu machen. Und ja, wenn man das nicht kann, dann ist es natürlich verständlich, dass man seine Rettung in vim sucht.
Jörg W. schrieb: > Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die > meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei > bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal > "leichter verdaulich" als ein vi. Keine Frage, der nano ist "zugänglicher" für Einsteiger. Das erklärt aber nicht, warum man den guten alten vim eines Teils seiner gewohnten Funktionalität berauben mußte und dies nicht einmal deutlich kenntlich gemacht hat. Das verwirrt dann die erfahrenen vim-Nutzer, die sich natürlich darauf verlassen, daß dieser Editor auch unter Debian funktioniert wie gewohnt. Ähnliches gilt für die Nummer mit der dash. Da wird der Wechsel auf Debian für Einsteiger erleichtert und für erfahrene Nutzer erschwert, und das bei einer Distribution, die sich laut Aussagen von Mitgliedern dieses Projekts vornehmlich an erfahrene Benutzer richtet. Äh? > Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz > gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie > einen vi dann doch auf Dauer bevorzugen. Definitiv, ja.
Leute, bitte tauscht eure Kindergarten-Anschuldigungen ("Umschuler"
(sic), "Werkzeuge für Erwachsene", "Gestümper") künftig per Email aus.
Das Forum braucht sowas nicht.
Ein T. schrieb: > Das erklärt aber nicht, warum man den guten alten vim eines Teils seiner > gewohnten Funktionalität berauben mußte und dies nicht einmal deutlich > kenntlich gemacht hat. Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht erwarten sollte, dass sie eine Bash ist.)
Nano schrieb: > Danke und so etwas darf ein Texteditor, der zum Editieren von > Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist, > auch. > > Also kein Fehler des Programms. Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler.
Nano schrieb: > Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist, > sondern er seinem Rechner zu wenig RAM verpasst hat. Das sagt Microsoft bei jeder neuen Windows-Version auch ;-)
Yalu X. schrieb: > Nano schrieb: >> sondern er seinem Rechner zu wenig RAM verpasst hat. > > Das sagt Microsoft bei jeder neuen Windows-Version auch ;-) Und diverse Dealer voin Placebo und sonstiger Betrugssoftware wie seineszeiten "SoftRAM" "Trotzdem ist der SoftRAM-Treiber mit 54 724 Bytes viel größer als das Original DynaPage.VxD. Beim näheren Anschauen trauten wir unseren Augen kaum: Er enthält 41 820 Nullen! Nur rund 12,6 KByte werden überhaupt genutzt, das Original belegt dagegen rund 8 KByte." aus https://www.heise.de/ct/artikel/Placebo-forte-284374.html
Nano schrieb: > Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern > enthält ist KEINE Textdatei Also bist Du jetzt hier der Chef und bestimmst über "richtige" Dateitypen und -Inhalte, und die Aufgaben, die andere mit ihren Werkzeugen bearbeiten dürfen? > Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier > verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei, zuverlässig, performant, stabil und absolut reproduzierbar funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei Dir angeblich Probleme gemacht haben sollen -- obwohl Dein Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler gemacht hast.
Jörg W. schrieb: > Nano schrieb: >> Also kein Fehler des Programms. > > Aber zumindest ungeschickt programmiert. Wenn man normale Datenmengen <= 1 MiB erwartet und die Hauptaufgabe das Einfügen, Entfernen, Tauschen und Hinzufügen von Zeilen ist, dann ist eine verkettete Liste mit Listenattributen für ein vorheriges und nächstes Listenelement als Datenstruktur völlig ausreichend und ungeschickt programmiert kann man hier auch nicht sagen, weil es für kleine Datenmengen sogar die bessere, da einfacher zu handhabende, Datenstruktur ist und große Messdatenreihen ganz gewiss nicht eine der Anforderungen war, als der Editor von den Programmierern programmiert wurde. Würdest du dagegen die Zeilen zu bspw. Zeilenblöcken verarbeiten, die insgesamt bspw. 64 KiB fassen können, dann müsstest du beim Einfügen in der Mitte von so einem vollen Block eine neuen Block, der dann gleich 64 LIb belegt anlegen und im Worst Case Fall, falls du das dann nicht noch komplizierter verwaltest, alle Zeilen, die ab der Hälfte des Blocks folgen nach unten schieben, so dass die unterste Zeile dann im nächsten Block landet. Für lahme Rechner ist das ein erheblicher Aufwand. In nano müssten stattdessen dazu nur zwei Adresszeiger vertauscht werden, fertig. Die Struct Liste ist somit sehr effizient, wesentlich effizienter als so eine Blockdatenstruktur. Und ja, natürlich braucht man für die extra Zeiger dann mehr Platz. Kein Vorteil ist umsonst. Wenn Norbert hier dann sagt, dass nano nicht gescheit programmiert wäre und Spielzeug sei, dann bedeutet das nichts anderes, als das er keine Ahnung von Datenstrukturen hat. > Nano schrieb: >> Und wenn du solche große Dateien hast und sie mit einem Texteditor >> anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine >> weitere Datenverarbeitung aufbereitest. > > Wer legt das fest? Du? Das man sich über eine sinnvolle Datenstruktur bei gegebener Aufgabenstellung Gedanken machen sollte, lernt man im Info Studium. > In aller Regel muss man in der Praxis einfach mal mit dem leben, was > einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor. Das ist leider wahr. All zu oft wird dann von den falschen Leuten ohne entsprechende Qualifikation eine Simple Quick & Dirty, aber Hauptsache billig Lösung hingeschludert und das ist dann das Ergebnis, was man hier bei Norbert sehen kann. > Nano schrieb: >> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist, >> sondern er seinem Rechner zu wenig RAM verpasst hat. > > Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so > einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch > dem Nano zur Verfügung steht. Die Liste kann prinzipiell beliebig lang anwachsen, es braucht also nur mehr RAM. Das Einlesen und Anlegen der Datenstruktur kostet natürlich anfangst etwas mehr Zeit, aber wenn sie dann im RAM liegt, dann geht das Einfügen oder Löschen von neuen Zeilen sehr effizient. Lass mal 10000000 neue Zeilen in so eine 64 MiB Datei automatisiert von nano und dann einmal von vim auf einem Rechner ohne Cache einfügen. Ich würde dann mal stark schätzen, dass nano deutlich schneller fertig sein wird.
Jörg W. schrieb: > Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn > auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist > es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht > erwarten sollte, dass sie eine Bash ist.) Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.
Nano schrieb: > Ich würde dann mal stark schätzen, dass nano deutlich schneller fertig > sein wird. Ich denke, einen Kasten Bier solltest du darauf lieber nicht verwetten. ;-)
Nanolator schrieb: > Nano schrieb: >> Danke und so etwas darf ein Texteditor, der zum Editieren von >> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist, >> auch. >> >> Also kein Fehler des Programms. > > Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler. Listenstrukturen sind beim Einfügen (insbesondere überall da, wo nicht das Datenende ist) und Löschen besonders effizient und daher sinnvoll. Daher ist das definitiv keine Verschwendung und schon gar nicht ist sie unbegründet. Siehe dazu nochmal mein vorheriges Kommentar.
Jörg W. schrieb: > Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn > auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist > es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht > erwarten sollte, dass sie eine Bash ist.) Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt das Folgende aus:
1 | ~ VIM - Vi IMproved |
2 | ~ |
3 | ~ version 8.1.3741 |
4 | ~ by Bram Moolenaar et al. |
5 | ~ Modified by team+vim@tracker.debian.org |
6 | ~ Vim is open source and freely distributable |
7 | ~ |
8 | ~ Help poor children in Uganda! |
9 | ~ type :help iccf<Enter> for information |
10 | ~ |
11 | ~ type :q<Enter> to exit |
12 | ~ type :help<Enter> or <F1> for on-line help |
13 | ~ type :help version8<Enter> for version info |
14 | ~ |
15 | ~ Running in Vi compatible mode |
16 | ~ type :set nocp<Enter> for Vim defaults |
17 | ~ type :help cp-default<Enter> for info on this |
Ein T. schrieb: > Ein Aufruf von "vi" hingegen gibt das Folgende aus: Hmm, das ist dann schon bissel irreführend.
Ein T. schrieb: > Nano schrieb: >> Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier >> verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten > > Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei > mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei, > zuverlässig, performant, stabil und absolut reproduzierbar > funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei > Dir angeblich Probleme gemacht haben sollen -- obwohl Dein > Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler > gemacht hast. Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es memtest86+?) überprüft. Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch die doppelten Einträge alle entfernen willst und das ganze noch durch eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche Datenmengen nie erwartet wurden. Um herauszufinden, was da genau das Problem war, müsste man sich natürlich den Code von sort und uniq, sowie der Shell ansehen. Ich habe mir dann was eigenes programmiert und mir so anders geholfen um eine richtige sortierte Liste mit einzigartigen Einträgen zu erhalten. Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen und das ganze dann wieder zu einer großen mehrere GB großen Datei zusammenfügen und dann anschließend sort und uniq darauf loslassen. Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein, wenn sort und uniq alles richtig machen.
Jörg W. schrieb: > Hmm, das ist dann schon bissel irreführend. Der relevante Hinweis ist auch leicht zu übersehen: Ein T. schrieb: > ~ Running in Vi compatible mode
Norbert schrieb: > Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens > 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe. Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen, daß die meisten funktionieren und manche wieder nicht. Ich kann mir nur wenige bessere Möglichkeiten vorstellen, um Verwirrung zu stiften.
Nano schrieb: > Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch > die doppelten Einträge alle entfernen willst und das ganze noch durch > eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und > die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche > Datenmengen nie erwartet wurden. Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas falsch gemacht hast.
Also was vim.tiny betrifft. Ja, da stimme ich zu. Da hätte man bei Programmstart schon als Titel angeben können, dass es sich hier um vim.tiny handelt und nicht um VIM - Vi IMproved , wie es bei vim.tiny ebenfalls im Titel steht. Wer will, der kann ja mal einen Bugreport an das Debianprojekt schreiben. https://www.debian.org/Bugs/Reporting Der einzige Unterschied, der am Splashscreen erkennbar ist, ist lediglich, dass die Vollversion von vim einen deutschen Text hat, sofern das System auf DE eingestellt ist, während die tiny Version englisch bleibt.
nano, ich finde du hast die Eingangsfrage, ob und wieso du nicht vim nutzt gut und (für dich) richtig beantwortet. Auf der Konsole, zum Editieren von Config-Files, reicht dir der nano und für größeres Zeugs hast du deine IDE. Soweit OK. Jetzt lockst du natürlich die übliche Meute an die dir zeigen will dass ihr Spielzeug viel toller ist (mir unverständlich was diesen Reflex auslöst). Und dein Problem dabei: die haben recht. Objektiv betrachtet kann der vim mehr als der nano, und wie man sieht sogar mit geringerem Ressourceneinsatz. Dein Fehler ist, dich aufgrund der Schilderung von Usecases, die für dich ja eh nicht relevant sind, zu einer Diskussion hinreißen zu lassen. Du musst keine Binärdateien ändern. Du musst keine 4Gb++ großen Textdateien ändern. Fancy find&replace-Orgien brauchst du auch nicht bzw. falls doch kriegst du sie anders abgebildet. Dann sag das doch einfach. Sag dass dein Anspruch an deinen CLI-Editor ist, Config-Dateien zu bearbeiten, und fertig. Das Problem ist, du versuchst diese Beispiele zu kontern, und das kann nur daneben gehen. Denn jetzt hast du nicht mehr die Frage "Nutzt du vim? [...] Wieso nicht?" sondern du hast die Diskussion "nano vs. vim" an der Backe und da siehst du kein Land. Ich stelle fest, du blamierst dich hier - ohne Not - bis auf die Knochen und die streitlustigen Subjekte dürfen heute mit der grimmigen Befriedigung ins Bett gehen, jemanden im Netz mal so richtig verdroschen zu haben.
:
Bearbeitet durch User
Mombert H. schrieb: > Nano schrieb: >> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch >> die doppelten Einträge alle entfernen willst und das ganze noch durch >> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und >> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche >> Datenmengen nie erwartet wurden. > > Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden > die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas > falsch gemacht hast. Du darfst natürlich gerne glauben, dass lang bewährte Software keine Bugs hat. Beim Finden der Heartbleed Lücke hat das allerdings ein paar Jahre gedauert, insofern kann das halt doch vorkommen.
Ein T. schrieb: > Norbert schrieb: >> Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens >> 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe. > > Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität > gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche > Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre > gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen, > daß die meisten funktionieren und manche wieder nicht. Ja, in der Tat. Mir fiel das immer unangenehm auf wenn ich meine .vimrc auf ein anderes System transferiert und dann den vi (nicht vim) gestartet hatte. Error detected while processing .vimrc: E319: Sorry, the command is not available in this version: > Ich kann mir nur wenige bessere Möglichkeiten vorstellen, > um Verwirrung zu stiften. Ach, da geht noch was… ;-)
Nano schrieb: > Du darfst natürlich gerne glauben, dass lang bewährte Software keine > Bugs hat. Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine Folge von fehlerhafter Anwendung waren.
Nano schrieb: > Ein T. schrieb: >> Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei >> mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei, >> zuverlässig, performant, stabil und absolut reproduzierbar >> funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei >> Dir angeblich Probleme gemacht haben sollen -- obwohl Dein >> Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler >> gemacht hast. > > Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es > memtest86+?) überprüft. Hm. > Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch > die doppelten Einträge alle entfernen willst und das ganze noch durch > eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und > die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche > Datenmengen nie erwartet wurden. Merkwürdig, solche Dinge mache ich seit vielen Jahren sehr regelmäßig und kann mich nicht daran erinnern, jemals ein Problem dabei gehabt zu haben. Übrigens benutze ich UNIX-Pipes auch oft mit Binärdaten, ohne daß es Probleme gäbe -- einer meiner häufig genutzten Befehle ist es, die Ausgabe von tar(1) auf pigz(1) zu pipen, denn parallel komprimieren geht natürlich viel schneller. > Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen > und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen > und das ganze dann wieder zu einer großen mehrere GB großen Datei > zusammenfügen und dann anschließend sort und uniq darauf loslassen. > Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein, > wenn sort und uniq alles richtig machen. Ich habe keinerlei Zweifel daran, daß das völlig problemlos funktionieren wird, wenn ich das mache, schließlich hat das ja auch in den letzten Jahren auch immer absolut problemlos funktioniert -- auch mit Dateien von mehreren Terabyte Größe, aber dann natürlich auf unseren fetten Eisen. Mittlerweile benutze ich für sowas nur deshalb unseren Spark-Cluster, weil das parallelisiert natürlich viel schneller geht. Aber mit kleinen Dateien von ein paar Gigabyte geht das natürlich auch lokal. Ich frage morgen aber mal meine Kollegen, ob denen etwas aufgefallen ist.
Ist schon ziemlich verwirrend, zumindest bei Linux Mint (und wahrscheinlich auch noch bei vielen anderen, die von Debian abstammen) Ruft man vim auf, so wird nichts gefunden. Ruft man vi auf, so meldet sich vim, obwohl es sich in Wirklichkeit um vim.tiny handelt. Will man vim benutzen, muss man es extra installieren. Das muss man auch erst mal verstehen.
Norbert schrieb: > Ein T. schrieb: >> Ich kann mir nur wenige bessere Möglichkeiten vorstellen, >> um Verwirrung zu stiften. > > Ach, da geht noch was… ;-) Bitte weck' jetzt keine schlafenden Geister den Debian-Leuten, ja? ;-)
Nano schrieb: > Es gibt mehrere Möglichkeiten nano unter Windows zu installieren. Eigentlich nur sinnvoll als Teil eines anderen Softwarepaketes. Nano schrieb: > Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen > intuitiven Editoren auch bereits pico zur Verfügung. > Und pico hat meistens gegen joe gewonnen, so war es auch bei mir. Es hat sich in der Zwischenzeit einiges getan..aber als eigenständiges Konsoleprogramm habe ich joe und seine Zwillingsbrüder noch nicht zum laufen bekommen. Entweder funktioniert der Download nicht, oder aber muss sich nochmal die Konfigurierhinweise genauer ansehen. Also Nix Plug and Play. Etwas Nano-Soziologie..: https://news.ycombinator.com/item?id=11953229 ( die Frage lautet: don't want to sound nasty , but is anyone there using nano really ? i know it come by default in some distros but that's about it really. ) Die Antworten sind recht lesenswert. Ein T. schrieb: > Heute kann man unter Windows das WSL2 installieren Noch einer, der noch Bedarf nach einem Aha hat? Ein T. schrieb: > Kein Bedarf mehr für > Cygwin und Co. So sehe ich das nicht. WSL ist eine Alternative neben anderen, teilweise auch viel besser zugeschnittenen Angeboten. Grundsätzlich aber keine schlechte. Mein Problem ist z.B. ich habe gar kein Windows 10 oder Windows 11. Und ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht vernüftig auf Linux spielen kann. (Und Dualboot brauche ich auch nicht) Hier noch ein Link auf die Suche in etwa "große Dateien editieren" https://askubuntu.com/questions/28847/text-editor-to-edit-large-4-3-gb-plain-text-file
rbx schrieb: > Und > ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht > vernüftig auf Linux spielen kann. Zumindest dafür gibts Abhilfe ;-) https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition Läuft bei mir unter Arch Linux nativ und problemlos. (Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag für Puristen evtl. nicht duldsam sein)
Mombert H. schrieb: > Nano schrieb: >> Du darfst natürlich gerne glauben, dass lang bewährte Software keine >> Bugs hat. > > Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software > sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine > Folge von fehlerhafter Anwendung waren. Du liest einfach nicht, was ich oben geschrieben habe. Ich erwähnte, dass ich damals den CLI Befehl mit sort und uniq mit kleiner Datenmenge auf Funktionsrichtigkeit überprüft habe. D.h. der CLI Befehl und die angegebenen Parameter waren korrekt und das Ergebnis richtig. Eine fehlerhafte Anwendung der CLI Tools würde bedeuten, dass das hier hätte spätestens auffallen müssen. Zumal du dich auch fragen solltest, wie viel man überhaupt bei sort und uniq bei der Parameterangabe falsch machen kann und ob dann überhaupt noch die Wahrscheinlichkeit einer fehlerhaften Anwendung durch den Nutzer ausreichend groß ist. Aber wie dem auch sei, glaub halt was du willst. Ich weiß, was ich beobachten konnte und die Wörter waren am Ende nach sort und uniq eben nicht einzigartig, sondern kamen mehrmals in der Datei vor, wie grep zeigte.. Du kannst jetzt gerne, wenn du möchtest, prüfen, ob sort oder uniq vielleicht mit irgendwelchen Puffergrößen arbeitet und dann bei Überschreitung von diesem nur noch auf die kleinere Puffergröße entsprechend sortiert bzw. auf einzigartige Elemente reduziert, das würde dann nämlich das Ergebnis erklären. Bedenke nämlich bitte, wenn du eine bspw. 20 GiB große Datei hast, dann muss die Zeile, die bspw. mit A beginnt und sich gerade ganz am Ende der Datei befindet, nach ganz vorne sortiert werden. Wenn du die 20 GiB nicht auf einmal in das RAM bekommst, dann reicht ein einfaches Array auf das man einen Sortieralgo anwendet nicht, sondern dann musst du dir einen entsprechenden Algorithmus ausdenken der das berücksichtigt. Gleiches gilt für das finden der uniq Elemente. Und es ist durchaus möglich, dass ein Programm, abhängig von der Datenmenge und dem verfügbaren RAM unterschiedliche Algorithmen anwendet, weil der Algo, der mit kleinen Daten, die komplett ins RAM passen vielleicht schneller ist, als der andere, der auch das Zwischenauslagern auf Festplatte berücksichtigt und den Umgang mit großen Datenmengen erlaubt. Das Resultat davon ist, dass du im gleichen Programm unterschiedlich gut getestete Algorithmen haben kannst Das ganze dürfte jetzt schon über 10 Jahre her sein. Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war zu groß und ich musste die Festplatte mitverwenden.
Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück überzeugt und springe gleich ans Ende: Nano schrieb: > Das ganze dürfte jetzt schon über 10 Jahre her sein. > Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war > zu groß und ich musste die Festplatte mitverwenden. Mit "über 10 Jahren" meinst du 30 Jahre oder so? Oder meinst du 8 GB? Nur so zur Erinnerung: -Anfang 2013 kam der Raspberry Pi mit 256 MB -Ende 2007 kam das iPhone mit 128 MB auf den Markt.
Mombert H. schrieb: > Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück > überzeugt und springe gleich ans Ende: > > Nano schrieb: >> Das ganze dürfte jetzt schon über 10 Jahre her sein. >> Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war >> zu groß und ich musste die Festplatte mitverwenden. Oh, kleiner Tippfehler. Es waren natürlich 8 GiB RAM. Ich habe das damals auf meinem Core2Duo durchgeführt und die Distri war irgendeine LTS Ubuntuversion aus der damaligen Zeit.
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. Eine Diskussion dazu im Debian-Devel-Forum findet man hier switching to vim-tiny for standard vi? https://lists.debian.org/debian-devel/2005/12/msg00796.html Der richtige vim wurde für base als zu groß angesehen und es wird lange diskutiert, welche optionale kleinere Version genommen werden soll. Wahrscheinlich haben sie auch irgendwo diskutiert wie man die Nutzer darüber informieren soll. Dazu habe ich aber auf die Schnelle keine Stelle gefunden. In der Paketbeschreibung von vim-tiny werden die Einschränkungen zwar erwähnt, aber das sieht der Nutzer eines frisch installierten base systems natürlich nicht, wenn er vim oder vi aufruft. https://packages.debian.org/bullseye/vim-tiny "This package contains a minimal version of Vim compiled with no GUI and a small subset of features. This package's sole purpose is to provide the vi binary for base installations. If a vim binary is wanted, try one of the following more featureful packages: vim, vim-nox, vim-athena, or vim-gtk3." Siehe auch Ein T. schrieb: > Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch > bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt > das Folgende aus:
:
Bearbeitet durch User
BTW, der popularity Contest bei Debian ist auch immer wieder interessant: https://qa.debian.org/popcon.php?package=nano https://qa.debian.org/popcon.php?package=vim Die Spalte "installed base" ist wenig aussagekräftig, wenn nano und vim-tiny vorinstalliert kommt, aber zumindest bei der Spalte vote dürfte man aussagekräftigere Daten haben. Vote steht da, wie die Beschreibung zeigt für: "Vote is the number of people who use this package regularly" Leute, die bei der Installation von Debian dieser Survey Funktion Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern zu. (Anmerkung: Ist wie beim nicht Wählen gehen). Nano liegt da mit 28311 votes auf Rang 817 Vim mit 20073 votes auf Rang 1013 und vim-tiny mit 11061 votes auf Rang 1423 Es scheint also viele zu geben, denen vim-tiny genügt oder denen nicht aufgefallen ist, dass sie einen abgespeckten vim verwenden. Andere Editoren habe ich mir auch mal angesehen: Joe 1146 votes, Rang 4218 https://qa.debian.org/popcon.php?package=joe Bei Emacs bin ich mir gerade nicht so sicher, ob emacs ohne namenszusatz nur für so ein Metapaket steht. Also guckt euch die Liste selber an: https://qa.debian.org/popcon.php?package=emacs Diverse GUI Editoren: kate v 4910 r 2215 https://qa.debian.org/popcon.php?package=kate gedit v 13374 r 1272 https://qa.debian.org/popcon.php?package=gedit geany v 1853 r 3409 https://qa.debian.org/popcon.php?package=geany pluma v 2420 r 3053 https://qa.debian.org/popcon.php?package=pluma mousepad v 3917 r 2471 https://qa.debian.org/popcon.php?package=mousepad Schade, dass man mehrere Pakete nicht auf einmal vergleichen kann.
Nano schrieb: > BTW, der popularity Contest bei Debian ist auch immer wieder > interessant: … solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig abgewählt.
Le X. schrieb: > Zumindest dafür gibts Abhilfe ;-) > https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition > Läuft bei mir unter Arch Linux nativ und problemlos. Danke für den Hinweis. :) Allerdings hatte ich das normale BG2 schon auf meinem Rechner installiert, und grundsätzlich läuft es ja, nur die Maussteuerung kommt nicht in die Gänge. In Windows gibt es solche Probleme auch, aber aber meist nur für ein paar Minuten oder Sekunden. Das war z.B. bei Kolibri OS so. Aber nach ein paar Minuten hatte sich die Maussteuerung gefangen. > (Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat > minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag > für Puristen evtl. nicht duldsam sein) Finde ich nicht schlimm. Aber eigentlich mochte ich das Zusammenzählen der Punkteverteilung beim Auswürfeln. Das hatte so einen netten Überraschungseffekt. Überhaupt scheinen mir die Arch-Entwickler der Abteilung Spiel und Spaß viel aufgeschlossener zu sein. Das aber nur eine Vermutung am Rande. Bei Fedora haben die schon angefangen, Benchmarks mit Far Cry 5 zu veröffentlichen - aber natürlich ohne sich ein paar Gedanken zu machen, was tatsächlich Gamemäßig abläuft, wo die Ansätze sind, oder wie man sie ordentlich dokumentiert. https://fedoramagazine.org/fedora-workstation-state-of-gaming-far-cry-5/ Nano schrieb: > Joe 1146 votes, Rang 4218 Naja, für Nano gab es auch kleine Einführungen vom Rechenzentrum an Unis. Teilweise waren (Einstiegs-)Kurse auch auf Nano ausgerichtet. Also von daher kein unbekannter Editor. Hinsichtlich der eigenständigen, unabhängigen Version auf Windows hat Joe aber deutlich die Nase vor Nano. Auch den MC gibt es schmerzfrei für Windows. So ein wenig kann man sich in der Situation hier auch an Basic erinnert fühlen. Letztlich war Basic für viele DIE Einstiegssprache schlechthin in das Programmieren. Und die Verbreitung von Basic war auch extrem. Irgendwie finde ich die Fortran 77 Werkzeuge der Watcom-Installation auch noch etwas ansprechender als GNU-Fortran.
Jack V. schrieb: > Nano schrieb: >> BTW, der popularity Contest bei Debian ist auch immer wieder >> interessant: > > … solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild > ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig > abgewählt. Wie bereits zuvor erwähnt: "Leute, die bei der Installation von Debian dieser Survey Funktion Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern zu." Beim Wählen ist das auch so. Wer nicht wählen geht, legitimiert die Gewählten.
Nano schrieb: > "Leute, die bei der Installation von Debian dieser Survey Funktion > Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern > zu." Was halt dazu führt, dass es nicht dazu geeignet ist, die Verbreitung oder gar Beliebtheit von irgendwas aufzuzeigen. Es war dazu gedacht, zu bestimmen, was auf den ersten Installationsimages landet, und ist heute weitgehend Deko. Wie auch immer – ist halt wieder so’n irrelevanter Nebenschauplatz, der eigentlich zum Thema nicht mal was beiträgt.
Nano schrieb: > head -c64M /dev/zero | tr "\000" "\n" >XXX Norbert schrieb: > Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:
1 | > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command |
2 | > 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi XXX |
> Wenn ich die mit nano öffne, dann werden ca 5.1GiB Speicher benötigt:1 | > PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command |
2 | > 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX |
Es geht auch anders:
1 | $ head -c64M /dev/zero | tr "\000" "\n" >XXX |
2 | $ fe XXX |
1 | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND |
2 | 44684 root 20 0 69420 68264 1744 S 0.0 0.1 0:00.32 fe XXX |
Dass hier der Speicherverbrauch nur geringfügig über der Größe der 64M Datei, welche nur aus Newlines besteht, hatte ich in diesem Thread hier mal kurz angedeutet: Beitrag "Re: Vi Editor ausgestorben?" Die Crux an den gängigen Editoren ist nämlich immer noch, dass sie zeilenorientiert arbeiten. Deshalb bauen sie da pro Zeile Verwaltungsstrukturen auf, die man gar nicht braucht. Den Text-Speicher kann man auch viel einfacher aufbauen, nämlich aus je zwei zusammenhängenden Blöcken, welche durch eine Lücke (gap) voneinander getrennt sind:
1 | buf1 | gap | buf2 |
2 | size1 gapsize size2 |
Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in die Lücke. Die gapsize wird dann um 1 verkleinert, size1 um 1 vergrößert. Bei weiteren Zeicheneinfügungen wird nichts mehr verschoben, es wird nur noch size1 inkrementiert und gapsize dekrementiert. Löschen per Backspace ist ebenso einfach:
1 | size1--; |
2 | gapsize++; |
Das wars. Und es funktioniert sogar zeilenübergreifend: Beim Löschen eines Newlines passiert nicht mehr! Ist die Lücke auf die Länge 0 geschrumpft, geschieht ein realloc(), um eine neue Lücke zu erzeugen. Auf heutigen Betriebssystemen, wo der Speicher sowieso nur virtuell gehandhabt wird, ist auch ein realloc() auf 1 GB oder mehr überhaupt kein Problem. Alle anderen Editierfunktionen werden analog implementiert, auf eine zeilenorientierte Speicherstruktur kann komplett verzichtet werden. Die Operationen auf den Speicher sind blitzschnell, da hier zusammenhängender Speicher verwendet wird. Man muss sich also nicht mehr von Zeile zu Zeile hangeln. Deshalb sind auch die Geschwindigkeiten bei einer Textsuche im zusammenhängenden Speicher kaum zu toppen. Verkettete Pointer auf die Zeilen oder ähnlich aufgebaute Verwaltungsstrukturen sind damit obsolet. Einziger Nachteil: Der Editor weiß nicht, in welcher Zeile sich der Cursor befindet. Diese Position muss er entweder auf Anfrage selbst ermitteln oder permanent bei jeder Textoperation nachhalten. Ich persönlich brauche solch eine Permanentanzeige nicht, die mir sagt, dass ich gerade in Zeile 9999 von 200000 stehe. Das kann der Editor auf Tastendruck auch ad hoc ermitteln, wenn ich es mal brauche.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Alle anderen Editierfunktionen werden analog implementiert, auf eine > zeilenorientierte Speicherstruktur kann verzichtet werden. Das ist zu kurz gedacht. Die Anzeige von Text in einem Texteditor ist ziemlich stark zeilenbasiert. Alle "comfort-Funtkionen" sind zeilenbasiert. diff, git-blame, Fehlermeldungen und Warnungen vom Compiler und so weiter. Es ist also naheliegend eine zeilenbasierte Datenstruktur zu nutzen. Frank M. schrieb: > Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per > memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in > die Lücke. Die Größe der Lücke wird dann um 1 verkleinert. Ist die Lücke > auf 0 geschrumpft, geschieht ein realloc, um eine neue Lücke zu > erzeugen. Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es plötzlich zwei Lücken und 3 Speicherblöcke. Führt man eine automatische Umbenennung von Variablennamen durch, gibt es N_umbennenung + 1 Speicherblöcke. Und entfernt man die überflüssigen Leerzeichen am Ende jeder Zeile gibt es N_zeilen+1 Speicherblöcke. Oder soll bei jeder dieser Aktionen durch kopieren wieder auf 2 Speicherblöcke reduziert werden? Für kleine Config-Files ist das egal, für eine 10k Zeilen Quelltextdatei oder größe CSV-Datein kann das schnell in einer Katastrophe enden.
mh schrieb: > Die Anzeige von Text in einem Texteditor ist ziemlich stark > zeilenbasiert. Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein Bildschirmfenster hat. mh schrieb: > Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es > plötzlich zwei Lücken und 3 Speicherblöcke. Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben. Es gibt immer nur eine Lücke. Der Editor existiert und ist real. Was er unter anderem kann, hatte ich in obigem Link mal angerissen: Beitrag "Re: Vi Editor ausgestorben?" Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache, kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen Blatt. Es gibt ihn nämlich nicht öffentlich.
Frank M. schrieb: > mh schrieb: >> Die Anzeige von Text in einem Texteditor ist ziemlich stark >> zeilenbasiert. > > Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei > der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt > wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein > Bildschirmfenster hat. Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer gestartet werden muss. Auch wenn man in Zeile 424242 und der Start-Pointer 2GB entfernt ist. Frank M. schrieb: > Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die > Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben. > Es gibt immer nur eine Lücke. Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die Lücke fällt. Frank M. schrieb: > Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache, > kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles > mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen > Blatt. Es gibt ihn nämlich nicht öffentlich. Wieviele Personen haben denn diesen "fe" schon getestet?
mh schrieb: > Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer > gestartet werden muss. Auch wenn man in Zeile 424242 und der > Start-Pointer 2GB entfernt ist. Der Start-Pointer liegt immer mindestens 3 Zeilen vor der Text-Cursor-Position. Das ist überhaupt nicht weit weg. Wenn ich mit dem Cursor eine Zeile tiefer gehe, wandert der Start-Pointer zum nächsten Newline (aus seiner Sicht) vor. Warum 3 Zeilen? Ich hasse Editoren, bei denen man die darüberliegende Zeile erst sieht, wenn man mit dem Cursor oben am Bildschirmrand anschlägt. Dasselbe gilt für den unteren Rand. Nähere ich mich ihm, dann fängt er frühzeitig an zu scrollen. > Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die > Lücke fällt. Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000 und dann 8000. > Wieviele Personen haben denn diesen "fe" schon getestet? Gestetet? Ungefähr ein Dutzend. Aktiv genutzt? Ein paar tausend. Er wurde u.a. an staatliche Stellen verkauft, z.B. an die Bundeswehr und diverse Staatsministerien - aber mit anderem Namen und Kontext. "fe" ist nur eine private Variante davon. P.S. Wenn Du dem Link in obigem Beitrag von mir gefolgt wärst, dann wüsstest Du, dass die Idee mit dem Gap nicht auf meinem Mist gewachsen ist, sondern von James Gosling stammt. Hier ein kleiner Literaturhinweis dazu: https://en.wikipedia.org/wiki/Gosling_Emacs oder auch zu seiner Person: https://en.wikipedia.org/wiki/James_Gosling . Er war unter anderem der Chefdesigner bei der Entwicklung von Java. Von daher behaupte ich mal, dass Editoren, die mit einer Lücke arbeiten, von mehreren hunderttausenden Anwendern genutzt wurden bzw. wird. P.P.S. Diese Stelle in seinem Code finde ich einfach genial: https://gist.github.com/jart/0a6a402b480e7dbcf8e61895759f2058 Unter einem ASCII-Art-Totenkopf steht folgendes:
1 | If you think you understand it, |
2 | You Don't, |
3 | So Look Again. |
Ergänzung: Ich habe lediglich seine Idee übernommen, nicht seinen Code. Den finde ich nämlich ziemlich gewöhnungsbedürftig. Zudem wurde "Gosmacs" von Gosling in den 80ern entwickelt. Da war der C-Sprachstandard längst nicht so weit wie heute. Von daher sieht der Code einfach "alt" aus. Richard Stallman (GNU Foundation) hatte ursprünglich für seinen "GNU Emacs" Teile von Gosmacs übernommen, hat diese dann auf Bitten von Unipress, welche mittlerweile Gosmacs kommerziell erworben hatte, wieder entfernt und neu implementiert. Ob "GNU Emacs" heute noch genauso mit einer Lücke arbeitet, weiß ich nicht. Offenbar ja: Nch kurzem Googlen finde ich folgendes: http://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html GNU Emacs scheint ebenso mit der Lücke (gap) zu arbeiten... da haben wir ja noch ein paar hunderttausend bis Millionen Anwender mehr ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: >> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die >> Lücke fällt. > > Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle > steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb > eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000 > und dann 8000. Selbst wenn: Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs aktuellen PC kein Ding.
Yalu X. schrieb: > Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs > aktuellen PC kein Ding. So ist es. Und man springt ja nicht dauernd vom Anfang zum Ende und wieder zurück. Und selbst wenn, wird noch lange nicht die Lücke verschoben. Verschoben wird sie erst, wenn ich auch tatsächlich an entfernter Stelle eine Textmanipulation vornehme.
Frank M. schrieb: > Alle anderen Editierfunktionen werden analog implementiert, auf eine > zeilenorientierte Speicherstruktur kann komplett verzichtet werden. Solch einen Editor (in der Art) hab ich damals (tm) in Z80-Assembler geschrieben. Hat wirklich sehr effizient funktioniert. Nachtrag: Heute würde ich es nicht wieder in Assembler machen. ;)
:
Bearbeitet durch User
Wie schnarchlangsam zeilenorientierte Editoren arbeiten, kann man einfach nachprüfen, wenn man XXX mal auf 640 MB vergößert.
1 | head -c640M /dev/zero | tr "\000" "\n" >XXX |
Dann startet man seinen Wunscheditor und drückt sofort die erforderliche Tastenkombination, um den Editor wieder zu verlassen:
1 | $ time fe XXX |
2 | real 0m3.046s |
3 | user 0m2.930s |
4 | sys 0m0.116s |
5 | |
6 | $ time vi XXX |
7 | real 0m12.316s |
8 | user 0m11.648s |
9 | sys 0m0.668s |
10 | |
11 | $ time nano XXX |
12 | real 0m56.437s |
13 | user 0m46.112s |
14 | sys 0m10.324s |
Einen Kommentar kann ich mir dazu mal sparen, nano säuft jedenfalls gnadenlos ab. Auch die sys-Zeit, welche angibt, wie lange die Anwendung den Kernel beansprucht, ist unterirdisch. P.S. Getestet unter Linux mit - AMD Ryzen 9 3900 (12 Kerne) - 128 GB RAM - 2x Samsung SSD PM983 1.92TB im Soft-Raid 1
:
Bearbeitet durch Moderator
Frank M. schrieb: > Dann startet man seinen Wunscheditor und drückt sofort die erforderliche > Tastenkombination, um den Editor wieder zu verlassen: Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg? (Wäre auf jeden Fall standardisierter). Da es neovim auch für Windows gibt, dachte ich, den schau ich mir mal genauer an, weil das beim Watcom Vi mit den Plugins nicht so toll ist. Nicht grundsätzlich aber für Neovim gibt es so nette Sachen und Lua Programming. Außerdem wird schon ein Plugin Manager empfohlen, da fühlt man sich fast wie bei Skyrim wo manche nicht vor > 300 Mods loslegen können. Auf die schnelle Gucken war aber auch erstmal nix, weil offenbar eine dll vergessen wurde, dem Packet beizulegen - oder wenigstens ein Readme diesbezüglich. Bei gvim geht das alles schon lange viel problemloser. (bei cygwin auch) Bei den Plugins für neovim sieht man oft Begleitbefehle für die Powershell. Da fragt man sich auch, was soll das. Können die Leute keine normale Windowskonsole mehr benutzen?
rbx schrieb: > Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg? Ich habe bei vi einfach ":q[CR]" gedrückt, ohne die Gänse. Da die Ladezeit immer die Tastendruck-Zeit übertraf, hat das auch keine Rolle gespielt. Das kann man auch ganz gut daran erkennen, dass in allen 3 Fällen ziemlich genau
1 | user + sys = real |
rauskommt. Idle-Zeiten gab es also keine ;-)
:
Bearbeitet durch Moderator
Frank M. schrieb: > Dann startet man seinen Wunscheditor und drückt sofort die erforderliche > Tastenkombination, um den Editor wieder zu verlassen: >
1 | > $ time fe XXX |
2 | > real 0m3.046s |
3 | > user 0m2.930s |
4 | > sys 0m0.116s |
5 | > |
6 | > |
Und wie soll die Zukunft deines fe Editors aussehen? Proprietärer Code neigt dazu, sofern er nicht in einem Unternehmen über mehrere Generationen hinweg weitergepflegt wird, zu sterben.
Kommt jetzt also vim vs. fe? Wann gehts los? Wer sind die Kombattanten? ;-)
rbx schrieb: > Bei den Plugins für neovim sieht man oft Begleitbefehle für die > Powershell. Da fragt man sich auch, was soll das. Können die Leute keine > normale Windowskonsole mehr benutzen? Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können, aber nicht wollen. Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.
Ein T. schrieb: > Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können, > aber nicht wollen. Die Powershell kann laut deren Aussage an vielen > Stellen deutlich mehr. Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht. Windows funktioniert anders als Linux, man sucht sich erstmal zusammen, was man so gebrauchen kann, wie z.B. die Sysinternals Programme. (oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu compilieren)
rbx schrieb: > Ein T. schrieb: >> Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können, >> aber nicht wollen. Die Powershell kann laut deren Aussage an vielen >> Stellen deutlich mehr. > > Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super > mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht. > Windows funktioniert anders als Linux, man sucht sich erstmal zusammen, > was man so gebrauchen kann, wie z.B. die Sysinternals Programme. > > (oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu > compilieren) Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser" fundamental von der meinen unterscheidet. Ich rede da von (und mit) Profis, weißt Du, und die sagen mir alle, daß die Powershell nicht nur so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe. Ein lieber Segelfreund von mir ist etwa spezialisiert auf MS Exchange, früher bei IBM und heute bei Microsoft. Der sagt, daß er früher meistens die GUI des Exchange-Servers und manchmal außerdem RegEdit benutzt hat, und mittlerweile nur noch die Powershell benutzt -- weil er damit viel schneller, sicherer und vor allem auch reproduzierbarer zum Ziel kommt. Ein anderer Mitsegler ist bei MS Deutschland im Azure-Bereich tätig und erzählt mir ganz Ähnliches. Klar, wenn die wesentlichsten und wichtigsten Tätigkeiten am Computer sich auf Spiele und etwas... exotischere Hobbies wie die von Dir genannten C-Compiler beschränken, dann wird man die Leistungsfähigkeit einer modernen Kommandozeile natürlich weder benötigen noch zu schätzen wissen. Das ist auch nicht schlimm. Aber darüber zu lästern und zu unterstellen, die Leute würden die Powershell nur benutzen, weil sie zu blöd für die klassische cmd.exe wären, das geht mir dann doch ein bisschen zu weit. Wie gesagt, Du hast halt keinen Bedarf nach einer modernen, leistungsfähigen Kommandozeile, und deswegen offensichtlich auch weder Erfahrung damit noch eine Ahnung davon, was die Powershell kann. Aber gräm' Dich nicht, in diesem Forum bist Du da in guter Gesellschaft: es gibt hier viele Leute, die alles ablehnen, das sie nicht verstehen (wollen), von der Objektorientierung über Skriptsprachen bis hin zu modernen Kommandozeilen, von Machine Learning über Fuzzy Logic bis hin zu bewährten Editoren... q.e.d. ;-)
Ein T. schrieb: > Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr. Sie kann mehr, macht aber alles anders, und vor allem kann sie Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich schmerzlich feststellen.
Jörg W. schrieb: > Ein T. schrieb: >> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr. > > Sie kann mehr, macht aber alles anders, und vor allem kann sie > Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich > schmerzlich feststellen. Das sind bei der Powershell keine Datenströme, sondern das sind Objekte! Das ist eine ganz andere Philoshopie.
Nano schrieb: > Das sind bei der Powershell keine Datenströme, sondern das sind Objekte! Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein generischer Ersatz für ein cmd.exe sein kann und/oder will. Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset von cmd.exe sei. Ist sie halt nicht.
Ein T. schrieb: > und die sagen mir alle, daß die Powershell nicht nur > so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe. Das ist allerdings auch keine große Kunst.
Ein T. schrieb: > Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser" > fundamental von der meinen unterscheidet. Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun? Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden wird. Sicher kann die einiges, aber vergleichen würde ich das, was die Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit konnte man auch viel machen. Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm. Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim?? Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen auf Spatzen schießen.
Die Powershell könnte man auch mit einem interaktiven Interpreter (z.B. Python-Shell) vergleichen. Eine Posix-Shell möchte sie ja offenkundig nicht sein. Ich höre über die Powershell auch nur gutes, auch von wenig MS-affinen Personen. Da ich damit aber kaum gearbeitet habe kann ich das weder bejajen noch verneinen. Um wirklich krasses Zeugs damit machen zu können braucht man wohl auch etwas .NET-Background.
Nano schrieb: > Das sind bei der Powershell keine Datenströme, sondern das sind Objekte! > Das ist eine ganz andere Philoshopie. Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan (sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind.
Jörg W. schrieb: > Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein > generischer Ersatz für ein cmd.exe sein kann und/oder will. Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf ausgelegt, .NET-Objekte zu verknüpfen. Wenn dies das Designziel war, dann sollte und wird sie gar kein generischer Ersatz für cmd.exe sein. > Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset > von cmd.exe sei. Ist sie halt nicht. Diese Implikation war von mir keineswegs intendiert, und vermutlich auch nicht von jenen Leuten, die mir von der Powershell erzählt haben.
rbx schrieb: > Ein T. schrieb: >> Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser" >> fundamental von der meinen unterscheidet. > > Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun? > Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden > wird. Du hattest den Begriff "Poweruser" eingebracht, nicht ich. > Sicher kann die einiges, aber vergleichen würde ich das, was die > Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit > konnte man auch viel machen. Wen ich mich recht entsinne, waren VB, VBA und VBS aber niemals interaktiv. Aber die Powershell ist genau das: eine interaktive Shell. > Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm. > Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm > zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim?? > Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen > auf Spatzen schießen. Unter den meisten Linux-Systemen gibt es bereits sehr moderne, leistungsfähige Shells, und das .NET-Framework, auf das die Powershell zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären Ansätzen. Insofern stellt sich mir gerade die Frage, wie Du darauf kommst, daß jemand die Powershell unter Linux benutzen wollen würde -- erst Recht zur Konfiguration von neovim?!
Ein T. schrieb: > Nano schrieb: >> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte! >> Das ist eine ganz andere Philoshopie. > > Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan > (sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind. Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann. Auch der Austausch von komplexen Datenstrukturen ist textbasiert natürlich etwas schwieriger. Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein Einwand inhaltlich richtig, wenn auch nicht unbedingt berechtigt. Ein T. schrieb: > und das .NET-Framework, auf das die Powershell > zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären > Ansätzen Veto. Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht schlechter) läuft (als unter Windows) ;-)
:
Bearbeitet durch User
Ein T. schrieb: > Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf > ausgelegt, .NET-Objekte zu verknüpfen. Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass sie unbrauchbar werden (irgendwelches Padding eingefügt). Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur .NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind. Le X. schrieb: > Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf > anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und > Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann. Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und "Daten" gibt es dort sowieso nicht, entsprechend ist es auch völlig egal, ob ich lesbare Texte oder irgendwelche Binärklumpen dort durch die Kante schiebe. Das funktioniert einfach™-
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Le X. schrieb: >> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf >> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und >> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann. > > Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und > "Daten" gibt es dort sowieso nicht Wieso schneidest du beim Zitieren denn meinen essentiellen Satz ab? Sorry, aber das ist ganz mies, sowas brauchts echt nicht. Ich hab extra für die ganz-päpstliche Fraktion klargestellt: Le X. schrieb: > Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein > Einwand inhaltlich richtig, Aber ein Textinterface funktioniert halt in der Praxis ganz anders als ein Interface mit definierten Objekten aus einem systemweiten Framework, und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon sehr schwierig (weswegen Dinge wie xml und json erfunden wurden). Bei Text muss halt Tool A den Output von Tool B genau parsen können, notfalls muss man mit Tools C, D und E den Zwischenoutput umformen. Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar: > WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Ich sehe schon dass der Powershell-Ansatz hier interessante Ansätze hat. Darauf wollte nano wohl hinaus, auch wenn er's mal wieder geschafft hat das sehr unglücklich zu formulieren. Die Diskussion ob Texte auch Daten sind müssen wir aber wirklich nicht führen.
:
Bearbeitet durch User
Le X. schrieb: > Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar: >> WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Das hat den Hintergrund, dass ›apt‹ für die direkte Verwendung gedacht ist, während es zum Scripten dafür geeignete Komponenten gibt, die man anstelle von ›apt‹ nutzen sollte.
Le X. schrieb: > Le X. schrieb: >> Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein >> Einwand inhaltlich richtig, > > Aber ein Textinterface funktioniert halt in der Praxis ganz anders als > ein Interface mit definierten Objekten aus einem systemweiten Framework, > und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon > sehr schwierig (weswegen Dinge wie xml und json erfunden wurden). > Bei Text muss halt Tool A den Output von Tool B genau parsen können, > notfalls muss man mit Tools C, D und E den Zwischenoutput umformen. Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann (zumindest unter unixoiden Systemen), nicht nur Text. Das kann man z.B. bei einem tar.gz-Archiv sehen. Das lässt sich z.B. so erzeugen:
1 | tar c mydir | gzip > mydir.tar.gz |
Früher, bevor tar selbst gzip aufrufen konnte, musste man es sogar in der Art schreiben. Der Output von tar besteht nicht aus Text, und der von gzip erst recht nicht.
Rolf M. schrieb: > Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann > (zumindest unter unixoiden Systemen), nicht nur Text. So ist es (und so funktioniert es ja auch in cmd.exe), niemand hat jemals festgelegt, dass eine Pipe nur für Strings da wäre. Daher hatte ich das Zitat auch eingekürzt (weil ich die Unterscheidung nicht einmal verstanden habe). Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn beide aus der .NET-Welt sind, dann sind das halt wie auch immer serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen sollte. Aber gut, wir hatten die Diskussion schon, ich weiß, dass die Powershell offenbar nur für .NET-Freunde richtig Sinn hat und weiß sie zu meiden. Mit .NET habe ich eh nichts weiter am Hut.
Ein T. schrieb: > Insofern stellt sich mir gerade die Frage, wie Du darauf > kommst, daß jemand die Powershell unter Linux benutzen wollen würde -- > erst Recht zur Konfiguration von neovim?! Eher so: Warum benutzen Linuxer nicht die normale Shell (CMD) oder wenigstens einer der normalen Alternativen dazu? Da gibt es ja einige. Ich fand es z.B. recht interessant, debug auch in der Cygwin Konsole aufrufen zu können. Mit Cygwin geht so einiges, sicher nicht alles, aber man kann seinen Spaß haben. Mit dem ghci oder dem Watcom Vi in der Powershell zu arbeiten, ist dagegen eher nervtötend. Möglicherweise hatte ich mich bei dem Plugs auch etwas verguckt.. https://github.com/junegunn/vim-plug#installation
Le X. schrieb: > Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf > anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und > Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann. Das scheint für die Powershell auch zu gelten, wenn ich die Ausführungen von Jörg Wunsch zu diesem Thema lese. Er berichtete diesbezüglich von Schwierigkeiten mit Wireshark, wenn ich mich recht entsinne. > Auch der Austausch von komplexen Datenstrukturen ist textbasiert > natürlich etwas schwieriger. Kommt halt darauf an. Die textbasierte Weitergabe hat den großen Vorteil, daß sie ausgesprochen flexibel ist und man mit Werkzeugen wie grep(1), sed(1), awk(1) etc manipulieren kann (und manchmal muß), was auf der Empfängerseite ankommt. Wie die erfahreneren Nutzer von unixoiden Pipes wissen, kann das bisweilen in ziemlich... aufwändigen Reformatierungen münden, die bei größeren Datenmengen durchaus auch manchmal zeit- und ressourcenaufwändig sein können. Wenn man wie Microsoft hingegen ein Framework wie .NET hat, mit dem man die meisten Funktionen des Systems und der eigenen Applikationen nutzen kann, dann macht das mit der Weitergabe von Objekten dieses Frameworks natürlich Sinn. Das heißt aber auf der anderen Seite allerdings auch, daß die verwendeten Komponenten mit den Objekten des Frameworks umzugehen wissen. Die Grundfunktion -- nämlich die Aus- oder Rückgabe einer Komponente als Eingabe einer anderen Komponente zu verwenden und die einzelnen Komponenten so flexibel zu einer komplexeren Funktionalität zu verbinden -- ist insofern im Kern dieselbe. Nur die Umsetzung ist bei den beiden Lösungen ganz unterschiedlich realisiert. > Ein T. schrieb: >> und das .NET-Framework, auf das die Powershell >> zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären >> Ansätzen > > Veto. > Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht > schlechter) läuft (als unter Windows) ;-) Das mag sein, davon habe ich keine Ahnung und verlasse mich daher gerne auf Deine Aussage. Tatsache ist allerdings, daß ich um Software, bei der Miguel De Icaza die Finger im Spiel hatte, lieber einen großen Bogen mache. ;-)
Jörg W. schrieb: > Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der > ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass > sie unbrauchbar werden (irgendwelches Padding eingefügt). Wenn einem so etwas begegnet, ist das sicherlich ärgerlich. Womöglich gibt es für solche Fälle sogar einen Workaround? > Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle > ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur > .NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind. Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine Software läuft, welche nicht .NET-fähig ist?
Ein T. schrieb: > Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine > Software läuft, welche nicht .NET-fähig ist? Keine Ahnung, was sie sich überhaupt dabei gedacht haben. Ich vermute ja mal, dass das gar nicht so sehr mit .NET zusammenhängt, sondern dass sie nur versuchen, da irgendwelche Zeichensatz-Konvertierungs-Geschichten drauf anzuwenden. Mir genügte es dann, den Schuldigen gefunden zu haben und zu meiden. (Absender war bei mir ein Python-Script, der .pcap erzeugt, Empfänger Wireshark. Abspeichern der .pcap-Datei per Ausgabeumlenkung hat sie genauso verhunzt.)
Rolf M. schrieb: >
1 | > tar c mydir | gzip > mydir.tar.gz |
2 | > |
Tipp für größere Archive:
1 | tar c mydir | pigz > mydir.tar.gz |
HF! ;-)
Jörg W. schrieb: > Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das > eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn > beide aus der .NET-Welt sind, dann sind das halt wie auch immer > serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die > nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen > sollte. Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder nur Zeiger auf Objekte, die in einer Art Shared Memory liegen. Damit könnte man sich den ganzen Aufwand mit Serialisierung und Deserialisierung sparen. Keine Ahnung, ob Microsoft das in der Powershell so implementiert hat, aber clever wär's.
Ein T. schrieb: > Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder > nur Zeiger auf Objekte, die in einer Art Shared Memory liegen. Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand an so einem Agreement nicht teilnimmt und in dem Falle entweder die Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen. Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle Option. (Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das ganz normale VM-System das bereits kann.)
Noch einmal 2 Fragen zu vim: 1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl ausgeben? Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es nett, wenn man nicht selber zählen muss. 2. Nochmal meine Frage von weiter oben. Wie damals bereits gesagt, habe ich youcompleteme installiert:
1 | 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 |
Aber vim-addons zeigt an:
1 | vim-addons |
2 | # Name User Status System Status |
3 | apparmor removed removed |
4 | editexisting removed removed |
5 | espeak removed removed |
6 | justify removed removed |
7 | matchit removed removed |
8 | youcompleteme removed removed |
Und wie nutze ich das jetzt?
Ein T. schrieb: > Tipp für größere Archive: > tar c mydir | pigz > mydir.tar.gz > > HF! ;-) Kenn ich. Und wenn man stärker komprimieren will per bzip2, kann man zum Beschleunigen pbzip2 verwenden. Bevor ich clonezilla entdeckt habe, hat mir das deutlich geholfen beim Komprimieren von 500GB-Festplatten-Images :) Ein T. schrieb: > Keine Ahnung, ob Microsoft das in der > Powershell so implementiert hat, aber clever wär's. Naja, dann muss das ganze ja auch irgendwie über Prozessgrenzen hinweg verwaltet werden, und Zugriffe müssen synchronisiert werden. Durch das Kopieren umgeht die Pipe solche Probleme komplett. Nano schrieb: > Noch einmal 2 Fragen zu vim: > > 1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl > ausgeben? Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro stecken, um es direkt nutzen zu können. Navigiere zum ersten " des Strings, dann: yt" :echo strlen(<C-r>") (<C-r> steht für Ctrl und r) > Aber vim-addons zeigt an: > vim-addons > # Name User Status System Status > apparmor removed removed > editexisting removed removed > espeak removed removed > justify removed removed > matchit removed removed > youcompleteme removed removed > > Und wie nutze ich das jetzt?
1 | vim-addons install youcompleteme |
Ich musste noch zusätzlich folgendes tun:
1 | sudo apt install python3-distutils |
Jörg W. schrieb: > Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand > an so einem Agreement nicht teilnimmt und in dem Falle entweder die > Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen. > > Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle > Option. Naja... hätte, wäre, wenn. Anscheinend war das wohl nicht gewollt oder jedenfalls nicht vorgesehen. Da müßte man die Entwickler fragen, warum sie das nicht gemacht haben und ob es eventuell Workarounds gibt. > (Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in > einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch > ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das > ganz normale VM-System das bereits kann.) Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über physikalische Dateien, mithin über den Dateisystempuffer arbeiten würden. Keine Ahnung, ob das stimmt, oder ob meine Erinnerung mich womöglich trügt.
Nano schrieb: > Wie damals bereits gesagt, habe ich youcompleteme installiert: > [...] > Und wie nutze ich das jetzt? Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast, ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits gefunden. Na, dann benutz' die doch einfach.
Ein T. schrieb: > Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über > physikalische Dateien, mithin über den Dateisystempuffer arbeiten > würden. Nö, intern (zumindest im BSD, in Linux kenne ich mich nicht aus) arbeiten sie genauso wie local domain sockets. Sind also eigentlich bidirektional, allerdings ist dieses Feature nicht portabel. Könnte sein, dass sowas wie command.com das mal mit Dateien emuliert hat, oder war's die microshell auf CP/M?
:
Bearbeitet durch Moderator
Rolf M. schrieb: > Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro > stecken, um es direkt nutzen zu können. > Navigiere zum ersten " des Strings, dann: > yt" > :echo strlen(<C-r>") > > (<C-r> steht für Ctrl und r) Ja du hast recht, das ist umständlich, aber: >
1 | > vim-addons install youcompleteme |
2 | > |
youcompleteme, wenn es per vim-addons install dann eingerichtet ist, danke für den Hinweis, zeigt automatisch an, wenn ein String, der einem char Array zugewiesen wird zu klein ist. Das ist also sogar noch besser. Ändern müsste man nur die Farbe, rosa Schrift auf rotem Hintergrund ist schlecht lesbar. > Ich musste noch zusätzlich folgendes tun: >
1 | > sudo apt install python3-distutils |
2 | > |
Das wurde bei mir automatisch mitinstalliert und war schon drauf.
Ein T. schrieb: > Nano schrieb: >> Wie damals bereits gesagt, habe ich youcompleteme installiert: >> [...] >> Und wie nutze ich das jetzt? > > Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast, > ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits > gefunden. Na, dann benutz' die doch einfach. Nur weil ich etwas ausprobieren will, heißt das nicht, dass ich das dann dauerhaft benutzen will. Und youcompleteme ist nicht vim, sondern ein Addon zu vim. Das ist ein großer Unterschied!
Nano schrieb: > Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es > nett, wenn man nicht selber zählen muss. Könnte man aber auch einer Suchmaschine fragen: https://vim.fandom.com/wiki/Word_count
rbx schrieb: > Nano schrieb: >> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es >> nett, wenn man nicht selber zählen muss. > > Könnte man aber auch einer Suchmaschine fragen: > > https://vim.fandom.com/wiki/Word_count Da steht nirgends etwas von "word count between """ und das war ja meine Frage. Um eine generelle Zeichenzählung geht es ja gerade nicht. Und ja, sicher kann man das wie oben mit etwas mehr Eingabeparametern dann auch irgendwie hinbiegen, aber diese aufwendigere Methode zeigt dann auch, dass das Zeichenzählen zwischen zwei "" nicht explizit vorgesehen war. Und das wollte ich wissen ob es da entsprechendes gibt.
Nano schrieb: > Da steht nirgends etwas von "word count between """ und das war ja meine > Frage. Korrektur ich meinte: character count beteen "".
Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim), wäre dir sicher aufgefallen, dass beim Markieren mit v, shift-V oder ctrl-V die Größe des markierten Bereichs in der Statuszeile angezeigt wird. Also markierst du einfach den String mit vi" (s. mein Beitrag weiter oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als auch in Bytes angezeigt. Nano schrieb: > zeigt dann auch, dass das Zeichenzählen zwischen zwei "" nicht > explizit vorgesehen war. Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die nicht explizit vorgesehen sind, nämlich durch das Kombinieren von Operatoren, Motions usw.
Yalu X. schrieb: > Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert > hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim), Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich schon längst vim installiert habe. > Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die > nicht explizit vorgesehen sind, nämlich durch das Kombinieren von > Operatoren, Motions usw. Lies oben nochmal und verstehe was ich geschrieben habe.
Nano schrieb: > Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich > schon längst vim installiert habe. Und die Länge des markierten Bereichs hat er nicht angezeigt?
Yalu X. schrieb: > Also markierst du einfach den String mit vi" (s. mein Beitrag weiter > oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der > String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als > auch in Bytes angezeigt. Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16 Bytes raus, was falsch ist. Richtig wären 15 Bytes (da \n in dem String ein Zeichen ist, aber im Quellcode aus zweien besteht und daher in diesem Fall auch so gezählt wird). Die von mir gezeigten Methode bekommt das korrekte Ergebnis raus.
:
Bearbeitet durch User
Rolf M. schrieb: > Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16 > Bytes raus, was falsch ist. Ok, die angezeigte Länge berücksichtigt keine Escape-Backslashes. Diese muss man selber von der angezeigten Länge subtrahieren, falls es sich um ein C-Stringliteral handelt.
Einige hier werden es bereits kennen: Seite 19, "Editors (a touchy subject)" http://www.cs.cmu.edu/afs/cs/academic/class/15213-f15/www/recitations/linux_boot_camp.pdf
:
Bearbeitet durch User
Alexander S. schrieb: > Einige hier werden es bereits kennen: Seite 19, "Editors (a touchy > subject)" > http://www.cs.cmu.edu/afs/cs/academic/class/15213-f15/www/recitations/linux_boot_camp.pdf Das Original findet man hier, kein Grund eine dicke PDF zu verlinken: https://xkcd.com/378/
Suchmaschine spukt u.a. aus: wc -m g Strg G vimscript Bei letzten Punkt denkt man dann: neovim? Lua! (war das mit der fehlenden dll für Windows nur ein Fettnäpfchen? Leider nicht, das wurde wohl gezielt so anvisiert, im Sinne von Nutzplattformfokussierung bzw. -beschränkung) (xkcd bzw. Randall Munroe erinnert recht stark an die Tagebücher und Briefe oder andere Schriften von Georg Christoph Lichtenberg https://de.wikipedia.org/wiki/Sudelb%C3%BCcher )
vim vs emacs? Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass mehr Erklärung notwendig ist?
willi schrieb: > vim vs emacs? > > Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher > als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder > ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass > mehr Erklärung notwendig ist? Ohne diesbezüglich Daten erhoben und analysiert zu haben, würde ich das als Indiz werten, daß der vi(m) schon deswegen häufiger genutzt wird, weil er auf unixoiden Systemen so ziemlich immer vorhanden ist. Außerdem gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. Stallman himself.
Jörg W. schrieb: > willi schrieb: >> vim vs emacs? > > Nö, war nicht die Frage. Irgendwie schon oder nicht? Ist vim ausgestorben (zu Gunsten von emacs)?
Ein T. schrieb: > Außerdem > gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von > einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. > Stallman himself. wann hat er diese Dokumentation geschrieben? ;-) Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B. VimScript. (war wohl doch nicht gut durchdacht)
emacs vs vim war gestern. heute gilt vim vs. neovim. und morgen wieder emacs vs. neovim. weil vim gegen neovim verlieren wird.
Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich ging's ja die ganze Zeit um vim vs. nano.
spricht eher dafür schrieb: > Ein T. schrieb: >> Außerdem >> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von >> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. >> Stallman himself. > > wann hat er diese Dokumentation geschrieben? ;-) Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The Extensible, Customizable, Self-Documenting Display Editor", stammt von 1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen Jahren heißt es "GNU Emacs Reference Manual" [3]. Auch wenn mir nicht ganz klar ist, was Du mit Deiner Frage bezweckst, so hoffe ich doch, sie hinreichend informativ beantwortet zu haben. [1] https://dl.acm.org/doi/book/10.5555/888850 [2] https://books.google.de/books/about/GNU_Emacs_Manual.html?id=v3QZAQAAIAAJ&redir_esc=y [3] https://www.amazon.de/GNU-Emacs-24-5-Reference-Manual/dp/9888381954 > Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B. > VimScript. (war wohl doch nicht gut durchdacht) Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die Software eben auch mal umbauen, um die Anforderungen abdecken und die neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht gewesen, erscheint mir daher vollkommen verfehlt.
Jörg W. schrieb: > Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich > ging's ja die ganze Zeit um vim vs. nano. Nein, darum ging es nie. Es gab hier lediglich vim Fanboys, wie man dies und das in nano löst. Es war am Ende also ein nano only Thread.
Nano schrieb: > Jörg W. schrieb: >> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich >> ging's ja die ganze Zeit um vim vs. nano. > > Nein, darum ging es nie. Es gab hier lediglich vim Fanboys *, wie man dies > und das in nano löst. Es war am Ende also ein nano only Thread. Satz vergessen: *die wissen wollten.
Jörg W. schrieb: > Und nano Fanboys. ;-) nano oder Nano? Ich bin ein echter Nano Fan. Selten ist die ▼ Entscheidung so einfach. :-)
Ein T. schrieb: > und dann muß man die > Software eben auch mal umbauen aber nicht die Programmiersprache. Lisp ist die beste Programmiersprache der Welt und darum wird emacs da nie was ändern (müssen). Und VimScript ist ein Ding, dass außer Vim keine Bedeutung hat und eine komische Syntax verwenden. Und auch darum ist NeoVim besser: Dort wird VimScript durch Lua ersetzt. Emacs ist da wirklich konsequent und besser. Aber diese Tastenkombinationen....
Ein T. schrieb: >> Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B. >> VimScript. (war wohl doch nicht gut durchdacht) > > Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal > wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die > Software eben auch mal umbauen, um die Anforderungen abdecken und die > neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und > Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine > Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die > Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht > gewesen, erscheint mir daher vollkommen verfehlt. Das Referenzbeispiel hier ist aber eher Elvis. ( http://elvis.the-little-red-haired-girl.org/ ) Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober der viel besser auf Windows läuft, als neovim.
rbx schrieb: > Das Referenzbeispiel hier ist aber eher Elvis. > > ( http://elvis.the-little-red-haired-girl.org/ ) > > Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober > der viel besser auf Windows läuft, als neovim. Unter Windows läuft der Elvis in der Version 2.2. Der ist von den Features auch heute noch top! Mir gefällt auch der WinVi: http://www.winvi.de/de/scrnshts.html Der hat auch einen Hex Editor eingebaut. Beide werden leider seit über 10 Jahren nicht mehr weiterentwickelt. Beide (genauso wie der Original vi) verstehen die hier als Beispiele gezeigten Befehle nicht.
1 | gg - geht nicht |
2 | da" - geht nicht |
3 | va" - geht nicht |
vi ist also auch nicht vi. Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen" nicht dabei. Auch fehlen etliche externe Libs. Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr als 100k Zeilen aber irgendwas falsch.
1 | vi-neatvi: 6475 |
2 | vi-WinVi: 31191 |
3 | vi-vis: 42059 |
4 | Notepad2: 55996 |
5 | vi-BSD_4_4_nvi.1.43: 94195 |
6 | vi-nvi-Berkely_vi: 121728 |
7 | vi-Elvis: 149560 |
8 | Notepad++: 254831 |
9 | vi-vim: 726514 |
10 | Emacs: 2142385 |
Ein T. schrieb: > spricht eher dafür schrieb: >> Ein T. schrieb: >>> Außerdem >>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von >>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. >>> Stallman himself. >> >> wann hat er diese Dokumentation geschrieben? ;-) > > Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber > die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The > Extensible, Customizable, Self-Documenting Display Editor", stammt von > 1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen > Jahren heißt es "GNU Emacs Reference Manual" [3]. Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL erfunden hat. rbx schrieb: > Das Referenzbeispiel hier ist aber eher Elvis. > > ( http://elvis.the-little-red-haired-girl.org/ ) Sehr schön. Elvis war schon Anfang der 90er für mich ein abschreckendes Beispiel für einen Editor unter Linux. Habe ihn dann trotzdem gelegentlich genutzt weil immer vorhanden. Später habe ich ihn dann nie mehr gefunden. Auch nicht die Website. Deshalb danke für die Verlinkung. udok schrieb: > Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen" > nicht dabei. Auch fehlen etliche externe Libs. > Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr > als 100k Zeilen aber irgendwas falsch. Die neuste Version von vim ist auch schon ganz schön fett geworden.
udok schrieb: > Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr > als 100k Zeilen aber irgendwas falsch. Ich muss gestehen das ich mir noch nie die Anzahl der Zeilen Sourcecode angesehen habe um eine Pro/Contra Entscheidung zu treffen. Ich fand's immer recht angenehm wenn der Editor mich einfach meine Arbeit machen ließ.
Ein T. schrieb: > Außerdem > gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von > einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. > Stallman himself. Original-Dokus sind oft schwer verständlich und didaktisch eine halb- bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.
Heinz schrieb: > Original-Dokus sind oft schwer verständlich und didaktisch eine halb- > bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere. und der Quellcode erst.. Stallmann meinte mal er hatte den Algoteil (der mit dem Totenkopf in der Originalquelle) noch viel eleganter bzw. smarter hinbekommen. Man stelle sich den Emacs Assembler-Optimiert vor, mit allem was man da heute so hat, mit Profiler einsteigen, Algoschinken, Rip-Mode, SSE, AVX (por Reg (String drin) 20h)(Alternative, OR AH, 20h) viele 64 Bit Register, Cuda als Rechenhilfe (also sowas wie Excel - Ersatz bzw. der neue Emacs- "Excel-Mode") und dann auch noch "Cloud-Optimierung" mit richtig guten Leuten.. Ansonsten scheinen ja keine Dokumentation (etwa wie bei Grafikkarten oder bei ARM hier und da), nur teilweise Dokumentation oder erbärmliche Dokumentation recht beliebt zu sein. Naja, wenn man das Know How hat und den Grips und eine gute Uniausbildung/UniBib auch noch, hat man zumindest einen Wettbewerbsvorteil. Vimscript ohne populäre Schnittstelle hat zumindest den Vorteil, nicht gleich wie mit Java an die Wand fahren zu müssen, oder mit neovim gewissermaßen Skyrim heavily-modded zu spielen. Der Cloud-Gedanke, bzw. das was Stallmann meint, ist ja so schlecht nicht, wenn man z.B. an die Automagie beim Start von Knoppix denkt, oder an den Emacs (der "Ersatzdesktop") bei Cygwin. Bei Cygwin ist (oder war, keine Ahnung) auf jeden Fall der Emacs der beste Editor ;) (da kann glaube ich auch kein WSL mithalten) Bei Fedora Workstation beschäftigt mich auch die Frage, Vim oder Neovim? Viel fesselnder finde ich aber die Frage, wie Neovim in Windows compilieren? Mit Watcom 32 Bit sollte das schon mal (weitgehend) reibungslos gehen. Spannender wird es bei 64 Bit. Wie weit kommt man mit Open Watcom V2? Aber neovim als 16-Bit Variante wäre meiner Meinung nach auch nicht so verkehrt. Back to the roots - würde ich mal so sagen. (das wäre dann z.B. Neovim für DOSBox) (könnte man statt Lua den C-Script Support vom Tiny C Compiler benutzen. Aber ach, der ist ja auch so 32 Bit..) Na, alles nicht so einfach.. https://stackoverflow.com/questions/3827370/h Ein T. schrieb: > rbx schrieb: >> Suchmaschine spukt u.a. aus: > > In Deiner Suchmaschine spukt es? 8-O Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das hat natürlich auch gewisse Vorteile, z.B. wenn man als Anrufer (wie ein echter Engel) bevorzugt wird in der ansonsten körperlich anwesenden Wartesschlange.
Hier noch Infos zum Speicherverbrauch und zur Suche unter Windows 10. Gemessen mit ProcessHacker. Der gvim ist auch unter Windows ein guter Allrounder - wenn man ihn bedienen kann... Interessanterweise ist auch der Notepad - über denn ja jeder lästert - vorne dabei. Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze 100MByte File in den Speicher holt. Bei der Suche kackt er aber ab. Alle anderen sind abgeschlagen. Wordpad und Word sind abgeschlagen, aber die konvertieren das Format intern um, und haben daher einen ordentlichen Nachteil.
1 | Peak Speicherverbrauch beim Öffnen von 100 Megabyte File mit 10 Millionen |
2 | Zeilen (Zahlen von 000000000 - 009999999) |
3 | => File Öffnen und Suchen des Strings 009999999, OS = Win 10 |
4 | |
5 | Editor | Peak Speicher [MB] | CPU Cycle [1e9-Cycles] | Kommentar |
6 | ========================================================================== |
7 | WinVi | 4.5 | 22.9 |
8 | gvim | 149 | 6.5 |
9 | Win10 Notepad | 272 | 4.3 |
10 | Notepad++ | 362 | 15.2 |
11 | Notepad2 | 372 | 12.3 |
12 | Visual Studio 2008 | 445 | 10.8 |
13 | Visual Studio 2022 | 616 | 149.8 |
14 | Wordpad | 845 | 236.0 |
15 | WinWord 2010 | 1230 | 579.0 |
16 | Notepad3 | | | Öffnet nicht |
17 | PsPad | | | Öffnet nicht |
18 | vi-Elvis | | | Öffnet nicht |
19 | ========================================================================== |
udok schrieb: > Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze > 100MByte File in den Speicher holt. Bei der Suche kackt er aber ab. > > Alle anderen sind abgeschlagen. Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am Speicherbedarf zu messen. Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei WinVi, Speicher nicht nutzt obwohl er vorhanden ist. Wichtig ist nur, dass er selbst für sich nicht viel braucht, also schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal etwas editieren" ist. Ich hatte, wie bereits gesagt, noch nie die Notwendigkeit solche großen Dateien mit Texteditoren zu öffnen. Was ich schonmal öffnen musste, war eine große Datendatei, für so etwas nutze ich aber einen Hexeditor und da sind drei Kriterien wichtig: 1. Kann der Hexeditor größere Dateien öffnen und bearbeiten als RAM vorhanden ist? 2. Nutzt er für die Bearbeitungsfunktionen das RAM oder lässt er es brach liegen. 3. Kann er auf solche in 1 beschriebenen Dateien auch Search and Replace anwenden ohne auszusteigen? Leider scheiterten da viele HexEditoren, die damit warben, unlimitiert große Dateien öffnen und bearbeiten zu können. Die S&R Funktion ist wohl leider oft so implementiert, dass hier dann nicht an den Speicherbedarf gedacht wird. Vermutlich rührt das daher, dass im RAM zuerst eine Datentstruktur aller gefunden Matches aufgebaut wird und dann der Nutzer gefragt wird, was er mit diesen jeweils einzeln oder auf alle angewendet machen möchte. Und hier steigen viele Hexeditoren dann aus, weil kein RAM mehr vorhanden ist und die aber mehr brauchen um die Sucheinträge unterzubringen. > Visual Studio 2008 | 445 | 10.8 > Visual Studio 2022 | 616 | 149.8 Wer eine 100 MiB große Quellcodedatei in eine IDE lädt, der macht etwas falsch.
Nano schrieb: > Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am > Speicherbedarf zu messen. > Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei > WinVi, Speicher nicht nutzt obwohl er vorhanden ist. > > Wichtig ist nur, dass er selbst für sich nicht viel braucht, also > schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal > etwas editieren" ist. Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. Startupzeit ist sicher ein weiteres wichtiges Kriterium. Einfache intuitive Bedienung und Integration ins OS ist auch wichtig, An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie gewöhnen. Schon interessant und frustrierend, das es nach >50 Jahren Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.
udok schrieb: > An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie > gewöhnen. Du kannst Dir die Tastaturbelegung doch beliebig umbasteln :) Ich finde es eher nervig, dass die GVIM packager für Windows immer ein "Windowsuseraugliches" Keymapping aktivieren. Aber das kann man ja zum Glück auch wieder rausschmeissen ;) /regards
udok schrieb: > Einfache intuitive Bedienung ist auch wichtig, Da bist du aber bei vi und Derivaten davon absolut falsch ;)
Ich benutze den vim in der Geschmacksrichtung "cream", das läuft auch unter wine. Für AVR-Assembler habe ich allerdings eine Syntax-highlighting-Datei im Web suchen müssen, die war nicht dabei. Schon von 2005, ist hier angehängt. Aber Geany kann es auch, in letzter Zeit habe ich den Cream nicht mehr benutzt.
Ich habe geany mit gedit verwechselt. Dort heißen die syntax-Dateien (xml) ".lang" und liegen unter /usr/share/gtksourceview->Version>/language-specs Speziell AVR habe ich nicht, aber mit "asm.lang" sieht es schon einigermaßen korrekt aus. Mit cream ist die Druckereinstellung etwas umständlich. Ich habe es für den PDF-Druck in mir angenehme Form eingerichtet.
:
Bearbeitet durch User
Karl Otto II. schrieb: > Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL > erfunden hat. Das stimmt, die Dokumentationen [1] unterliegen der GNU Free Documentation License [2]. Die GFDL ist die Lizenz des GNU-Projekts für Dokumentationen. Irgendwie beschleicht mich das Gefühl, daß Du mir etwas sagen möchtest. Aber leider komme ich nicht darauf, was das sein könnte. [1] https://www.gnu.org/software/emacs/manual/ [2] https://www.gnu.org/licenses/fdl-1.3.de.html
Heinz schrieb: > Ein T. schrieb: >> Außerdem >> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von >> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M. >> Stallman himself. > > Original-Dokus sind oft schwer verständlich und didaktisch eine halb- > bis vollkatastrophe ;) Das sehe ich nicht so. > Dazu kommt noch die Sprachbarriere. Englisch kann man lernen, das ist gar nicht so schwierig -- und wer Software oder Elektronik entwickeln will, kommt darum ohnehin nicht herum. Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus, da ist bestimmt auch etwas für Dich dabei.
rbx schrieb: > Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, > hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so > körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche Gesellschaft. ;-)
Ein T. schrieb: > Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für > die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus, > da ist bestimmt auch etwas für Dich dabei. Da habe ich schon vor über 20 Jahren gesucht und nur von der Fernuni Hagen etwas brauchbares zu Emacs gefunden. Aber etwas, das Inhaltlich im Umfang darüber hinausgeht, dann leider nicht. Habe dann mit Emacs sogar meine Diplomarbeit geschrieben. Heute benutze ich vi und emacs nur mal um einen Wert in einer Konfigurationsdatei zu ändern, dazu reichen dann meine Kenntnisse auch. Ansonsten benutze ich heute Notepad++ und VS Code. Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine Zeit zu schade. Deren Zeit ist einfach abgelaufen. Ein Editor ist für mich Werkzeug und nicht Selbstzweck.
timol schrieb: > Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine > Zeit zu schade. Um mit VScode effizient zu arbeiten, musst du dich genauso einarbeiten. Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal (mindestens die unterschiedliche Modi muss man kennen). Ich staune da immer wieder über meine Kollegen, weil ich mir viele der nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in Ordnung so.
Jörg W. schrieb: > Ich staune da immer wieder über meine Kollegen, weil ich mir viele der > nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs > effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in > Ordnung so. Klar ist es völlig in Ordnung. Mir kann es doch egal sein, womit sich hier wer quälen will. Ich kenne nur keinen Entwickler, der mit vim programmiert, aber ich weiß natürlich dass es welche gibt. In den meisten Firmen gibt es auch sehr strenge Vorgaben womit entwickelt wird, wie dokumentiert wird und wie der Code auszusehen hat. Oft hat da sogar auch der Kunde noch mitzureden. Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.
Jörg W. schrieb: > Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten > ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal > (mindestens die unterschiedliche Modi muss man kennen). Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man direkt im Insert-Mode, und es können die von Windows bekannten Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur Verfügung. Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.
timol schrieb: > Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders. Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was du hier gerade heraus hängen lässt.
udok schrieb: . Schon interessant und frustrierend, das es nach >50 Jahren > Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt. Das könnte vielleicht auch daran liegen, dass diese Wünsche ein sehr bewegliches Ziel sind. Der Eine will mal schnell eine Zeile in einer Konfigdatei ändern, ein anderer hingegen grosse Datendateien editieren, wieder einer möchte das Gesamtkunstwerk grafisch, aberauch über eine SSH-Verbindung nutzen, und jeder davon hätte es gerne möglichst komfortabel. Also im eigenen Sinne und für alle möglichen Definitionen des Wortes komfortabel, versteht sich. Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig und/oder unwichtig erklärt.
udok schrieb: > Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. > Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. hüstel Äh, bitte entschuldige... mit einem Editor? 8-O
Ein T. schrieb: > udok schrieb: >> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist. >> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache. > > hüstel Äh, bitte entschuldige... mit einem Editor? 8-O räusper Er meint bestimmt einen Hexeditor ;-)
alex schrieb: > Da bist du aber bei vi und Derivaten davon absolut falsch ;) Nö die Fanboys finden das Teil super und geilen sich seit hunderten von Beiträgen daran auf. Da müssen dann schon auch mal (Text-) Dateien mit 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Aber gut das Lieblingsspielzeug ist ja so geil, da ist das völlig wurscht ob man am Ende der Datei noch weis was in der 3. Zeile stand. Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen auch vi, vim oder wie sie alle heißen mögen. Damit wird die Arbeit erledigt und gut ist es. Mir würde es im Traum nicht einfallen so ein Gewese um dieses Thema zu machen. Ein Editor ist ein Werkzeug, das für meine Zwecke funktionieren muß - mehr nicht.
Zeno schrieb: > Da müssen dann schon auch mal (Text-) Dateien mit > 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig > derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch > Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format enthält? Was sind die Alternativen? Die Software, die die Daten erzeugt neu entwickeln? Einen anderen Job suchen, der nicht mit solchen Dateien zu tun hat? Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen Dateien oder dem Editor meiner Wahl. Meine Kollgen haben keine Probleme mit diesen Dateien oder dem Editor meiner Wahl. Mein Chef hat keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Unsere Kunden haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Nur du und nano haben Probleme damit. Und ihr wisst nichteinmal was das für Dateien sind und was damit gemacht werden muss.
Zeno schrieb: > Mir würde es im Traum nicht einfallen so ein Gewese um dieses Thema zu > machen. Warum machst du es denn dann?
Kiffer schrieb: > Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), > für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die > Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig > und/oder unwichtig erklärt. Nein, so war das nicht. Nano hat eingangs klargestellt für was er welchen Editor verwendet und warum. Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der vim zwar unbestreitbar besser performt, die für ihn aber nicht relevant seien. Das ändert freilich nichts daran dass er sich in den darauf folgenden technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war, überhaupt auf die Beispiele einzugehen.
:
Bearbeitet durch User
Le X. schrieb: > Sein Fehler war, überhaupt auf die Beispiele einzugehen. Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler bezeichnen. ;-) Wofür sollte er überhaupt gut gewesen sein? Irgendein ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen, scheint er nicht zu haben, was man schon an seinem Abqualifzieren derjenigen als "Fanboys" gut erkennen kann.
udok schrieb: > Schon interessant und frustrierend, das es nach >50 Jahren > Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt. Auch nach über 100 Jahren Automobilbau gibt es noch kein Automobil, das alle Wünsche nach Fahrleistung, Transportkapazität, Wirtschaftlichkeit, Umweltfreundlichkeit und Protzigkeit erfüllt. Immerhin scheint bei den Editoren jeder Diskussionsteilnehmer hier einen gefunden zu haben, der zumindest seine persönlichen Erwartungen erfüllt. Somit besteht womöglich gar kein Bedarf an der eierlegenden Wollmilchsau (falls diese überhaupt realisierbar ist).
Nano schrieb: > 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. Ja, und das ganze dauert 10x so lange und die Chance, dass man mit der Maus nicht ganz genau ist und evtl. mehr oder weniger löscht, ist ziemlich hoch. Das ist weder effizient noch ergonomisch. Alleine die Zeit, die ich dazu brauche meine Hand von der Maus auf die Tastatur zu wechseln ist mindest doppelt so viel wie "5dd" zu drücken. >> 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. Meine Güte, so ein Schwachsinn!
Petr T. schrieb: > Meine Güte, so ein Schwachsinn! Eine weitere Diskussion auf diesem Niveau erübrigt sich.
Le X. schrieb: > Kiffer schrieb: >> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), >> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die >> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig >> und/oder unwichtig erklärt. > > Nein, so war das nicht. Aber ja doch, genau so war das. Zu Anfang ist er gleich mal mit einer überheblichen Provokation in diesen Thread eingestiegen (Beitrag "Re: Vi Editor ausgestorben?") und dann hat er das passende Echo nicht vertragen und die Vollmimi gegeben. Und im Laufe dieser Entwicklung, die er mit seiner viel zu großen Klappe selbst bewußt und gezielt provoziert hat, hat er mehrfach die Contenance verloren, die Aufgaben und Wünsche anderer entweder einfach ignoriert oder für unwichtig erklärt, wieder andere wurden von ihm herablassend behandelt, als Straftäter diffamiert und als drogensüchtig bezeichnet. Auf dem Höhepunkt seines Auftritts, der vom ersten Beitrag an nichts als eine gezielte, bewußte und gewollte, maximal herablassende, arrogente und besserwisserische Peovokation war, hat Mr. Mimimi sich soger entblödet, nach den Moderatoren zu rufen, als ob die nicht schon genug mit den anderen ungezogenen Kleinkindern zu tun hätten. Chill mal Deine Base, LeX.
Jörg W. schrieb: > Irgendein > ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen, > scheint er nicht zu haben, was man schon an seinem Abqualifzieren > derjenigen als "Fanboys" gut erkennen kann. Das Wort "Fanboy" hat Nanos (wieder einmal, honi soit qui mal y pense) Beschützer LeX in diese Diskussion eingebracht. Sein Schützling hat das dann nur übernommen.
Kiffer schrieb: > Chill mal Deine > Base, LeX. Chillt am besten alle mal eure Base und kommt wieder zum Thema zurück.
Der Kiffer hier sollte mal weniger Drogen nehmen. Na immerhin passt der Name.
Jörg W. schrieb: > timol schrieb: >> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders. > > Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was > du hier gerade heraus hängen lässt. Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. So sind die Threads hier im Forum gleich unterhaltsamer. Aber ein Mod kann sich hier ja aufführen wie ein A...
mh schrieb: > Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere > 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format > enthält? Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei entsteht. Eine Datei mit Sourcecode, egal welche Programmiersprache wird wohl kaum so groß werden. Wenn man wirklich soviel Sourcecode unterbringen muß, dann teilt man das Projekt in halbwegs verdauliche Häppchen auf. bei meinem größten Projekt hatte eine Sourcecodedatei, die Hauptdatei des Projektes (insgesamt ca. 800 Sourcecodefiles), knapp 18000 Textzeilen (760kB) und das war eigentlich schon zu viel. Das Teil ist über 20 Jahre gewachsen, weil immer wieder neue Anforderungen dazu gekommen sind. Heute würde ich das anders machen. Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß. Bei dem erwähnten Programm handelt es sich um eine SW zum Auswerten von Messreihen. Die Daten liegen als ASCII Dateien vor sind aber selten größer als 10kB. Ausnahme sind Unixdatenfiles die meist als Wiederholungsprotokolle vorlagen, also noch zusätzlichen Fülltext enthielten. Die von mir entwicklte SW hat die Daten auch wieder im ASCII-Format gespeichert - Dateigröße ca. 10kB, davon aber meist so 10 Stück pro Messreihe, also isgesamt 100kB. Selbst bei sehr umfänglichen Messreihen war das Gesamtdatenvolumen nicht größer als 1MB, also 1% von Deinen 100MB - aufgeteilt auf mehrere Dateien. Mit anderen Worten wer so große Datendateien enstehen läßt macht was falsch. Solche Riesendateien kann kein Mensch mehr überblicken, geschweige denn vernünftig auswerten. Wenn derartige Datenmengen anfallen dann heißt das Stichwort Datenbank, die bringt dann auch die passenden Tools mit um die Daten auszuwerten. Für Logfiles gilt im Prinzip das Gleiche wie für die Daten. Da sollte man als Programmierer dafür sorgen, das die nicht zu groß werden. Ich habe deshalb bei meiner Software die Logfiles auf eine Maximalgröße von 2MB begrenzt. Wenn ein File diese Größe erreicht hat wurde der Name um das aktuelle Datum + Uhrzeit egänzt, dann weg gesichert und ein neues Logfile begonnen. Selbst dieses 2MB File ließ sich schon schlecht auswerten - einfach zu groß und unübersichtlich. Abgesehen davon würde ich ein Logfile auch nicht mit einem Editor öffnen, da gibt es in der GUI Viewer bzw. im Shellfenster cat, more und bei Bedarf grep. Und ja ich hatte auch schon größere Textdateien, aber 100MB sind mir in 30 Berufsjahren nie vor gekommen. Das Beispiel ist einfach nur an den Haaren herbei gezogen, um zu zeigen das der vi, vim etc. das Geilste ever ist. Um das eigentliche Thema geht es doch schon lang nicht mehr.
timol schrieb: > Aber ein Mod kann sich > hier ja aufführen wie ein A... Das tut der Jörg eigentlich nicht - auch wenn ich nicht generell seine Statements teile. Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare halt ab und an entsprechend aus. Man muß ja auch nicht alle Statements von Jörg kommentieren.
timol schrieb: > Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten > mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. Argumente bringst du ja auch keine, nur Behauptungen. Warum erwartest du dann von anderen Argumente? Du behauptest, dass andere "sich quälen", du definierst, wer wo wem was vorschreibt und dass das dann halt so sei. Möglicherweise habe ich schon ein paar "Klitschen" (das scheint dein Begriff für alles das zu sein, was du nicht kennst) mehr gesehen – zwischen 5 und 50000+ Mitarbeitern war da vieles dabei. Zeno schrieb: > Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei > entsteht. Tja, und wenn andere die Datei für ihn in der Form erzeugen? Gehst du zu denen hin und erzählst ihnen, dass sie da was falsch machen? Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien herum editieren würde – aber wenn solche Dateien halt irgendwo entstehen und man auch mal drin editieren muss (oder sie zumindest ansehen, was drin suchen etc.), dann sollte es ein Tool geben, mit dem man das machen kann. Das muss ja auch nicht notwendigerweise das gleiche sein wie das, mit dem man seine täglichen Programmieraufgaben erledigt – es soll Leute geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das Gegenteil von "Fanboys".
Zeno schrieb: > Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß. Veto. Zum Beispiel traces eines beliebigen Bus-Systems sind wesentlich größer. Die werden zwar meist mit dedizierter SW geöffnet, trotzdem kam es schon vor dass ich mit Traces mit einem Editor ansehen musste. Aber es stimmt schon, von der Fähigkeit, beliebig große Dateien öffnen zu können würde ich jetzt nicht die Wahl meines Standard-Editors abhängig machen. Dafür kommt dieser usecase (bei mir) zu selten vor.
Zeno schrieb: > mh schrieb: >> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere >> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format >> enthält? > Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei > entsteht. Natürlich hast du den Rest meines Beitrags nicht zitiert ;-) Du bist also der Meinung, dass ich die XXk€ Software, die mein Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du, wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".
Mombert H. schrieb: > Du bist also der Meinung, dass ich die XXk€ Software, die mein > Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du, > wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der > Begründung "Nano und Zeno sagen, dass ich etwas falsch mache". Also wenn ich Dein Arbeitgeber wäre, würde ich sagen "na klar, wenn diese ausgewiesenen Experten das sagen, müssen wir das sofort machen! Lass uns nochmal XXk€ ausgeben damit die beiden uns eine neue Software bauen, die kann nur besser sein!"
Ein T. schrieb: > rbx schrieb: >> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, >> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so >> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. > > Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit > mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche > Gesellschaft. ;-) Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln könnten?
Yalu X. schrieb: > Jörg W. schrieb: >> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten >> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal >> (mindestens die unterschiedliche Modi muss man kennen). > > Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man > direkt im Insert-Mode, und es können die von Windows bekannten > Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S > (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur > Verfügung. > > Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann > sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen. Das würde ich nicht sagen. Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über das Menü einstellbar. Mit Vim im Easy-Mode und den von Windows bekannten Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) hat man noch lange keinen Zeilenumbruch das Kodierungsschema eingestellt. Sollte man hier den Vim im Eays-Mode mit leistungsfähigeren Editoren vergleichen, die ihre Einstellungen über Menüs erlauben, dann geht hier noch weniger. Der Easy-Mode ahmt also zwar bekannte Tastaturkürzel nach, aber er macht Vim dadurch noch lange nicht zu einem intuitiv benutzbaren Editor. Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren feststellen konnte, kein ESC :q! um vim zu verlassen. Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt. Das einzige was ging war ALT+F4, aber das nur, weil das die Tastenbelegung für KDE zum Schließen von Anwendungen ist und die Konsole daher nachfragte, ob sie mitsamt allem, was darin läuft, geschlossen werden soll.
Nano schrieb: > Auch ein STRG+Q oder ALT+Q oder STRG- Meinte STRG+C > brachte hier keinen Erfolgt. Kiffer schrieb:> > Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), > für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die > Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig > und/oder unwichtig erklärt. Ich habe oben geschrieben, dass ich keine großen in der Regel Binärdateien mit einem Texteditor bearbeite und dafür einen Hexeditor verwende. Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 MiB große Quellcode Datei in einer IDE öffnen will. Tipp: Es macht Sinn, solche großen Quellcodedateien in mehrere kleine aufzuteilen. Bei so einer großen Datenmenge kann man sogar überlegen, ob man nicht vielleicht auch gleich noch eine Bibliothek baut und die dann einbindet.
Nano schrieb: > Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben (die berühmte Konfig-Datei). Selbst im Emacs benutze ich die entsprechende Funktion sehr selten, obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als auch Menüs).
Nano schrieb: > Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 > MiB große Quellcode Datei in einer IDE öffnen will. Es ging allerdings nicht um Quellcode, sondern um irgendwelchen Krempel, der in Textform vorliegt (daher keinen Hex-Editor braucht) und den irgendein Programm außerhalb des Einflussbereichs desjenigen produziert, der dann die Daten trotzdem gelegentlich ansehen und anfassen muss. Warum, weshalb und wieso die Daten genau so entstehen, muss man nicht diskutieren, wenn man darauf eh keinen Einfluss hat. Sie sind dann einfach da. Dass hier keiner 100 MB großen Quellcode in eine einzige Datei stopft, bedarf wohl keiner großen Diskussion.
Nano schrieb: > Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 > MiB große Quellcode Datei in einer IDE öffnen will. > Tipp: > Es macht Sinn, solche großen Quellcodedateien in mehrere kleine > aufzuteilen. Ich schreibe alle relevanten Infos mit printf ins Log, da sind bei 1000 Messages / Sekunde * 50 Bytes 30 MB in 10 Minuten erreicht... Das ist dank SSD kein Performanceproblem. Glaub mir, das willst du dir mit keinem Hex Editor anschauen.
Zeno schrieb: > alex schrieb: >> Da bist du aber bei vi und Derivaten davon absolut falsch ;) > > Nö die Fanboys finden das Teil super und geilen sich seit hunderten von > Beiträgen daran auf. Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige mich sogar persönlich angreifen, wie man oben sehen konnte. Der Grund ist einfach: Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann ist das natürlich besonders übel für die Fanboys, wenn ich deren vim nicht nutze. Bei einem IT Laien wäre das nämlich nicht so wichtig oder irrelevant, denn ein Laie kennt sich nicht aus, daher haben dessen Aussagen kein Gewicht, da ich keiner bin, ist das in meinem Fall anders. Dafür werde ich angegriffen, das ist der Grund. @vim fanboys :p > Da müssen dann schon auch mal (Text-) Dateien mit > 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig > derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch > Datendateien mit einem Editor bearbeiten muß, der macht was falsch. ++ So sehe ich das auch. > Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen > auch vi, vim oder wie sie alle heißen mögen. Ganz deiner Meinung.
Nano schrieb: > warum die Fanboys Die wissen, dass du dich allein durch die bloße wiederholte Verwendung dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen abzustempeln ist ein Ausdruck fehlender Argumente.
mh schrieb: > Zeno schrieb: >> Da müssen dann schon auch mal (Text-) Dateien mit >> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig >> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch >> Datendateien mit einem Editor bearbeiten muß, der macht was falsch. > > Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere > 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format > enthält? Ich versuche es mal: Ihr habt oben etwas von Messdaten geschrieben. Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, dann sollte man über ein Binärformat und ein Programm, über das man auf diese zugreift und das diese aufbereitet, nachdenken. Grund: Ein Binärformat spart viel mehr Platz und ist für einen Computer viel besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf, dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier zu großen Verlusten führen. Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust mehr Sicherheit und das erlaubt dann auch die alten Dateien zu komprimieren und so Speicherplatz zu sparen. Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei anzulegen. > Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen > Dateien oder dem Editor meiner Wahl. Bis mal der Rechner eine Störung hat. > Mein Chef hat keine > Probleme mit diesen Dateien und dem Editor meiner Wahl. Dann weise ihn mal auf die Punkte hin, die ich gerade genannt habe und dann beobachte ob sich an seiner Einstellung etwas ändert. > Unsere Kunden > haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Gleicher Fall wie beim Chef. > Nur > du und nano haben Probleme damit. Wir haben ja auch Ahnung und würde das so deswegen auch nicht machen. Die Begründung warum wir das anders machen würde, habe ich hier gerade geschrieben. Es liegt jetzt an dir, daraus zu lernen und die Verbesserungen zu übernehmen und umzusetzen und dann brauchst du auch diese großen Dateien nicht mehr. > Und ihr wisst nichteinmal was das für > Dateien sind und was damit gemacht werden muss. Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im einfachsten Fall ASCII Text.
Nano schrieb: > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann > ist das natürlich besonders übel für die Fanboys, wenn ich deren vim > nicht nutze. Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du dich aufregst, über was auch immer... dazu gehören aber mindestens 2.
Nano schrieb: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Ist alles richtig, aber dann muss ich erst ein Programm schreiben, das mir die Daten in ASCII umwandelt. Bringt also nix ausser Arbeit. Wir leben auch nicht mehr in den 90'ern. Jedes Handy Spiel installiert heute 100 MB...
Le X. schrieb: > Kiffer schrieb: >> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), >> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die >> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig >> und/oder unwichtig erklärt. > > Nein, so war das nicht. > Nano hat eingangs klargestellt für was er welchen Editor verwendet und > warum. > Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der > vim zwar unbestreitbar besser performt, die für ihn aber nicht > relevant seien. So weit okay. > Das ändert freilich nichts daran dass er sich in den darauf folgenden > technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war, > überhaupt auf die Beispiele einzugehen. Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in MB gedacht habe.
Nano schrieb: > Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich > 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht > aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in > MB gedacht habe. Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen. Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber auch nix, im Fernsehen spielts ja nix gescheites.
Jörg W. schrieb: > Le X. schrieb: >> Sein Fehler war, überhaupt auf die Beispiele einzugehen. > > Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler > bezeichnen. ;-) Ich habe diesen Thread nicht eröffnet. Der ist nicht von mir. Er wurde von dem Nutzer OpenBSD am 06.01.2020 16:38 erstellt. Ich habe auf die Frage des TS erstmals am 8.1.2020 geantwortet.
Nano schrieb: > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu Du solltest an Deiner Selbstwahrnehmung arbeiten. Niemand hier dürfte Dich für einen Profi halten. Eher für einen Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Nachweise Deiner angeblichen Kompetenz willst Du ja leider nicht liefern: Beitrag "Vielzahl an IDE, Framworks, usw."
udok schrieb: > Nano schrieb: >> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich >> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht >> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in >> MB gedacht habe. > > Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen. Okay, die Zeit hätte ich mir natürlich sparen können, so hast du natürlich recht. Aber einen technischen Fehler habe ich nicht gemacht, außer dem mit den 8 MB anstatt 8 GB. > Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber > auch nix, im Fernsehen spielts ja nix gescheites. Das ist wahr.
Kiffer schrieb: > ...viel Unsinn... Erstens: Du hast dich im Thread verirrt. Zweitens: Deine Behauptungen und Anschuldigungen hier bezüglich dem anderen Thread sind nicht korrekt. Bist du vielleicht der Straftäter aus dem anderen Thread? Ein Mod könnte und sollte das mal überprüfen, das würde mich interessieren.
vim schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu > > Du solltest an Deiner Selbstwahrnehmung arbeiten. > > Niemand hier dürfte Dich für einen Profi halten. Eher für einen > Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen > zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne > Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten. Und was alle anderen außer ihm falsch machen. Und was er viel besser könnte wenn man ihn nur ließe. Er erklärt uns wie groß Dateien werden dürfen. Und das er noch nie Größere gebraucht oder gesehen hat. Er erklärt uns das Binärformate bei größeren Dateien besser sind. Wir alle sollten besser auf ihn hören! ;-)
Jörg W. schrieb: > Nano schrieb: >> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über >> das Menü einstellbar. > > Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben > (die berühmte Konfig-Datei). Nicht zwingend. Früher musste man unter Windows die Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien, die unter Unix mit einem LF Codierung für den Zeilenumbruch abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte. Und README Dateien lesen, das gehört meiner Meinung nach noch zu den administrativen Aufgaben. Heute in Windows 10 kann Notepad glücklicherweise mit diesen Zeilenendencodierungen umgehen, aber früher war das nicht so. Und beim Kodierungsschema ist es nicht viel anderes. Vieles kam aus DOS Zeiten mit z.B. Codetabelle 430, dann musste man das entsprechend umstellen können. > Selbst im Emacs benutze ich die entsprechende Funktion sehr selten, > obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als > auch Menüs). Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte, welcher Editor sich für mein DOS Projekt am besten eignet. Emacs hat beim ersten Start irgendwelche Daten aufbereitet und eine Ewigkeit dafür gebraucht. Danach haben die Starts auch sehr lange gedauert. Ich habe ihn daher gelöscht. Aber wenn du willst, dann kannst du dir das gerne mal unter FreeDOS ansehen. Die Emacs Version darauf ist schon ein paar Jahre alt.
Jörg W. schrieb: > Nano schrieb: >> warum die Fanboys > > Die wissen, dass du dich allein durch die bloße wiederholte Verwendung > dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen > abzustempeln ist ein Ausdruck fehlender Argumente. Oh, mir ging es da jetzt nicht um die normalen Vim Nutzern, sondern tatsächlich um die aggressive Gruppe unter den Vim Nutzern die hier ausrastet, wenn man vim nicht nutzt. Der Einfachheit halber übernehme ich hier lediglich die Begriffsbezeichnung, die Le X. anfangs einbrachte und nutzte, in dem Fall also "Fanboys". Siehe dazu: Beitrag "Re: Vi Editor ausgestorben?"
udok schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann >> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim >> nicht nutze. > > Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du > dich > aufregst, über was auch immer... dazu gehören aber mindestens 2. Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den anderen dann zu korrigieren. Du kennst ja sicher folgendes Comic: https://xkcd.com/386/ Ich kann stundenlang diskutieren.
vim schrieb: > Nano schrieb: >> Der Grund ist einfach: >> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also >> weitaus mehr Gewicht zu > > Du solltest an Deiner Selbstwahrnehmung arbeiten. > > Niemand hier dürfte Dich für einen Profi halten. Eher für einen > Informatik-Erstsemester, ... Als vim Fanboy hast du jetzt natürlich keine andere Möglichkeit mich wieder persönlich anzugreifen, anstatt in der Sache, nachdem ich Personen wie dich durchschaut habe. > Deine Beitragsbewertungen sprechen für sich, -13 ohne > Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. Beitragsbewertungen kann man als Gast nicht einsehen, also existieren sie nicht. Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI zu verstehen.
Norbert schrieb: > Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten. > Und was alle anderen außer ihm falsch machen. > Und was er viel besser könnte wenn man ihn nur ließe. > Er erklärt uns wie groß Dateien werden dürfen. > Und das er noch nie Größere gebraucht oder gesehen hat. > Er erklärt uns das Binärformate bei größeren Dateien besser sind. > > Wir alle sollten besser auf ihn hören! ;-) Oben habe ich in meinem Beitrag Beitrag "Re: Vi Editor ausgestorben?" ja ausführlich und argumentativ begründet, warum man für Messdaten keine einzige große Datei nutzen sollte. Es steht dir jetzt frei, diese ganzen von mir genannten Argumente hiermit zu widerlegen, aber warum nutzt du diese Chance nicht und greifst mich stattdessen wieder persönlich an, O Ton: > Aber dafür erklärt er uns doch so schön die Welt... anstatt einfach mal in der Sache mich argumentativ zu widerlegen? Überlege mal! Letzten Endes könntest du jetzt auch einfach zugeben, dass du die genannten Argumente nicht widerlegen kannst.
Nano schrieb: > vim schrieb: >> Deine Beitragsbewertungen sprechen für sich, -13 ohne >> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle. > > Beitragsbewertungen kann man als Gast nicht einsehen, also existieren > sie nicht. > Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen > sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an > dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI > zu verstehen. Ups, da fehlte ein Wort. Ich meinte natürlich "nicht zu verstehen".
Nano schrieb: > Oben habe ich in meinem Beitrag > Beitrag "Re: Vi Editor ausgestorben?" > > ja ausführlich und argumentativ begründet, warum man für Messdaten keine > einzige große Datei nutzen sollte. > > Es steht dir jetzt frei, diese ganzen von mir genannten Argumente > hiermit zu widerlegen Diese Hybris ist unbeschreiblich! Du meinst tatsächlich anderen erklären zu müssen, was richtig und was falsch ist? Wer glaubst du eigentlich wer du bist? Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes vorzustellen: Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB. Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht beugen wollen. Diese Anlagen bestehen darauf Daten im Textformat auszuspucken. Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert tadellos. Also nimm dich mal ein wenig zurück und rede (und vor allem urteile) nicht über Dinge die in deiner Welt nicht vorkommen.
Nano schrieb: >> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann >> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen. > > Das würde ich nicht sagen. Du nicht, ich schon. > Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Ich habe nicht behauptet, dass EasyVim ein 1:1-Notepad-Klon ist, aber die wesentlichen Funktionen, insbesondere die, die man zum Editieren der berühmten Config-Files braucht, sind gleich oder zumindest leicht in den Menüs auffindbar. Wer deutlich mehr braucht, nutzt nicht den Easy-Mode und erst recht nicht Notepad. Was meinst du mit dem einstellbaren Zeilenumbruch? Die Aktivierung und Deaktivierung des automatischen Zeilenumbruchs? Oder die maximale Zeilenlänge als Parameter für den automatischen Zeilenlänge? Beides lässt sich über das Menü einstellen. Was meinst du mit Kodierungsschema? Die Zeichenkodierung? Defaultmäßig wird diese von der zu editierenden Datei oder – wie beim Nano – vom der Einstellung des aufrufenden Prozesses bzw. des Betriebssystems übernommen. Kein Anfänger möchte diese Einstellung ändern. Falls er fortgeschritten genug ist, um dennoch solche exotischen Funktionen zu brauchen, wird es ihm nicht schwer fallen (auf jeden Fall leichter als beim Nano ;-)), den entsprechenden Befehl nachzuschlagen. > Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren > feststellen konnte, kein ESC :q! um vim zu verlassen. Das soll es auch nicht, denn das wäre ja für den Anfänger nicht easy :) > Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt. Strg+Q sollte gehen und geht bei mir auch. Wenn es bei dir nicht geht, hast du wieder so eine verkrüppelte Vim-Version installiert, oder dein Window-Manager nutzt diese Tastenkombination für eigene Zwecke. Dann bleibt aber immer noch das Menü (File/Exit bzw. Alt+FX) oder eben > ALT+F4 Nano, mittlerweile weiß doch jeder, der diesen Thread liest, dass du kein Freund von Vim bist, und jeder (einschließlich mir) akzeptiert dies, auch ohne dass du ständig neue und immer fadenscheinigere Gründe gegen Vim an den Haaren herbeiziehst.
Norbert schrieb: > Nano schrieb: >> Oben habe ich in meinem Beitrag >> Beitrag "Re: Vi Editor ausgestorben?" >> >> ja ausführlich und argumentativ begründet, warum man für Messdaten keine >> einzige große Datei nutzen sollte. >> >> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente >> hiermit zu widerlegen > > Diese Hybris ist unbeschreiblich! > Du meinst tatsächlich anderen erklären zu müssen, was richtig und was > falsch ist? Wer glaubst du eigentlich wer du bist? Und wieder wiederholst du deinen Angriff auf die Person, anstatt in der Sache meine Argumente zu widerlegen. Lies und lerne: https://de.wikipedia.org/wiki/Argumentum_ad_hominem > Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes > vorzustellen: > Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB. > Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht > beugen wollen. > Diese Anlagen bestehen darauf Daten im Textformat auszuspucken. > Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert > tadellos. Das widerlegt meine Argumente nicht, es zeigt nur, dass diese Geräte von den gleichen Typen programmiert wurde, die alle Messdaten in eine einzige große Datei zu schreiben. Übrigens gibt es das split Kommando, das solltest du dir mal ansehen.
Nano schrieb: > Ihr habt oben etwas von Messdaten geschrieben. > > Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, > dann sollte man über ein Binärformat und ein Programm, über das man auf > diese zugreift und das diese aufbereitet, nachdenken. Du meinst z.B. so wie es systemd tut? Der schreibt seine Logdaten als Binärklumpen raus, so dass man sie nicht mehr einfach mit einem normalen Texteditor öffnen kann. Ansonsten: Was bringt es mir, über ein Binärformat nachzudenken? Wenn ich ein Programm habe, das die Daten als Text ausgibt, dann ist das eben so. Nicht jeder hat die komplette Software, die er benutzt, selbst geschrieben oder die Möglichkeit, diese mal kurz umzuprogrammieren, um ein völlig anderes Format auszugeben. > Grund: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. Allerdings muss man dann eben auch das Anzeigeprogramm schreiben. Bei Text nehme ich einfach den bereits vorhandenen Texteditor. > Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei > anzulegen. Sag das mal dem AUTOSAR-Konsortium. Da können auch mal XML-Dateien entstehen, die 2GB groß sind. Das kann ich als Anwender nicht ändern, sondern nur hinnehmen und muss halt irgendwie damit klar kommen.
Nano schrieb: > Ein T. schrieb: >> rbx schrieb: >>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, >>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so >>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. >> >> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit >> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche >> Gesellschaft. ;-) > > Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln > könnten? Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und Berührungen geht. ;-)
Nano schrieb: > Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann > aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige > mich sogar persönlich angreifen, wie man oben sehen konnte. > > Der Grund ist einfach: > Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also > weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann > ist das natürlich besonders übel für die Fanboys, wenn ich deren vim > nicht nutze. Bwahahahaha! TY, YMMD... again! ;-)
Nano schrieb: > Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin > da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den > anderen dann zu korrigieren. Davon merke zumindest ich leider wenig. > Ich kann stundenlang diskutieren. Das hingegen ist mir schon aufgefallen. Erstaunlich, nicht wahr?
Nano schrieb: >> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben >> (die berühmte Konfig-Datei). > > Nicht zwingend. Früher musste man unter Windows die > Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien, > die unter Unix mit einem LF Codierung für den Zeilenumbruch > abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte. Dafür habe ich nie Notepad genommen, sondern Wordpad. Das konnte das sofort. Da man darin aber nichts editieren muss, interessiert mich nicht, wie man da was umstellen würde. > Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 > ausprobiert Das ist ja auch Quatsch, das überhaupt zu versuchen. Du kannst vielleicht einen alten GNU Emacs auf einer PDP-11 benutzen, aber einen aktuellen Emacs auf so einem kastrierten System zu nehmen, das kann nicht gut gehen. Ein aktueller Emacs startet (im GUI-Modus) auf vergleichbarer Hardware unter Unixen zumindest schneller als ein Notepad++ unter Windows.
Jörg W. schrieb: > Ein T. schrieb: >> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr. > > Sie kann mehr, macht aber alles anders, und vor allem kann sie > Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich > schmerzlich feststellen. Von einem User im Python-Forum.de werden das "Windows Terminal" [1] und der "Cmder" [2] empfohlen, vielleicht könnte eines dieser Programme etwas für Dich sein. HF! [1] https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701?hl=de-de&gl=DE [2] https://cmder.net/
Nano schrieb: > 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. hihi... ja die erkennt man echt gut ;)
Le X. schrieb: > Es ist schon interessant wie fanatisch man sein Tool lieben kann. > Überkochende Emotionen sind ein Garant für gute Unterhaltung. Oh ja... bin schon an der zweiten Portion Popcorn...
Nano schrieb: > Meinte STRG+C Das ist das klassische Argument. Das ist dann eher so, wie wenn der Rechner beim Skyrimspiel hängt bzw. das Bild "einfriert". Konsole geht nicht. Alt-F4 auch nicht usw. Aber irgendwas geht. Oft muss man den Rechner nicht neustarten. Bei Windows geht bei solchen Sachen erfahrungsgemäß Strg+Alt+Entf gut. Das kann man auch ab und zu in Linux benutzen. Aber prinzipiell nicht mehr sinnvoll, wenn der Bildschirm einfriert. Im Unterschied zu den Spielstörungen gibt es bei Vi und Vim die ein oder andere Einführungshilfe. Die sollte man mitnehmen/Dabeihaben. Aber auch dann ist das nicht mehr rauskommen blöd und kann vorkommen - vermutlich deswegen, weil es meist nicht in Großbuchstaben im Hilfetest steht. Nano schrieb: > enn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über > das Menü einstellbar. Notepad++ kann das. Open Office, also Libre Office aber auch. Auf jedenfall muss man das öfter machen, wenn man Texte vom Normalen Desktop nach Cygwin überträgt. Nano schrieb: > Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 > ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte, > welcher Editor sich für mein DOS Projekt am besten eignet. Da kannst du den Watcom Vi benutzen :) Und außerdem die 32Bit Debug-Version von Paul Vojta. Ein T. schrieb: > Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und > ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich > andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und > Berührungen geht. ;-) Mir ging es nur darum, den Unterschied zwischen der "Geistform" und der normalen körperlichen Anwesenheit verständlich zu machen. Das scheint mir ja gut gelungen zu sein, und das reicht mir auch. https://www.youtube.com/watch?v=ppmEc56nSFk
Zeno schrieb: > timol schrieb: >> Aber ein Mod kann sich >> hier ja aufführen wie ein A... > Das tut der Jörg eigentlich nicht Aber sicher tut er das - und zwar nicht nur in diesem Thread. > Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare > halt ab und an entsprechend aus. Die Benutzung von Unix rechtfertigt noch lange nicht ein solches Verhalten. Und es betrifft ja auch viele andere Themen. > Man muß ja auch nicht alle Statements > von Jörg kommentieren. Klar, man muss gar nichts. Gilt für andere aber auch.
timol schrieb: > Zeno schrieb: >> timol schrieb: >>> Aber ein Mod kann sich >>> hier ja aufführen wie ein A... >> Das tut der Jörg eigentlich nicht > > Aber sicher tut er das - und zwar nicht nur in diesem Thread. Hm, die Vi Benutzung mit gewissen Formen des Unternehmertums in einen Topf, bzw. eine Schublade zu werfen, ist aber schon spannend. https://de.wikipedia.org/wiki/Generalisierungsgradient
Jörg W. schrieb: > Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien > herum editieren würde Das liest sich aber in seinem Beitrag anders. mh schrieb: > Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen > Dateien ... Ich lese das so, das er öfter mit solchen Dateien zu tun hat. Am Ende ist es mir arber auch Rille. Ich habe mich die letzten 25 Jahren mit Auswertung von Messdaten beschäftigt, sowohl von der SW-Seite (Entwickler) her und auch als Anwender, also selbst Messdaten erzeugt. Derartig große Textdateien, die ich dann noch mit einem Editort bearbeiten müßte, sind mir da nicht untergekommen. Lediglich beim CT gab es eine Datendatei mit ca. 2GB. Da waren aber nur die ersten 2kB reiner Text der Rest war binär. Jörg W. schrieb: > es soll Leute > geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das > Gegenteil von "Fanboys". Schrieb ich ja z.B cat, more, grep und Konsorten. Mombert H. schrieb: > Natürlich hast du den Rest meines Beitrags nicht zitiert ;-) Warum sollte ich das das tun, wenn ich nur Deine Frage beantworte?
Nano schrieb: > Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im > einfachsten Fall ASCII Text. Naja heute ist ja XML die Wunderwaffe. Das hat zwar durchaus seine Berechtigung und die Daten sind sehr gut lesbar, aber es bläht die Datei eben auch deutlich auf. Die Datendateien meines Programmes waren für eine Messung zwischen 7 und 10kB groß, macht für eine vollständige Messreihe mit 7 Messungen 70-100kB. Der Typ der meine Software neu programmieren sollte hat da auf XML gesetzt, woraufhin sich das Datenaufkommen verzehnfacht hat. Gut spielt nunmehr keine Rolle mehr da man die Neuentwicklung nach 6 Jahren eingestellt hat und mit meinem Programm weiter arbeitet. Noch sparsamer im Platzverbrauch war mein Vorgängerprogramm, das hat für einen kompletten Datensatz weniger als 10kB gebraucht. Nachteil war natürlich, das man sich die Daten nur mit dem Programm selbst anschauen konnte, da sie im Binärformat gespeichert waren. Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht. Zum Beispiel bei meiner Wetterstation werden alle 300s die Daten gespeichert (pro Datensatz 52 Werte) und die werden selbstverständlich nicht als Text sondern in einer Datenbank gespeichert. Derzeit sind sind ca. 7100 Datensätze gespeichert bei einer Datenbankgröße von 1,5MB. Und ja man kann sich das mit den passenden Tools, tabellarisch aufbereitet ansehen, allerdings ist das eher ein mühsames Geschäft. Ich stelle mir gerade vor das als ne Textdatei gespeichert und dann mit dem vi angeschaut, dannach wäre man dann reif für die Klappse.
udok schrieb: > Wir leben auch nicht mehr in den 90'ern. Stimmt, Du lebst sogar noch in den 1970'zigern, da wurde der vi erfunden, also zu einer Zeit wo Speicherplatz noch knapp war und das Datenaufkommen in Byte oder kB gemessen wurde.
Beitrag #7124925 wurde von einem Moderator gelöscht.
Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt, dass es eine ältere Version war.
Aber sicher keine von 1990. :)
Alles danach wurde doch nur noch auf VM-Systemen benutzt.
MS-DOS mit gerade mal 64 KiB linear adressierbarem Adressbereich ist nun
so ziemlich das letzte, was man irgendwie als Referenz benutzen würde.
Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt,
Du sagst ziemlich viel, wenn der Tag lang... okay, vergiß das mit dem
Tag. ;-)
Zeno schrieb: > Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit > einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht. Das könnte auch gzipped CSV, JSON oder YAML sein. Dafür gäbe es schon fertige Frontends, Libraries und Tools. Gerade bei großen Datenmengen ist es aufwändig und daher meistens ziemlich dumm, das Rad neu erfinden zu wollen. Meine Güte!
Kiffer schrieb: > Meine Güte! Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie sie sich ihre Arbeit organisieren.
Kiffer schrieb: > Das könnte auch gzipped CSV, JSON oder YAML sein. Klar groß, größer, am größten - für sehr große Datenmengen sind Textdateien ungeeignet. JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt. Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung, und da sind die Datenmengen eher überschaubar.
Zeno schrieb: > Klar groß, größer, am größten - für sehr große Datenmengen sind > Textdateien ungeeignet. > JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man > sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt. > Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung, > und da sind die Datenmengen eher überschaubar. Sieh an, Pippi Langstrumpf erklärt uns die Welt. Selbstverständlich ist JSON für die Speicherung von grossen Datenmengen geeignet und wird dafür benutzt. Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel mit den Werten kostet kaum Overhead und kann prima als Stream verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und getestete, stabile und performante Tools und Libraries dafür, die man nutzen oder drauf aufbauen kann. Solche Eigenschaften müsstest Du mit Deinem unprofessionellen Gebastel erstmal hinbekommen, kleiner Held.
Jörg W. schrieb: > Kiffer schrieb: >> Meine Güte! > > Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie > sie sich ihre Arbeit organisieren. Hab' ich das? Nö. Die einzigen, die hier anderen etwas vorschreiben wollen, sind Na-no und Ze-no. Hast Du da vielleicht etwas verwechselt?
Kiffer schrieb: > Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header > mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel > mit den Werten kostet kaum Overhead und kann prima als Stream > verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und > getestete, stabile und performante Tools und Libraries dafür, die man > nutzen oder drauf aufbauen kann. Das ist ja alles nicht durchaus richtig, aber kannst Du nicht bitte einfach mal auf die Provokationen verzichten? In diesem Thread ist schon genug provoziert worden, simple Besserwisserei sollte fürderhin reichen.
Beitrag #7125414 wurde von einem Moderator gelöscht.
Nano schrieb im Beitrag #7125414: > Lass mich raten, du gehörst zu denen, die sich aus ganz vielen Ecken > dutzende Bibliotheken für die kleinste Funktion ins Projekt einbinden, > weil du das alles nicht selber programmieren kannst und dann prahlst du > hier auch noch damit herum es besonders ineffektiv zu machen. Peinlich! Erwartbar falsch geraten. Mit ein bisschen Erfahrung lernt man, sinnvolle Entscheidungen zu treffen, wann man etwas selbst entwickeln, testen und pflegen sollte, und wann das zu etwas führt, das erfahrene Entwickler als NIH-Problem kennen. Nur Anfänger glauben, alles besser zu können als der Rest der Welt. Weißt Du, Hybris gehört zwar nach Larry Wall, dem Erfinder der Sprache Perl, zu den Kardinaltugenden guter Entwickler. Faulheit aber auch! > Und JSON IST ineffizient für große Datenmenge, da ist sogar CSV um > Welten besser! > JSON ist für kleine Datenmengen gedacht, in erster Linie dafür, wo man > normalerweise XML einsetzen würde. Wo steht das? Wer sagt das? Du? > JSON ist effizienter als XML, aber > bei mehren hundert MB ist es immer noch höchst ineffizient. [ ] Du hast den Teil mit der Komprimierung verstanden. [ ] Du hast den Teil mit dem Datenformat verstanden. > Also arbeite mal an deinem Umgangston, Na das sagt der Richtige.
Endlich! vim 9 ist in Debian sid angekommen. Jetzt steht der weiteren Verwendung nichts mehr im Wege, die Nutzerbasis wird sich erhöhen. Andere Distributionen werden nachziehen. Die Bugbereinigung wird anlaufen. Der tolle Editor lebt weiter. Aber der Resourcenverbrauch hat ja vom einstigen Editor für Minimalisten ordentlich zugelegt. Wer eine schlankere Version bevorzugt, kann es mit vim-tiny versuchen.
Max Mustermann schrieb: > Endlich! > vim 9 ist in Debian sid angekommen. Am Mittwoch letzter Woche bereits – du bist zu langsam. Und am Samstag wurde die Version in Testing aufgenommen – dessen Userbasis ist ja doch ungleich größer, als die von Unstable.
Max Mustermann schrieb: > Endlich! > vim 9 ist in Debian sid angekommen. > ... > Andere Distributionen werden nachziehen. Der Nachzügler ist – nach über 5 Wochen – wohl eher Debian selber. Zum Vergleich: Arch hat dafür 5,7 Stunden gebraucht :)
42 schrieb: > Arch ist bei Aktualisierungen immer top. Nein, nicht immer. Siehe beispielsweise Cura – das ist nun schon drei Monate veraltet.
Siggi schrieb: > Wann wird wohl Ubuntu und Linux-Mint nachziehen? Die neuste Version von vim ist für Mainstream-Distries einfach unwichtig. Standardmäßig haben die ohnehin nur vim-tiny. So als Backup-Lösung wenn die GUI nicht funktioniert und man deshalb keinen richtigen Editor verwenden kann.
Nico schrieb: > und man deshalb keinen > richtigen Editor verwenden kann. Was ist ein richtiger Editor?
Roman schrieb: > Was ist ein richtiger Editor? Kate, Bluefish, VScode, Ultraedit, notepad++(Windows) Minimalistisch für console: nano, pico, joe
Nano schrieb: > Oben habe ich in meinem Beitrag > Beitrag "Re: Vi Editor ausgestorben?" > > ja ausführlich und argumentativ begründet, warum man für Messdaten keine > einzige große Datei nutzen sollte. Du schreibst in dem verlinkten Beitrag: Nano schrieb: > Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, > dann sollte man über ein Binärformat und ein Programm, über das man auf > diese zugreift und das diese aufbereitet, nachdenken. > Grund: > Ein Binärformat spart viel mehr Platz und ist für einen Computer viel > besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm > schreibt, gleich noch daran denken, die Daten noch zu komprimieren. In dieser Argumentation fehlen mir einige praktische und ökonomische Perspektiven. Ja, Textdat(ei)en sind vielleicht um einen Faktor zwei bis fünf größer, dafür aber sofort und ohne weiten Investitionsaufwand für die Softwareentwicklung von jedem Menschen lesbar. Es gibt eine riesige Vielfalt fertiger, leisungsfähiger und sehr feingranular konfigurier- und steuerbarer Programme, um Textdat(ei)en anzeigen und verarbeiten zu können, denk nur mal an grep(1), sed(1), awk(1), oder an perl(1), oder auch gnuplot(1) oder die Programme aus dem graphviz-Paket. Oder an Pandas in Verbindung mit Matplotlib, Seaborn, Plotly oder Bokeh, um nur ein paar Beispiele aufzuführen. Obendrein sind Textdat(ei)en flexibler als Binärdat(ei)en, das heißt: in einer Textdatei kann ich ohne Weiteres verschiedene Logformate speichern und anschauen (denk nur mal an die Systemlogs unter Linux und UNIX), während das bei binären Dateien zwar machbar, aber mit wesentlich mehr Aufwand verbunden ist -- welcher obendrein bei jeder Änderung erneut anfällt. Wenn der, der die Daten verarbeiten soll, dann vielleicht nicht identisch mit dem Softwareentwickler ist, werden Deine Binärdat(ei)en sehr schnell zu einem bösartigen ökonomischen Problem. Meinen Rechner riesige Textdat(ei)en durchsuchen, verarbeiten, anzeigen zu lassen, kostet mich wenig. Einen Softwareentwickler an die Entwicklung eines Binärformates und dann bei jeder Änderung wieder daran zu setzen, kostet mich hingegen erstens Zeit und zweitens Geld. Und wenn mal ein Sensor spinnt und kaputte Daten in eine Binärdatei schreibt, ist womöglich die ganze Datei mit allen Daten verloren, wenn ich nicht schon wieder viel Geld ausgeben und einen Entwickler daran setzen will. Nano schrieb: > Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf, > dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier > zu großen Verlusten führen. Dieses Argument zieht nur, wenn die Daten auch dann nützlich sind, wenn sie nur in Teilen vorliegen. Bei vielen Messungen haben die Daten aber nur dann einen Wert, wenn sie über die gesamte Messung hinweg durchgängig vorliegen. Das heißt: wenn die Aufzeichnung wegen eines Ausfalls mitten während der Erhebung der Daten endet, ist der gesamte Test inklusive aller erhobenen Daten nutz- und wertlos. > Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei > schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust > mehr Sicherheit und das erlaubt dann auch die alten Dateien zu > komprimieren und so Speicherplatz zu sparen. Textdat(ei)en kann man auch komprimieren, wußtest Du das schon? Meistens sogar mit ziemlich guten Kompressionsraten... Mein grundsätzliches Herangehen an solche Datenmengen ist allerdings ohnehin ein gänzlich anderes: egal, wie ich die Dat(ei)en bekomme, pumpe ich sie sofort in meinen Opensearch-Cluster. Nicht, weil der die Daten dann binär speichert, sondern weil der extrem performant und obendrein hochverfügbar ist, meine Daten direkt und trotzdem strukturell flexibel in revertierten Indizes speichert, die sich wiederum unfaßbar schnell durchsuchen, wunderbar mit Opensearch-Dash visualisieren, oder mit allen möglichen Programmier- und Skriptsprachen weiterverarbyten lassen. Deswegen kann ich bei Eurem Gespräch über Speicherformate von Massendaten nur bedauernd mit dem Kopf schütteln -- und dabei vor allem darüber, daß Du die inhärenten Vorzüge von Textdat(ei)en entweder nicht (an)erkennen willst oder nicht kennst. Dateien, Jungs, echt mal... das ist doch total Neunziger. ;-) Zuletzt sei eine Kleinigkeit angemerkt, die Du anscheinend ebenfalls aus Deinen Augen verloren hast. Nämlich, daß man als Profi oft gar keine andere Wahl hat, als Daten so zu verarbeiten, wie man sie bekommt.
Ein T. schrieb: > egal, wie ich die Dat(ei)en bekomme, pumpe > ich sie sofort in meinen Opensearch-Cluster. Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht, dass Data-Mining generell uninteressant ist. Geht aber auch etwas besser mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich Kunstprodukte ein. Das passiert zwar auch bei wichtigen Gutachten - naja, sehr viele Leute sind nicht gut in Statistik (trotz der entsprechenden guten Ausbildung), und ich eigentlich auch nicht, wenn ich mir keine Mühe gebe - ist trotzdem nicht schön, und so wohl eher ein Grund zum schmunzeln trotz des düsteren Hintergrundes.
rbx schrieb: > Ein T. schrieb: >> egal, wie ich die Dat(ei)en bekomme, pumpe >> ich sie sofort in meinen Opensearch-Cluster. > > Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht, > dass Data-Mining generell uninteressant ist. Verrätst Du mir, wie Du an dieser Stelle auf "Data Mining" kommst? War es das Stichwort "Cluster", das Dich getriggert hat, oder wie kam das zustande? Im Kern geht es erst einmal darum, die Daten möglichst schnell und möglichst unaufwändig mir und den Kollegen zugänglich zu machen, damit wir mit den Daten arbeiten können. Dafür werden wir nämlich bezahlt. Vielleicht magst Du Dir die Software mal näher anschauen, um zu verstehen, was sie leistet und was nicht. > Geht aber auch etwas besser > mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich > Kunstprodukte ein. Schon der erste Schritt, nämlich die explorative Datenanalyse (EDA), kann ohne fundierte Kenntnisse der Statistik nicht funktionieren, und für jede Tätigkeit im Bereich des Data Mining gilt dasselbe. Ich bin daher äußerst irrigiert, wie man da irgendwelche Widersprüche ausmachen kann. Kann es sein, daß Du Dich mit Data Mining nicht wirklich auskennst und daher einigen (durchaus populären) Mißverständnissen aufgesessen bist? Oder, anders gefragt: was glaubst Du eigentlich, was wir im Data Mining so machen, wie das funktioniert und, vor allem, wie das ohne fundierteste Kenntnisse in Statistik gehen könnte?
Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Hauptsache irgendwelche vagen Andeutungen machen, damit keiner weiß worum es geht und man dann anderen Ahnungslosigkeit vorwerfen kann? Oder warum antwortet man überhaupt darauf, wenn gar nicht klar ist, worum es geht? Ein Troll gegen den anderen Troll.
prust schrieb: > Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Nach 'nem Monat Pause hat sich wieder jemand an einer (längst widerlegten) Aussage betreffend der Verwendung von großen Textfiles hochgezogen,
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.