Forum: PC Hard- und Software Vi Editor ausgestorben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Openbsd (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die 
ultimativen Vorzuege dieses Editors?


Wenn nein, warum nicht?

von A. K. (prx)


Bewertung
7 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
5 lesenswert
nicht lesenswert
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.

von User (Gast)


Bewertung
0 lesenswert
nicht lesenswert
VIM hat Features die andere Editoren nicht haben, z.B. CTRL-X CTRL-F 
direkt im Editor nach Dateinamen suchen.

von zitter_ned_aso (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Schetiphist (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
User schrieb:
> z.B. CTRL-X CTRL-F
> direkt im Editor nach Dateinamen suchen.

na klar ;-)

von ich (Gast)


Bewertung
7 lesenswert
nicht lesenswert
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).

von olibert (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Rolf R. (dankobum)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Walter K. (walter_k488)


Bewertung
1 lesenswert
nicht lesenswert
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

von vive la vi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Jack V. (jackv)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Emil Epsilon (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Vim as a Python IDE - Martin Brochhaus"

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Andi schrieb:
>   (Und das schon seit >30j)

Den gibts seit 43 Jahren und er stammt von einem Gründer von Sun 
Microsystems.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von oszi40 (Gast)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
*Weil vi lokal nützlich beim Kaffeetrinken ist.
Die Tastatur sollte trocken bleiben. Sonst ändert sich das Layout!

von Andi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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... ;)

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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... 
;-)

von Eric (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
1 lesenswert
nicht lesenswert
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
von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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, 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
von JJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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:

  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.

von JJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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;-)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
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
von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von P. S. (namnyef)


Bewertung
0 lesenswert
nicht lesenswert
Nur wenn ich auf meinem Linux-Server (keine GUI) ein paar Zeilen in 
einem config-file o.ä. ändern muss.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
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
von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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 :)

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Hans Müller (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Hans Müller schrieb:
> Da drin sollten in Zeile 212556 ein paar Worte geändert werden.

Kenner verwenden dafür "sed". ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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"

:-)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wieviel Tausend Zeilen Code schreibt ihr denn pro Tag?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von michael_ (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von rbx (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.)

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
dann braucht man aber meistens auch keine Sonderzeichen.

von michael_ (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von michael_ (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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 :-)

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
Na endlich geht der Thread in die Richtung die sich der TE gewünscht 
hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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. :)

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von JJ (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
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.

von svensson (Gast)


Bewertung
5 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
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
von Roland F. (rhf)


Bewertung
1 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber heute könnte ich EDT vermutlich nicht mehr bedienen. ;-)

Zur Auffrischung die Belegung des Nummernblocks ;-)
+-----------------+------------------+------------------+------------------+
|       PF1       |        PF2       |        PF3       |        PF4       |
|                 | Schrittw. Suche  |  Suche nach ...  |  Zeile einfügen  |
|      GOLD       |      Hilfe       |  Suche weiter    |  Zeile löschen   |
+-----------------+------------------+------------------+------------------+
|  Kommando ...   |                  |     Ersetzen     |  Wort einfügen   |
|  Nächste Seite  |   Blättern v/z   | Anhängen Zw.-Sp. |  Wort löschen    |
+-----------------+------------------+------------------+------------------+
|     Textende    |    Textanfang    | Zw.-Sp. einfügen | Zeichen einfügen |
|     Vorwärts    |    Rückwärts     | Zwischenspeicher | Zeichen löschen  |
+-----------------+------------------+------------------+------------------+
|                 | Lösch.Rest Zeile |                  |   Ersetzen und   |
| Wort vor/zurück | Zeilenende v/z   |   Rollen Zeile   |   Weitersuchen   |
+-----------------+------------------+------------------+                  |
|             Leerzeile              |  Mark. aufheben  | Enter mit Indent |
|      Zeilenanfang vor/zurück       |     Markieren    |                  |
+------------------------------------+------------------+------------------+

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
von JJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von udok (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Lasst doch den armen vi endlich ruhen!

Diese Leichenfledderei ist ja nicht auszuhalten.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
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"

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
Der vi wird uns alle überleben…

Der wird noch laufen, wenn es keine Computer mehr gibt. Notfalls auf 
einem Toaster.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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
von zitter_ned_aso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
bis eclipse gestartet ist, ist vim mit coc schon fertig ;-)

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
zitter_ned_aso schrieb:

> WEnn man C-Libs verwendet, dann hat man unter Eclipse keine
> Autoverfollständigung.

Blödsinn.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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? :)

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. :-)

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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ß.

von zitter_ned_aso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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..

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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. 
;-)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von Andi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von zitter_ned_aso (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
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
von Walter K. (walter_k488)


Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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
von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Ich weiß nicht, warum so ein Bohei um die Trailing Whitespaces gemacht 
wird. Da macht man einmal ein
: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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. :)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Geht mir auch so. :-)

von 900ss D. (900ss)


Bewertung
0 lesenswert
nicht lesenswert
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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.)

von Arno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
...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

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
900ss D. schrieb:
> Weshalb möchtest du diese sehen? Also im Quellcode?

Wenn hinter einem \ wahlweise ein Leerzeichen oder ein [CR]LF steht.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.)

von 900ss D. (900ss)


Bewertung
1 lesenswert
nicht lesenswert
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
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
                 "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
von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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:
$ ps aux | fgrep emacs
j           1568   0.0  0.1   206172   40236  -  S    14Nov19     25:04.06 emacs (emacs-26.1)
j          57361   0.0  0.0     6652    2556  6  S+   18:00        0:00.00 fgrep emacs
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. ;-)

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Nano schrieb:
> Tabs sind keine Whitespacezeichen.

Doch eigentlich schon. Zumindest in den meisten gängigen Sprachen.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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>. :)

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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
von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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:
>
>
> $ ps aux | fgrep emacs
> j           1568   0.0  0.1   206172   40236  -  S    14Nov19 
> 25:04.06 emacs (emacs-26.1)
> j          57361   0.0  0.0     6652    2556  6  S+   18:00 
> 0:00.00 fgrep emacs
> 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. ;-)

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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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
von Andi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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
von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
Andi schrieb:
> Viele Wege führen nach Rom ;)

Ein weiterer: 1,$ lässt sich als % abkürzen, also :%s/...

: Bearbeitet durch User
von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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;-)

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.
von Egon D. (egon_d)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von rbx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
-7 lesenswert
nicht lesenswert
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

von A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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". ;-)

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uhu U. (uhu)


Bewertung
-3 lesenswert
nicht lesenswert
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 ;-)

von Udo K. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
> [ü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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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! ;-)

von Max H. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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)

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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. ;-)

von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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... "\(".)/"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.