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... "\(".)/"
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.