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.
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.
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.
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?>>> Wenn nein, warum nicht?
Weil ich mir die Shortcuts nie merken kann (und Nano besser ist).
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum?
Weil ich den gleichen Editor auf AIX, Solaris, BSD und Linux vorfinde
und nicht lange ueber Tastenkombinationen nachdenken muss. Allerdings
trifft das auch auf Emacs zu.
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?>>> Wenn nein, warum nicht?
vi beherrsche ich zwar, bin dabei aber nicht sicher. nano ist einfacher
und deshalb nutze ich diesen, wenn ich einen Editor im shell-Fenster
brauche.
Ansonsten nutze ich unter Linux gedit oder nedit.
olibert schrieb:> Allerdings trifft das auch auf Emacs zu.
Nicht, wenn das erste Unix ein Microport Unix für 286 war.
EMACS = eight megabytes and constantly swapping.
Allerdings verwende ich üblicherweise tatsächlich den Emacs, customized.
Aber ich hau den nicht jedesmal drauf, wenn ich bloss einen Editor für
Configfiles brauche.
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum?
Inzwischen mehr neovim
Warum? Na weil notepad++ für PowerUser gemacht wurde - und Nano für VHS
Dozenten und BWLer
zitter_ned_aso schrieb:> User schrieb:>> z.B. CTRL-X CTRL-F>> direkt im Editor nach Dateinamen suchen.>> na klar ;-)
In einer z.B. kde-edelkonsole mglw. schon ;)
sonst halt wie üblich vlt. via Shellbefehl :!find ... :!locate ...
Ergebnis gleich einlesen :read :r bzw. :r!xy
:r!xy dann steht das Ergebnis der Aktion im Buffer
oder man schickt das in den Hintergrund mit Ctrl-Z und macht was
anderes.
Solange es noch Leute gibt denen systemd am init vorbeigeht wird der
gebraucht ;)
Seit emacs ist vi obsolet! Das kann man überall im Usenet nachlesen!
Ernsthaft: das erste, was ich bei Systemen mache, die den vi mitbringen:
ich ersetze ihn durch den Vim und erstelle einen Symlink namens vi.
Insofern muss ich im Sinne des Eingangsposts sagen: nein, ich arbeite
nicht mehr mit dem vi.
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi?
Ja!
>Wenn ja, warum?
Falsche Frage! Die Frage ist "Wann arbeitet man mit dem vi?" dann
erübrigt sichFrage:
> Was sind die> ultimativen Vorzuege dieses Editors?
Ich benutzt den vi wenn ich remote bspw überne ssh arbeite. Also zur
Bearbeitung von Konfigurationsdateien, logs durschauen auf einem
Headless system oder sourcen auf einem built-Server beacker. vi braucht
halt wenig Bandbreite im Vergleich zu den Pixel-Gui-Editoren und es gibt
ihn für quasi jedes system, nicht nur für Windows/DOS Tipp-Prothesen.
Manche schätzen, das man den vi komplett ohne Mouse nutzen kann. Das
reisst den geschickten Tipper nicht aus dem Flow. Und man kann den vi
auch zur IDE pushen mit multiple windows, diff und compile from editor:
https://www.youtube.com/watch?v=YhqsjUUHj6g
Openbsd schrieb:> Was sind die> ultimativen Vorzuege dieses Editors?
1. Recht vielseitig und kann man in der Konsole benutzen (toll z.B. für
Windows (kommt u.a. mit Watcom-Compiler Installation)).
2. Ziemlich gut standardisiert - bzw. muss man normalerweise nicht erst
groß nachinstallieren oder nach Alternativen suchen.
3. Sehr schnell für Powerhacker wie Spieleprogrammierer z.B.
4. kleine Challenge (hatte mal an der Uni angefangen: wie kommt man aus
diesem Editor heraus??)
5. Nettes recht verfängliches Tutorial für Vim auf Linuxen - kommt
normalerweise per Eingabe: vimtutor de
6. Macht auch irgendwie Spaß, wenn man merkt, dass es besser wird
7. Nette Kaffee-Tasse (Vi Bild von ct):
https://www.heise.de/ct/ftp/08/16/184/
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?
* Weil er auf jedem *NIX on board ist.
* Weil es ihn auch für alle anderen OS gibt.
* Weil er überall (annähernd) gleich funktioniert.
(Und das schon seit >30j)
* Weil man mit ihm sehr schnell und effizient arbeiten kann.
(Finger können auf der Tastatur bleiben)
Allerdings (zumindest meiner Erfahrung nach) Voraussetzung:
* US Keyboardlayout
Was zur Situation führt dass man, wenn man zwischen Textverarbeitung,
Email, ... und Programmierarbeiten wechselt, immer das Keyboardlayout
wechseln muss. (Was ja seit Win7 auch auf Windows sehr einfach geht.)
Und natürlich, dass man sich angewöhnt beim Tippen nicht mehr auf die
Tasten zu schauen ;)
BTW: Weiß zufällig jemand wie man unter Windows ein bestimmtes
Keyboardlayout an eines oder mehrere Fenster binden kann?
Andi schrieb:> 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.
A. K. schrieb:>> * US Keyboardlayout>> Die Zeichen sind immer die gleichen, nur die Position auf der Tastatur> nicht. Hängt also davon ab, ob man sich die Position merkt, oder das> Zeichen.
Das ist natürlich richtig.
Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach
effizienter zu erreichen.
Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit
deutschem Layout programmieren kann.
Man merkt eben dass ich aus einer Zeit stamme, wo man anfangs nur
US-Tastaturen an Terminals kannte ;)
Wie lästig war das damals als die ersten VT100-Terminals mit Deutscher
Tastatur auftauchten... ;)
Andi schrieb:> Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach> effizienter zu erreichen.
Auch, wenn’s OT ist: mit Neo2 ist’s noch viel effizienter erreichbar,
gar nicht zu reden von {} und [] und so Sachen. Damit funktioniert zwar
wieder die hjkl-Navigation nicht gescheit, im Gegenzug hat’s aber auch
direkt aus der Grundstellung heraus erreichbare Cursortasten auf der
vierten Ebene, so dass man die vi-Navigation auch nicht braucht.
Zumindest im Vim nicht, vi in der Urversion kann ja mit den Cursortasten
nicht so richtig.
Andi schrieb:> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit> deutschem Layout programmieren kann.
Ich auch nicht. In frühen Jahren - das war vor der PC Dominanz -
verwendeten ein Freund und ich an einem 68000 Eigenbau-Rechner mit
Eigenbau-OS eine Async-Tastatur mit Eigenbau-Layout auf US Grundlage.
Damals konnte man Tastaturen vergleichsweise günstig kundenspezifisch
angepasst kaufen. Und den AIM65 davor gab es sowieso nur in US-ASCII.
Auf eine 16-Segment LED kriegst du keine Umlaute drauf.
Irgendwann setzte sich dann aber doch der PC durch, es wurde Deutsch und
der Zeichencode normiert. Ich habe mich aber nie an ß gewöhnen können
und verwende weiterhin ziemlich konsequent ss. Ausser dort, wo so
Grammar-Nazis wie Autokorrektoren partout auf ß bestehen.
Andi schrieb:> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit> deutschem Layout programmieren kann.
Ich auch nicht. Seit ich eine deutsche Tastatur habe, habe ich daher ein
Keyboard-Mapping, bei dem die äöü-Tasten [\]/{|} geben und nur dann die
Umlaute, wenn man zugleich AltGr drückt (das passt gut mit dem rechten
Daumen zusammen).
Damit kann zwar sonst niemand schreiben außer mir :), aber ich habe auf
diese Weise beide Welten. Unter MS-DOS brauchte es dafür noch so'n
doofes TSR-Programm, seit Unix geht das einfacher und direkt im OS /
X11.
Openbsd schrieb:> Vi Editor ausgestorben?
Vi hat außerhalb kommerzieller Unix-Systeme kaum Verbreitung erlangt, da
sein Quellcode erst seit 2002 frei (sowohl wie Beer als auch wie
Freedom) verfügbar ist und es zu diesem Zeitpunkt schon jede Menge
leistungsfähigere (und teilweise zu Vi abwärtskompatible) Editoren gab.
Ausgestorben ist er deswegen aber noch nicht, den Quellcode gibt es
hier
https://github.com/n-t-roff/heirloom-ex-vi
und seine Söhne (Vim, Elvis, Nvi usw.) erfreuen sich nach wie vor großer
Beliebtheit.
> Arbeitet von euch noch jemand mit dem vi?
Mit Vi nicht, aber mit seinen Nachfolgern.
> Wenn ja, warum?
Jedenfalls nicht, weil es beim ersten Kontakt sofort gefunkt und so
etwas wie Liebe auf den ersten Blick stattgefunden hätte :)
Sondern deswegen:
Ich verwendete Vi erstmals auf einer Sun-Workstation. Das geschah aber
eher aus der Not heraus, weil auf diesem Rechner sonst kein tauglicher
Editor installiert war.
Privat verwendete ich auf dem Amiga den mit dem Aztec-C-Compiler von
Manx mitgelieferten Vi-Klon Z, der für damalige Verhältnisse recht
leistungsfähig war und sogar Ctags unterstützte. Auch hier gab es für
mich kaum Alternativen. Emacs konnte zwar noch mehr, war aber auf den
16-Bit-Homecomputern wie dem Amiga oder Atari ST wegen des zu großen
RAM-Bedarfs nicht lauffähig (diese Rechner hatten weder Eight Megabytes
noch Swap-Space ;-)). Für kleine Computer gab es nur den µEmacs, der
aber so stark abgespeckt war, dass ich lieber beim Z blieb.
Nachdem ich mich an die Bedienung von Vi und Z gewöhnt hatte und es
Vi-Klone für praktisch jede Plattform gibt, auf der ein Editor überhaupt
Sinn macht, war es naheliegend, weiterhin auf dieser Schiene zu fahren.
Etwas anderes benutze ich nur noch in Ausnahmefällen.
Wenn ich die Wahl habe, nehme ich den Vim, der der mächtigste Vi-Sohn
sein dürfte. Da er (ggf. mit Plug-Ins) alles kann, was ich von einem
guten Editor erwarte, schaue ich mich nur noch sehr sporadisch nach
Alternativen um. Diese gibt es zwar mittlerweile durchaus, sie sind aber
für meine Bedürfnisse maximal ebenbürtig zum Vim, weswegen ein Umstieg
mit dem damit verbundenen Einarbeitungsaufwand verschwendete Zeit wäre.
Sogar die Busybox, die oft auf schmalbrüstigen Embedded-Systemen
eingesetzt wird, enthält neben Ed einen (abgespeckten) Vi.
Kurz: Mit Vi & Co. ist man einfach überall zu Hause :)
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?
In meinem Admin-Team arbeiten vier von fünf Leuten mit dem vim und einer
(moi) mit dem GNU Emacs. Sie können alles, was man von einer modernen
IDE oder Editor erwartet, Syntaxhighlighting natürlich sowieso, aber
auch Autocompletion, Codenavigation, Refactoring... und für uns ist
einer der wesentlichen Vorzüge, daß man sie auch auf der Kommandozeile
über dünne Netzwerkverbindungen nutzen kann. Und hie und da nutze auch
ich den vi(m), einfach weil er auf jedem UNIXoiden System verfügbar ist
und ich nicht überall einen Emacs installieren darf, kann oder will.
> Wenn nein, warum nicht?
Naja, einem Einsteiger würde ich eher Atom, Sublime, Visual Studio Code,
UltraEdit, Kate, gedit oder einen anderen moderneren Editor empfehlen --
einfach, weil sie die auch unter anderen Programmen üblichen Shortcuts
und Menüführungen verwenden, und dadurch die Lernkurve häufig flacher
ist. Aber sonst, why not? Ist halt noch ein Stück altes UNIX-Feeling...
;-)
Ich arbeite taeglich damit. Wie schon einige geschrieben haben, es ist
auf allen unixoiden Systemen vorhanden und mit Linux, BSD, Solaris, AIX
habe ich taeglich zu tun. Privat nutze ich allerdings auch vim.
> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit> deutschem Layout programmieren kann.
Ich auch nicht. Deshalb habe ich auch immer noch meine englische
IBM-Tastatur aus den 80ern. Ich wuesste auch keinen Grund wieso ich
daran etwas aendern sollte.
Aber es spricht natuerlich auch nichts dagegen deutsche Tastaturen
einfach auf englisch umzuschalten. Man muss ja beim schreiben nicht auf
die Tasten schauen. .-)
Olaf
Ich benutze auch keinen vi, aber vim sehr häufig, sowohl lokal als auch
remote per ssh - zuhause und am Arbeitsplatz.
Manche Kollegen nutzen von Zeit zu Zeit vi, wenn sie was auf der
Kommandozeile editieren müssen. Allerdings nur, weil sie nicht wissen,
dass es durchaus signifikante Unterschiede zu vim gibt.
Auf meinem Android-Handy habe ich mir die App "VimTouch" installiert. Da
ich dort aber eigentlich nie einen Texteditor brauche, nutze ich die gar
nicht. Außerdem ist es per Touchscreen vermutlich nicht sehr bequem zu
bedienen. ;-)
Jörg W. schrieb:> Wenn ich mal irgendwo schnell paar Zeilen ändern muss, dann auch "vi"> (wobei es mir dann ziemlich egal ist, was für eine Implementierung sich> hinter diesen beiden Buchstaben verbirgt).
Naja, vim ist schon deutlich besser als vi. Letzterer kann z.B. beim
undo nur eine Stufe und kann im Edit-Mode nicht per Cursor-Tasten
navigieren.
Alleine das sollte schon als Grund reichen, eher vim zu verwenden.
Sheeva P. schrieb:> Naja, einem Einsteiger würde ich eher Atom, Sublime, Visual Studio Code,> UltraEdit, Kate, gedit oder einen anderen moderneren Editor empfehlen --> einfach, weil sie die auch unter anderen Programmen üblichen Shortcuts> und Menüführungen verwenden, und dadurch die Lernkurve häufig flacher> ist. Aber sonst, why not? Ist halt noch ein Stück altes UNIX-Feeling...> ;-)
Es gibt auch noch gvim. Da hat man dann auch Menüs und Toolbars und so
Zeug. Und da steht bei den Menüeinträgen auch wie von anderen
GUI-Programmen gewohnt die Tastenkombinationen dahinter. Das kann beim
Einstieg helfen.
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.
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.
Andi schrieb:> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit> deutschem Layout programmieren kann.
Deshalb hatte damals auch Pascal hierzulande eine viel stärkere
Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout
einfach viel angenehmer von der Hand als C.
Bernd K. schrieb:> Deshalb hatte damals auch Pascal hierzulande eine viel stärkere> Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout> einfach viel angenehmer von der Hand als C.
Wobei man beim Programmieren auch ab und zu mal denken sollte, nicht nur
tippen. ;-)
Mir passiert es gelegentlich, dass ich schnell einen Text oder Quellcode
im Editor meiner Wahl, z.b. UEStudio oder joe, verfasse und der Compiler
sich anschließend über die Zeichenfolge :wq beschwert.
Bernd K. schrieb:> Deshalb hatte damals auch Pascal hierzulande eine viel stärkere> Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout> einfach viel angenehmer von der Hand als C.
Aber nur, wenn man die Kommentare mit
1
(* *)
schreibt, sonst hat man ja das gleiche Problem. Pascal habe ich aber
ohnehin vorrangig zu Zeiten benutzt, da ich sowieso noch eine englische
Tastatur hatte.
Rolf M. schrieb:> Alleine das sollte schon als Grund reichen, eher vim zu verwenden.
Nö, wenn ich das alles brauche, habe ich auch einen Emacs in Reichweite.
:-)
Den [n]vi[m] nehme ich vor allem dann, wenn es keinen Emacs gibt oder
der Job wirklich so klein ist, dass es auf irgendwelche besonderen
Features nicht ankommt.
Habe Anfang der 1990er in einem Laden gearbeitet, wo alles mit Unix
gemacht wurde (DG/UX, kennt heute keiner mehr). Meine Kollegen benutzten
alle fleißig den vi (noch den "richtigen"), und ärgerten sich oft genug
mehr oder weniger damit 'rum. Ich bin damals ziemlich schnell beim Emacs
gelandet, war aber von den Kollegen wohl trotzdem noch derjenige, der am
Ende die meisten vi-Kommandos kannte. ;-)
Linux/Unix Admin hier, ich benutzte vim jeden Tag als mein Hauptwerkzeug
weil er
- überall installiert ist
- klein und schnell ist
- im Terminal bzw. in SSH Sessions Funktionen liefert die üblicherweise
GUI Editoren vorbehalten sind.
In letzter Zeit kommt immer mal wieder EMACS dazu, weil ich den org-mode
für mich entdeckt habe.
Jörg W. schrieb:> Bernd K. schrieb:>> Deshalb hatte damals auch Pascal hierzulande eine viel stärkere>> Anhängerschaft als irgendwo sonst, es ging (und geht) mit unserem Layout>> einfach viel angenehmer von der Hand als C.>> Aber nur, wenn man die Kommentare mit>> ()>> schreibt,
... und wenn man Array-Indizes mit (. und .) klammert, also bspw. so:
1
a(.x.) := b(.x.)
Digraphen gibt es aber auch in C: <% und %> für die geschweiften, <:
und :> für die eckigen Klammern und %: für das #-Zeichen.
Bei mir ist mittlerweile das vordere Daumengelenk der rechten Hand in
einem 90°-Winkel fest verwachsen, so dass ich mit Daumen und Zeigefinger
problemlos die AltGr-Kombinationen für die geschweiften und eckigen
Klammern erreiche. Da brauche ich weder Digraphen noch eine englische
Tastaturbelegung ;-)
JJ schrieb:> In letzter Zeit kommt immer mal wieder EMACS dazu, weil ich den org-mode> für mich entdeckt habe.
Gibt es in ähnlicher Form auch für Vim:
https://github.com/jceb/vim-orgmode
Hab's aber noch nicht ausprobiert.
Wenn man sich mal verinnerlicht hat, dass der vi/vim ein Mode-basierter
Editor ist dies beim Arbeiten immer im Hinterkopf hat und sich immer
darüber klar ist, welchen Mode man gerade benutzt und auch noch weiss,
wie man sich zwischen den wichtigsten Modi bewegt... wird der vi/vim
nicht nur sehr logisch erscheinen sondern man lernt ihn schätzen.
Am Anfang gehört etwas Überwindung dazu, die Finger von der Maus zu
lassen (auch wenn die im vim natürlich längst unterstützt wird und sich
gerade im visual-mode anbietet ) und was noch viel wichtiger ist -und
was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten
zu lassen ( am besten die Pfeiltasten remappen ).
Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu
den Pfeiltasten zucken;-)
Walter K. schrieb:> und was noch viel wichtiger ist -und> was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten> zu lassen ( am besten die Pfeiltasten remappen ).> Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu> den Pfeiltasten zucken;-)
Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV. Diese
Tastenbelegung stammt noch aus einer Zeit als man noch elektrische
Schreibmaschinentastaturen in Terminals eingebaut hat. Überall sonst auf
der Welt wird mit den Pfeiltasten, Pagetasten, Home und End navigiert,
mit shift markiert und mit shift-del, shift-ins cut & paste. Das sitzt
vielen (mir auch) so tief im Muskelgedächtnis daß es schwer fällt sich
da nur für vim umzugewöhnen. Deshalb benutz ich den vim auch nur wenn
ich mal per ssh irgendwo in ner remote shell bin um 3 Zeilen in ner
Konfig-Datei zu bearbeiten, auf dem Desktop und zum längeren Arbeiten
dann doch lieber vscode.
Bernd K. schrieb:> Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV.
Ist er nicht, denn die Pfeiltasten funktionieren ja grundsätzlich.
Man muss ja nicht unbedingt solche Ratschläge aus dem letzten
Jahrtausend so bierernst nehmen. Auch ein Emacs hat aus historischen
Gründen seine eigenen Kommandos zur Navigation (C-P, C-N), aber ich kann
mich nicht dran erinnern, wann ich die das letzte Mal benutzt hätte.
Jeder normale Mensch nimmt die Cursortasten.
Jörg W. schrieb:> Jeder normale Mensch nimmt die Cursortasten.
Einspruch. Es ist erheblich bequemer, den Cursor bewegen zu können,
ohne die Hände aus der Grundstellung nehmen zu müssen. Natürlich nur für
die, die ihre Hände normalerweise in der Grundstellung haben – dann
ist’s allerdings deutlich spürbar.
Die, welche üblicherweise sowieso mit’m Zeigefinger in geringer Höhe
Suchkreise über den Tasten ziehen, werden vermutlich keinen Nachteil
darin sehen, die Hand zu den Cursortasten bewegen zu müssen.
Sorry: Quark.
Ich tippe seit Jahrzehnten mit 10 Fingern (habe ich schon vorm
Computerzeitalter mit der Schreibmaschine gemacht, wo es wirklich
Überwindung kostete, mit dem kleinen Finger den Wagen anzuheben). Wenn
ich den Text schreibe, habe ich die Finger auf der Haupttastatur liegen
– aber dann muss ich nicht groß navigieren (höchstens mal mit der
Löschtaste).
Wenn ich im Text hin und her navigiere, dann brauch ich nicht die 10
Finger auf der Tastatur, denn in erster Linie suche ich da irgendwas.
Jörg W. schrieb:> Sorry: Quark.
Halten wir fest: es gibt verschiedene Ansichten. Zumindest ein
Zehnfingerschreiber stört sich daran, zum Verschieben des Cursors die
Hände übermäßig bewegen zu müssen, und das bin ich. Wahrscheinlich gibt
es noch mehr – sonst hätten die Neolinge die Navigationstasten nicht auf
die Grundlinie gelegt, und in der Vi-Doku würde hjkl nicht als Feature
hervorgehoben. Insofern halte ich’s für etwas anmaßend, das mal eben
pauschal als „Quark“ abzutun, nur, weil man’s selbst nicht so empfindet.
Jack V. schrieb:> Insofern halte ich’s für etwas anmaßend, das mal eben pauschal als> „Quark“ abzutun.
Der „Quark“ war insbesondere die Reaktion auf deinen zweiten Absatz oben
– der implizit unterstellt, alle diejenigen, die Cursortasten benutzen,
wären zu blöd zum 10-Finger-Schreiben.
Hättest du dir den Absatz gespart, hätte ich gar nicht auf deine
Äußerung reagiert, da es in der Tat einfach nur verschiedene Meinungen
gibt.
Jörg W. schrieb:> Der „Quark“ war insbesondere die Reaktion auf deinen zweiten Absatz oben> – der implizit unterstellt, alle diejenigen, die Cursortasten benutzen,> wären zu blöd zum 10-Finger-Schreiben.
Entschuldige, aber deine Interpretation war in diesem Fall falsch.
Natürlich nutzen die meisten Zehnfingerschreiber die Pfeiltasten, weil
eben die wenigsten Programme eine andere Steuerungsmöglichkeit vorsehen,
und es käme mir nicht im Traum in den Sinn, sie deswegen als blöd
hinzustellen. Im Vi und seinen Ablegern (um wieder auf das Thema
zurückzukommen) gibt es aber eine Alternative auch für qwert-User, und
wenn diese sich drauf einlassen, könnten sie durchaus ’nen Komfortgewinn
erfahren. Die bringt nur keinerlei Vorteile für
Nichtzehnfingerschreiber, darauf war meine Aussage bezogen.
Die Verwendung von H, J, K und L als Cursor-Tasten gehen auf das
ADM-3A-Terminal zurück, auf dem der Vi-Entwickler Bill Joy, damals
gearbeitet hat und bei dem das (normalerweise in Kombination mit Ctrl)
tatsächlich die Cursor-Tasten waren.
http://xahlee.info/kbd/ADM-3A_terminal.html
Auf diesem Terminal war auch die Escape-Taste leichter erreichbar, und
für den Doppelpunkt (zum Umschalten in den Command-Mode) musste kein
Shift gedrückt werden. Auch die Tilde als Symbol für das Home-Directory
in Unix-Shells hat wohl dort seinen Ursprung.
Nachdem ich das gelesen habe, habe ich natürlich sofort Escape auf die
die Tabulator-, Ctrl auf die Caps-Lock-, Tab auf die linke Ctrl- und den
Doppelpunkt auf die Akzent-Taste gelegt. Damit flutscht es mit dem Vim
jetzt noch besser. Angenehm ist dabei vor allem, dass Escape nun auf
einer großen Taste liegt und man den Arm dafür nicht so weit ausstrecken
muss.
Auf die freigewordene Esc-Taste könnte man passend zu ihrer Beschriftung
das Shutdown-Kommando legen ;-)
Yalu X. schrieb:> Auf die freigewordene Esc-Taste könnte man passend zu ihrer Beschriftung> das Shutdown-Kommando legen
Irgendeine englische Tastatur (ich glaube, von älteren Suns) hatte dort
einfach nichts drauf stehen. Eignet sich gut für die berühmte
„anykey“. ;-)
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.
Bernd K. schrieb:> Die Existenz letzterer Gruppe> muss es sein die dafür verantwortlich ist daß sich vim so hartnäckig> hält.
Das denke ich nicht. Tatsächlich habe ich in meinem Umkreis noch nie
jemanden gehabt der seine Tastatur remappt.
(Wenn man von der Umschaltung de-en absieht)
Auch auf einer ganz normalen Belegung kann der vim seine Stärken
ausspielen.
Bernd K. schrieb:> Yalu X. schrieb:>> Nachdem ich das gelesen habe, habe ich natürlich sofort Escape auf die>> die Tabulator-, Ctrl auf die Caps-Lock-, Tab auf die linke Ctrl- und den>> Doppelpunkt auf die Akzent-Taste gelegt.>> Diese Aussage bestärkt mich in meiner Überzeugung daß es mindestens zwei> fundamental unterschiedliche Typen von Menschen zu geben scheint: ...> ... das ganze Gehirn scheint fundamental anders verschaltet zu sein.
Keine Angst, ich bin kein Alien. Die Änderung des Tastatur-Layouts habe
ich längst wieder rückgängig gemacht. Es ging mir bei der ganzen Aktion
nur darum, mich einmal in meinem Leben wie Bill Joy zu fühlen :)
Bernd K. schrieb:> Die Existenz letzterer Gruppe
z.B.
- C-Programmierung
- Unixe/Linuxe, die kein Deutsch können
- viele gute englischsprachige Rpgs
- Erfahrung mit vielen verschiedenen Tastaturen/Layouts
Dann gibt es aber auch noch so Sachen wie: Du kannst mit einer einzigen
logischen Operation mit den SSE-Registern ganze Sätze in einem Rutsch
von Groß auf Klein oder umgekehrt umstellen bzw. in dieser Richtung
normieren.
Sofern keine großen Sonderzeichen dabei..
Mit vielen Sonderzeichen geht es sequentiell besser.
Aber:
Einer der schnellsten Tipper, die ich sah, der brauchte nur 2 Finger.
Layouts waren dem ziemlich egal.
Wer 10 Finger schreiben kann, weiss, dass ueben ueben ueben hilft bzw.
Uebung den Meister macht.
Das gilt genauso für hjkl ;)
Bernd K. schrieb:> Diese Aussage bestärkt mich in meiner Überzeugung daß es mindestens zwei> fundamental unterschiedliche Typen von Menschen zu geben scheint: Einmal> die deren versierter Umgang mit der Tastatur damit steht und fällt daß> ihre Tasten auch morgen noch genau an der selben Stelle liegen an der> sie gestern schon waren und dann gibt es anscheinend welche die sich mal> eben schnell die halbe Tastatur bis zur Unkenntlichkeit ummappen und> damit dann trotzdem noch zurechtkommen.
Was heißt "trotzdem"? Sie mappen sich das ja um, gerade damit sie
besser damit zurecht kommen, weil es intuitiver ist (häufig verwendete
Zeichen/Funktionen möglichst einfach erreichbar). Ich würde das
vielleicht auch machen, aber was mich davon abhält ist, dass ich
wahrscheinlich wahnsinnig werden würde, wenn ich an einem Rechner
arbeite, wo ich dieses Mapping nicht benutzen kann. Also lieber doch so,
dass es auf jedem Rechner ohne Umbauten geht. Ist schon schlimm genug,
wenn ich unter Windows kein focus-follows-mouse habe.
Jörg W. schrieb:> Irgendeine englische Tastatur (ich glaube, von älteren Suns) hatte dort> einfach nichts drauf stehen. Eignet sich gut für die berühmte> „anykey“. ;-)
Es gibt "Das Keyboard" in einer Version, wo auf gar keiner Taste was
aufgedruckt ist: https://www.daskeyboard.com/de/daskeyboard-4-ultimate/
Nur die Harten kommen in'n Garten. ;-)
Nette Anekdote: Ein Kollege hat mal während ich im Urlaub war ein paar
Tastenkappen auf meiner Tastatur vertauscht. Ich hab das anfangs gar
nicht gemerkt und hab's dann einfach so gelassen, weil's mir egal war.
Bis ein anderer Kollege an meinem Rechner was eintippen musste und daran
fast verzweifelt ist, weil es immer falsch war. Da hab ich mich wieder
an die vertauschten Tasten erinnert, und dann war's klar.
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.
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
A. K. schrieb:> Hans Müller schrieb:>> Da drin sollten in Zeile 212556 ein paar Worte geändert werden.>> Kenner verwenden dafür "sed". ;-)
"ed is the UNIX text editor"
:-)
A. K. schrieb:> Andi schrieb:>> Tatsächlich habe ich in meinem Umkreis noch nie>> jemanden gehabt der seine Tastatur remappt.>> Ich habe auf dem Netbook die rechte Shift-Taste zu PgDn gemacht. Eine> der wichtigsten Funktionen, sonst nur umständlich über Fn+Down> erreichbar.
Ich habe mal auf einem Notebook Strg und Fn getauscht. Es gab dort eine
Fn-Taste ganz links unten im Eck, neben Strg. Nun ist mein linker
kleiner Finger gewöhnt, dass Strg die ganz äußere Taste ist und kam
deshalb nicht damit klar. Offenbar war ich aber nicht der einzige mit
dem Problem, denn es gab im BIOS-Setup des Rechners extra die
Möglichkeit, die Funktionalität der beiden Tasten zu tauschen. Das würde
außerhalb auch nicht gehen, da die Fn-Taste direkt vom
Tastaturcontroller ausgewertet wird und das Betriebssystem sie gar nicht
sieht.
> Am Desktop in der Firma habe ich die Tastenkappe von ShiftLock> abgezogen. Eine der ärgerlichsten Tasten überhaupt.
Müsste ja auch ein CapsLock sein, was es unter Linux auch ist.
Rolf M. schrieb:> Müsste ja auch ein CapsLock sein, was es unter Linux auch ist.
Wäre auch nicht besser, ich latsche da zu oft ungewollt drauf.
Die Cap ist jedenfalls ab.
Rolf M. schrieb:> Offenbar war ich aber nicht der einzige mit dem Problem, denn es gab im> BIOS-Setup des Rechners extra die Möglichkeit, die Funktionalität der> beiden Tasten zu tauschen.
Thinkpad, metoo. :) Die älteren Versionen haben die BIOS-Funktion noch
nicht.
Hans Müller schrieb:> vi (und vor allem sein Erben vim etc.) ist eine Liebe auf den dritten> Blick, die es aber Wert ist.
Nee, das ist mit Recht nicht mehr eines Blickes würdig.
Du wie viele andere hier protzen mit vim o.ä.
Die Wenigsten kennen doch den richtig alten vi nicht.
Anfang der der 90' ziger hatte ich CAD Weiterbildung auf SUN-
Workstations.
Dazu auch Grundlagen in C und UNIX.
Der Dozent sagte nach 3h Einweisung in VI, so nun habt ihr ihn
kennengelernt, und vergesst sofort, dass es ihn gibt.
Verwendet wurde da VIS(?), mit Copy u. Paste und Mausmarkierung.
Man muß sich sowas nicht antun:
Befehl xxxxx löscht im dritten Wort die letzten drei Zeichen rückwärts
usw.
Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur
Brust nehmen.
Ist der gleiche Müll.
Findet man in LINUX eigentlich noch den Ur-VI?
Unter KNOPPIX schon mal nicht.
michael_ schrieb:> Der Dozent sagte nach 3h Einweisung in VI, so nun habt ihr ihn> kennengelernt, und vergesst sofort, dass es ihn gibt.
Das hat der gesagt, weil er wusste, das ein Schnell/Billig-Einführung
nicht geht.
jede IDE hat doch Befehle zum Editieren von Text Löschen von Zeilen
etc.
Und vim hat mit Sicherheit nicht die schlimmsten key bindings.
Zumal diese key bindings quasi überall verwendet werden können (notfalls
per Plug-In. Oder meinetwegen, die von emacs. Aber irgendwas muss man
doch nehmen.)
zitter_ned_aso schrieb:> Wieviel Tausend Zeilen Code schreibt ihr denn pro Tag?
Es wird dich wahrscheinlich überraschen, aber man kann Tastaturen nicht
nur fürs Programmieren verwenden.
rbx schrieb:> Das hat der gesagt, weil er wusste, das ein Schnell/Billig-Einführung> nicht geht.
Doch!
Du kriegst eine Liste mit Befehlen. Fertig.
Wenn du so ein Experte bist, dann zeig sie hier.
michael_ schrieb:> Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur> Brust nehmen.> Ist der gleiche Müll.
Nein. Dem fehlt vor allem eins: reguläre Ausdrücke. (Auch sonst ist es
eher ein mickriger Ableger von dem, was ein ed oder ex kann, und vi,
also den "visual mode" kann er meiner Erinnerung nach gleich gar nicht.)
Reguläre Ausdrücke sind zwar write-only, aber ihre Flexibilität ist so
groß, dass es schlicht kein Stück GUI gibt, was auch nur annähernd so
viel in der Suchfunktion kann. (Es gibt natürlich GUIs, bei denen man
die Suchbegriffe auch optional als reguläre Ausdrücke interpretieren
lassen kann.)
> Findet man in LINUX eigentlich noch den Ur-VI?
Nö, unter BSD auch nicht, dafür war dessen Quellcode zu lange
proprietär. Linux hat vim, BSD hat nvi.
Jörg W. schrieb:>> Wer UNIX/LINUX nicht hat oder mag, kann sich mal den EDLIN unter DOS zur>> Brust nehmen.>> Ist der gleiche Müll.>> Nein. Dem fehlt vor allem eins: reguläre Ausdrücke. (Auch sonst ist es> eher ein mickriger Ableger von dem, was ein ed oder ex kann, und vi,> also den "visual mode" kann er meiner Erinnerung nach gleich gar nicht.)
Für mich waren beide extrem abschreckend.
Was verstehst du unter "visual mode"?
Nur weil er in einem Fenster einer grafischen Oberfläche läuft?
Jörg W. schrieb:> Nö, unter BSD auch nicht, dafür war dessen Quellcode zu lange> proprietär. Linux hat vim, BSD hat nvi.
Vielleicht hat jemand ein Bsp. für den Ur-VI, damit man damit rumspielen
kann.
Und dann ohne Bildschirm, nur mit einem Typenraddrucker als Ausgabe :-)
michael_ schrieb:> Was verstehst du unter "visual mode"?
"vi" und "ex" sind zwei Namen für das gleiche Programm. Als "vi" startet
es im visual mode für Terminals wie VT100, als "ex" für command line bei
Teletypes. Der "ex" Modus steckt im visual mode hinter den ":" commands.
Gott bewahre!
Ich benutze lieber eine richtige IDE.
Und für die paar Configdateien in der Konsole reicht nano um Längen und
ist auch wesentlich bequemer.
Für komplexere Sachen starte ich auch gerne kate.
vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw.
direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu
verlassen.
Die Grundkommandos kenne ich.
Ein paar Tutorials habe ich auch schon durchgearbeitet, aber über kurz
oder lang vergisst man die weiterführenden Kommandos halt doch und
leistungsfähige GUI Editoren können heutzutage mehr, als mancher Vim
Nutzer denkt.
Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso
nicht anstinken und wenn man erst die Konfiguration ändern muss, kann
man es auch gleich bleiben lassen und die IDE nehmen.
Nano schrieb:> Gott bewahre!
Laß' mich mal da 'raus, bitte.
> Ich benutze lieber eine richtige IDE.> Und für die paar Configdateien in der Konsole reicht nano um Längen und> ist auch wesentlich bequemer.> Für komplexere Sachen starte ich auch gerne kate.
Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal
eine Dokumentation oder eine Präsentation erstellen, also mit Markdown,
HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch
schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder
womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für
Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine
klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein
Python-, Ruby-, Perl- oder PHP-Skript...
Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren
Bedienung merken muß, sondern einen Killer wie n?vim? oder Emacs hat,
der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting,
Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das
Wichtigste, den Code, nicht mit drölfzig Einstellungs- und
Ausgabefenstern verdeckt.
> vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw.> direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu> verlassen.
Systemweite Einstellungen für Benutzerpräferenzen sind meistens keine
gute Idee.
> Ein paar Tutorials habe ich auch schon durchgearbeitet, aber über kurz> oder lang vergisst man die weiterführenden Kommandos halt doch und> leistungsfähige GUI Editoren können heutzutage mehr, als mancher Vim> Nutzer denkt.
GUI-Editoren können genau so viel oder wenig wie n?vim? oder Emacs,
nicht mehr und nicht weniger. Aber reine GUI-Editoren können eines
nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen
geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort
mal schnell etwas auf einer Remote-Maschine ändern möchte... Nicht
selten ist es auch so, daß man die Aufgabe mit einem kleinen, schnellen
Editor wie n?vim?, Emacs, oder meinetwegen auch Nano bereits erledigt
hat, bevor so eine GUI-Software überhaupt gestartet und einsatzbereit
ist... ;-)
> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann> man es auch gleich bleiben lassen und die IDE nehmen.
Dafür kann man so eine n?vim?-Konfiguration wunderbar zwischen Maschinen
sogar unterschiedlicher Betriebssystemfamilien hin und her kopieren. Den
Konfigurationsaufwand macht man sich also nur einmal, danach holt man
die Konfig einfach aus dem Repo und gut ist... ;-)
Sheeva P. schrieb:> Aber reine GUI-Editoren können eines nicht: mir einen schnellen Zugriff> auf die Dateien meiner Maschinen geben, wenn ich auf einem Boot in> Kroatien oder sonstwo sitze und dort mal schnell etwas auf einer> Remote-Maschine ändern möchte.
Wobei sowas vermutlich nur einen Bruchteil der Leserschaft interessiert
– und diejenigen musst du schätzungsweise nicht weiter davon überzeugen,
warum man auch im Zeitalter von 4K-Monitoren zumindest hin und wieder im
reinen Textterminal manche Arbeit (sehr viel schneller) erledigt bekommt
als in der GUI. :)
Jörg W. schrieb:> Wobei sowas vermutlich nur einen Bruchteil der Leserschaft interessiert
Was wohl auf die meisten technischen Diskussionsthemen zutrifft.
Nur bei Politik fühlt sich jeder angesprochen. ;-)
Hallo,
Jörg W. schrieb:> ...zumindest hin und wieder im reinen Textterminal manche Arbeit> (sehr viel schneller) erledigt bekommt als in der GUI. :)
Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe,
extrem leistungsfähige und universell anwendbare Programme sind, deren
immensen Vorteile aber nur dem nutzt und erschließt, der täglich
(stündlich?) intensiv damit arbeitet. Für Profis eben.
...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der
Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen
Nutzung steht.
rhf
Roland F. schrieb:> ...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der> Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen> Nutzung steht.
Das soll bitte jeder für sich selbst entscheiden.
Ich habe aber erstaunlicherweise noch nie von jemandem gehört der sich
in vim eingearbeitet hat und das danach für unverhältnismäßig hielt.
Unwahrscheinlich, dass das nur an falsch verstandenem Stolz liegt.
Roland F. schrieb:> Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe,
Der ursprüngliche "vi" lief auf einer 16-Bit Maschine und war für
heutige Verhältnisse geradezu winzig.
Emacs ist ein anderes Thema. Der ist von Haus aus sowieso mehr
Lisp-Interpreter mit Library als Editor.
Yes, vi is a religion. More than that, it's a cult religion. It started
out as a UNIX editor and has now become a Ubiquitous editor. Unlike,
say, Microsoft Word, it can also give the illusion of magic. Watching a
vi guru doing some heavy editing on a file, as her fingers fly over the
keys and textual transformations sweep across the screen, one could
believe that one is in the presence of supernatural powers. "Awesome",
the audience murmur to themselves. Maybe.
http://www.guckes.net/vi/mirror/vi.html
michael_ schrieb:> Findet man in LINUX eigentlich noch den Ur-VI?
Zumindest in Arch-Linux wird er defaultmäßig installiert.
Ein POSIX-konformes Betriebssystem, das für die interaktive Nutzung
vorgesehen ist, sollte die Option POSIX2_UPE unterstützen und damit auch
einen Vi mitbringen. Siehe hier:
http://www.open-std.org/JTC1/SC22/WG15/docs/options.htm
Hier ist eine Liste der zu POSIX2_UPE gehörenden Tools (zweimal nach
POSIX2_UPE suchen), darunter auch Ex und Vi:
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.htmlmichael_ 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-vimichael_ schrieb:> Nee, das ist mit Recht nicht mehr eines Blickes würdig.
Doch nicht? Ja was denn nun?
Nano schrieb:> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann> man es auch gleich bleiben lassen und die IDE nehmen.
Auch die meisten IDEs müssen konfiguriert und mittels Plug-Ins erweitert
werden, wenn man damit mehr als einen speziellen Aufgabentyp erschlagen
will. So unterstützt bspw. Eclipse von Hause aus nur Java-Entwicklung.
Für alles andere (bspw. C++) muss zusätzlich (mindestens) ein Plug-In
installiert werden. Das ist zwar meist kein allzu großes Problem, ist es
bei Vim aber auch nicht.
Da viel über remote gearbeitet wird, nutze ich den vi(m) ab und an zur
Konfiguration. Manchmal gibt es einfach keine Alternative (z.B. Firewall
oder sehr schlanke virtuelle Systeme).
Sofern möglich, installiere ich aber den Midnight Commander nach, der in
vielen Distrubutionen verfügbar ist.
Roland F. schrieb:> Was wieder mal zeigt, das Software wie Vi (oder EMACS) hochkomplexe,> extrem leistungsfähige und universell anwendbare Programme sind, deren> immensen Vorteile aber nur dem nutzt und erschließt, der täglich> (stündlich?) intensiv damit arbeitet. Für Profis eben.>> ...Und für die anderen rund 95 eher ungeeignet sind, da die Mühe der> Einarbeitung in diese Programme in keinem Verhältnis zur eigentlichen> Nutzung steht.
Angenommen, das träfe zu, so wäre das der rationale Gesichtspunkt. Aber
im Laufe der Jahre sind mir auch schon ein paar Menschen begegnet, die
wohl zu diesen 95% zählen würden, und, nunja... das treibt schon
seltsame Blüten.
Da gibt es zum Beispiel die junge Dame, die Videos für ihren
Youtube-Auftritt zusammenschneiden, mit Übergängen versehen und ein
bisschen Text darauflegen will. Natürlich geht so etwas nicht mit einer
freien oder wenigstensmoderat bepreisten Software, nein, es MUSS eine
teure "Profi"-Lösung sein, von deren Funktionen sie, grob geschätzt,
etwa 5 bis 10 Prozent nutzt. Oder der ältere Herr, der UNBEDINGT Adobe
Photoshop braucht, als ob er seine Urlaubsbilder nicht mit Paint Shop
Pro oder The GIMP skalieren könnte. Diesen Sermon kann ich bei Bedarf
noch endlos fortsetzen und bin sicher, solche Fälle sind hier vermutlich
jedem schon begegnet -- auch in diesem Forum gibt es ja eine
signifikante Anzahl von Menschen, für die es keine Alternativen zu
Altium oder Eagle gibt...
Insofern denke ich, viele Leute wollen Profisoftware, damit sie sich
wie Profis fühlen und für den noch so unwahrscheinlichen Fall, daß sie
einmal eine besondere Funktion benötigen, kein neues Programm lernen
müssen. Nur sind die meisten Profiprogramme so komplex bei der
Funktionalität, oft aber auch in der Bedienung und Usability, daß
dieselben Nutzer mit der Software eher schlecht bis gar nicht umgehen
können.
Übrigens, sehr lustig: häufig haben auch Softwarediskussionen, gern auch
um "IDE vs. n?vim?/Emacs", das Niveau: "Aber meine IDE kann XY, ätsch"
-- und enden dann oft bei "das ist ja super -- das können n?vim?/Emacs
schon seit dreißig Jahren. Wann und wie oft hast Du diese Funktion
zuletzt genutzt?" Sorry, aber... ich finde das mittlerweile nur noch zum
Totlachen. ;-)
michael_ schrieb:> Hans Müller schrieb:>> vi (und vor allem sein Erben vim etc.) ist eine Liebe auf den dritten>> Blick, die es aber Wert ist.>> Nee, das ist mit Recht nicht mehr eines Blickes würdig.
Ach, das entscheidest neuerdings Du? Gut zu wissen.
> Du wie viele andere hier protzen mit vim o.ä.
Natürlich benutzen die Leute den vi nur, um damit zu protzen.
Wie muß ich solche Aussagen jetzt verstehen? Nur weil Du nicht damit
umgehen kannst, dann kann er kein gutes Werkzeug sein? Du entscheidest
was eine gute Software ist, und wer was anderes benutzt, tut das nur zum
Angeben?
> Die Wenigsten kennen doch den richtig alten vi nicht.
Na und? Es gibt ja genug Klone mit demselben Bedienkonzept.
Sheeva P. schrieb:> Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal> eine Dokumentation oder eine Präsentation erstellen, also mit Markdown,> HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch> schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder> womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für> Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine> klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein> Python-, Ruby-, Perl- oder PHP-Skript...
Eclipse kann auch gewöhnliche Textdateien bearbeiten.
Ich muss also nicht einmal meine IDE verlassen, wenn ich so etwas
dringen machen muss.
> Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren> Bedienung merken muß, sondern einen Killer wie n?vim?
Denkfehler!
Nano und kate erschließen sich intuitiv, da muss man keine Lernwoche
einplanen, wie bei vim.
Und was die IDE betrifft, in der sollte man ohnehin Zuhause sein. Zum
Entwicklen kann vim da ohnehin nicht mithalten.
> oder Emacs hat,> der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting,> Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das> Wichtigste, den Code, nicht mit drölfzig Einstellungs- und> Ausgabefenstern verdeckt.
Von Haus aus kann vim das erst einmal nicht. Du musst das alles
einrichten.
Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den
auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist
deutlich umständlicher, als die Buttons und Tastaturkombinationen in der
IDE.
Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt
sehen können möchte. Bei gdb muss man erst den step eingeben und dann
sagen, welche Variablen man anschauen will. Bei der IDE sieht man die
Variablenzustände immer und man drückt einfach seine Taste oder den
Button.
Und da das nicht bei vim voreingestellt ist, hat man noch eine weitere
Hürde bis alles passt.
>> vi(m) also nur, wenn ich muss, weil irgendein Shellscript ihn bspw.>> direkt aufruft, anstatt sich auf die Systemweite Editoreinstellung zu>> verlassen.>> Systemweite Einstellungen für Benutzerpräferenzen sind meistens keine> gute Idee.
Ich hätte mich da besser ausdrücken sollen.
Ich meine damit die individuellen Einstellungen pro Benutzeraccount.
> Aber reine GUI-Editoren können eines> nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen> geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort> mal schnell etwas auf einer Remote-Maschine ändern möchte... Nicht> selten ist es auch so, daß man die Aufgabe mit einem kleinen, schnellen> Editor wie n?vim?, Emacs, oder meinetwegen auch Nano bereits erledigt> hat, bevor so eine GUI-Software überhaupt gestartet und einsatzbereit> ist... ;-)
Deswegen und dafür habe ich ja auch nano.
>>> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso>> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann>> man es auch gleich bleiben lassen und die IDE nehmen.>> Dafür kann man so eine n?vim?-Konfiguration wunderbar zwischen Maschinen> sogar unterschiedlicher Betriebssystemfamilien hin und her kopieren. Den> Konfigurationsaufwand macht man sich also nur einmal, danach holt man> die Konfig einfach aus dem Repo und gut ist... ;-)
Das geht bei einer IDE genauso.
Yalu X. schrieb:> Nano schrieb:>> Und gegen eine richtige IDE kann vim in der Standardeinstellung sowieso>> nicht anstinken und wenn man erst die Konfiguration ändern muss, kann>> man es auch gleich bleiben lassen und die IDE nehmen.>> Auch die meisten IDEs müssen konfiguriert und mittels Plug-Ins erweitert> werden, wenn man damit mehr als einen speziellen Aufgabentyp erschlagen> will.
Die Änderungen halten sich bei einer IDE in Grenzen.
Fakt ist, bei der IDE ist der Debugmodus mit Ansichtfenster für die
Variablen standardmäßig verfügbar.
> So unterstützt bspw. Eclipse von Hause aus nur Java-Entwicklung.> Für alles andere (bspw. C++) muss zusätzlich (mindestens) ein Plug-In> installiert werden. Das ist zwar meist kein allzu großes Problem, ist es> bei Vim aber auch nicht.
Das stimmt nicht. Es gibt von Eclipse eine extra C/C++ Version.
Die kann C und C++ von Haus aus.
Nano schrieb:> Zum Entwicklen kann vim da ohnehin nicht mithalten.
Hust, hust – lass dich besser nicht auf diese Diskussion ein.
Dass er für dich nicht dafür taugt, ist außer Zweifel¹. Du solltest aber
nicht von dir auf andere schließen.
¹ Nicht, weil ich dich für unfähig halten würde, sondern weil du diesen
Fakt ja klar und deutlich so artikuliert hast.
Hallo,
JJ schrieb:> Ich habe aber erstaunlicherweise noch nie von jemandem gehört der sich> in vim eingearbeitet hat und das danach für unverhältnismäßig hielt.
Was nicht unbedingt meiner Behauptung widerspricht. Diese "Jemande"
können ja Profis sein, für die ein Texteditor zur Grundausstattung ihres
Arbeitsumfeld gehört. Und ich kann mir gut vorstellen das es dann
sinnvoll ist ein Universalwerkzeug einzusetzen, ich zitiere mal:
Sheeva P. schrieb:> Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal> eine Dokumentation oder eine Präsentation erstellen, also mit Markdown,> HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch> schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder> womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für> Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine> klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein> Python-, Ruby-, Perl- oder PHP-Skript...>> Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren> Bedienung merken muß, sondern einen Killer wie n?vim? oder Emacs hat,> der das alles, und zwar wirklich alles, kann. Mit Syntaxhighlighting,> Tab Completion, Codebrowser, ... und der, ahja, den Blick auf das> Wichtigste, den Code, nicht mit drölfzig Einstellungs- und> Ausgabefenstern verdeckt.> Aber reine GUI-Editoren können eines> nicht: mir einen schnellen Zugriff auf die Dateien meiner Maschinen> geben, wenn ich auf einem Boot in Kroatien oder sonstwo sitze und dort> mal schnell etwas auf einer Remote-Maschine ändern möchte...
Wenn man in einem solchen Arbeitsumfeld tätig, in der man 100% aller
Editiertätigkeiten mit einem Werkzeug erledigen kann, müsste man schon
mit dem Klammerbeutel gepudert sein, wenn man mit einer
80%-Prozentlösung zufrieden gibt.
Wie gesagt, für den weniger intensiven "Gebraucher" von Texteditoren
halte ich Vi, EMACS und Konsorten für eher weniger geeignet, da der
Aufwand zum Erlernen der Bedienung in keinem Verhältnis zum Nutzen
steht.
rhf
Jörg W. schrieb:> Auch ein Emacs hat aus historischen Gründen seine eigenen Kommandos zur> Navigation (C-P, C-N), aber ich kann mich nicht dran erinnern, wann ich> die das letzte Mal benutzt hätte.
Wenn ich Emacs verwende, dann nehme ich immer C-P, C-N. Der Weg mit den
Fingern ist einfach kürzer als zu den Pfeiltasten. Und deshalb nehme ich
beim vi auch h,j,k,l.
Es gibt aber noch einen Grund: Gerade früher bei den seriellen Terminals
passierte es desöfteren, dass die Escape-Sequenzen, die z.B. durch die
Pfeiltasten erzeugt wurden, vom vi "zerhackt" wurden. Das liegt an den
Timeouts, die nicht immer griffen, um ESC-Sequenzen von der ESC-Taste zu
unterscheiden. Denn per ESC-Taste kommt man ja wieder in den
Kommando-Modus.
Meiner Meinung nach war das ein großer Design-Fehler beim vi.
Denn fast jede Editiertaste (im VT100/220-Modus) beginnt mit ESC.
Beispiel: Pfeil runter ist <ESC>[B. Wenn man dann mal länger die
Pfeil-runter-Taste drückte, hatte man dann nachher desöfteren
[B[B[B[B[B[B[B[B[B[B[B[B[B[B in der Text-Datei stehen.
Von daher habe ich mir schnell h,j,k,l angewöhnt. Dasselbe dann auch mit
C-P, C-N beim Emacs.
P.S.
Den Lieblingseditor, den ich unter "x"-Systemen verwende, ist ein von
mir selbstgeschriebener Clone des VAX/VMS-Editors "EDT" - mit vielen
Erweiterungen. Da werden sämtliche Tasten des separaten Nummernfeldes
als Editier- und Navigationstasten verwendet. Da sie alle eng
beieinander liegen, kann man damit ungemein schnell innerhalb der
Text-Dateien navigieren. Die Pfeiltasten gehen zwar auch, werden aber
wegen der besseren Alternativen durch die
EDT-Nummernblocktasten-Navigation fast überflüssig. Und
selbstverständlich ist auch die "GOLD"-Taste implementiert ;-)
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. ;-)
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.
Oh jeh, jetzt wirds aber nostalgisch...
Ich muss aber gestehen, dass ich den Pfunktionstasten und Datenfreigabe
nicht sehr hinterhertrauere.
XEDIT war es bei mir damals wohl...
JJ schrieb:> Oh jeh, jetzt wirds aber nostalgisch...
Kann man so oder so sehen. Mein Clone-EDT kann mehrere Fenster, kann
C-Highlightning, kann UNIX-Befehle (z.B. "make") direkt starten und den
Output in ein Editierfenster übernehmen, kann direkt zu fehlerhaften
Zeilen im C-Code springen, kann Editier-Macros und auch Scripts in einer
(selbst entwickelten) Programmiersprache ausführen. Damit kann er dann
auch "Türme von Hanoi", "Pangolins" und andere Spielchen direkt im
Textbuffer ausführen ;-)
Solche Sachen hatte ich damals dem (Gosling-)Emacs abgeschaut und dann
neu implementiert. Lisp fand ich einfach zu grausig. Und weil er eine
besondere Art der Speicherverwaltung benutzt (nix verkettete Pointer auf
Zeilen), kann er Textdateien bearbeiten, die bis zu 2 GB groß sein
können - mit ganz normaler Bearbeitungsgeschewindigkeit. Außerdem lädt
er solche großen Dateien schneller als jeder andere Editor. Da macht
dann Notepad++, den ich unter Windows gern benutze, ziemlich schnell
schlapp.
Auch weil die curses- und ncurses-Implementationen damals so grottig
waren, hatte ich auch eine neue Curses-Lib geschrieben (damals auch in
Teilen in der iX veröffentlicht), welches die Scrolling-Regions und
Editierbefehle von Terminals besser nutzte und so die Ausgabe gerade auf
seriellen Terminals wesentlich beschleunigte.
Ich nutze den Editor auch noch heute, schreibe mit ihm immer noch meine
C-Programme - IRMP und eine Menge anderes Zeugs. Außerdem bringe ihm ab
und zu auch noch ein paar neue Gimmicks bei.
Im wesentlichen besteht der Clone aus der Zusammenfassung der besten
Features von EDT, Emacs und vi. Und damit ist der auch heute noch
hochaktuell.
Jörg W. schrieb:> Nano schrieb:>> Zum Entwicklen kann vim da ohnehin nicht mithalten.>> Hust, hust – lass dich besser nicht auf diese Diskussion ein.>> Dass er für dich nicht dafür taugt, ist außer Zweifel¹. Du solltest aber> nicht von dir auf andere schließen.>> ¹ Nicht, weil ich dich für unfähig halten würde, sondern weil du diesen> Fakt ja klar und deutlich so artikuliert hast.
Nun, das liegt in der Natur der Sache.
Vim ist in erster Linie ein Texteditor, keine IDE.
Eine IDE ist weit mehr als ein Texteditor und auf die
Softwareentwicklung optimiert.
Bei der Nutzung von GUI Toolkits, kann man bspw. die GUI mit der IDE
zusammenklicken und den Kontrolcode dann anschließen eintragen. Mit vim
geht das meines Wissens nach nicht.
Deswegen bin ich der Meinung, das vim mit einer IDE nicht mithalten
kann.
Die IDE ist für ihren Aufgabenzweck optimiert, vim ist auch für Latex
und Textdateien da, nicht nur für die Softwareentwicklung. Insofern ist
die Optimierung auf einen bestimmten Aufgabenzweck eine andere, bei vim
liegt es eher auf das generelle Editieren von Dateien die als Text in
diversen Formaten vorliegen, die Spezialisierung einer IDE hat er nicht.
Nano schrieb:> Vim ist in erster Linie ein Texteditor, keine IDE.
Die Grenzen sind fließend.
Ich bin mit Vim zu wenig bewandert, bin mir aber trotzdem ziemlich
sicher, dass der eine vollwertige IDE aufbauen kann. Zumindest mache ich
das mit Emacs exakt so (auch den würdest du sicher als "in erster Linie
ein Texteditor bezeichnen"¹), und der größte Vorteil dabei ist, dass ich
zwar innerhalb der letzten knapp drei Jahrzehnte alles Mögliche an
Entwicklungsarbeit erledigt habe, aber trotz der massiv
unterschiedlichen Aufgabenfelder in all den Jahren nie meine IDE
grundlegend wechseln musste. ;-) Unix-Programmierung,
FreeBSD-Kerneldebugging (mit remote GDB), LaTeX, Python, Perl, AVR, ARM
– alles in der gleichen IDE, mit der gleichen Tastenbelegung. :)
¹) Wie oben bereits erwähnt worden ist, ist das ohnehin eine falsche
Wahrnehmung: Emacs ist seit Jahrzehnten in erster Linie ein
Lisp-Interpreter, der halt sehr viele "einfache" Tasten auf den Befehl
"self-insert" abbildet, sodass sie das entsprechende Zeichen im aktiven
Puffer einfügen.
Jörg W. schrieb:> Nano schrieb:>> Zum Entwicklen kann vim da ohnehin nicht mithalten.>> Hust, hust – lass dich besser nicht auf diese Diskussion ein.
Er hat aber Recht, vim ist nun mal ein Editor und keine IDE, kann da
also nicht mithalten.
Jörg W. schrieb:> Zumindest mache ich> das mit Emacs exakt so (auch den würdest du sicher als "in erster Linie> ein Texteditor bezeichnen"¹),
Emacs: "a great operating system, lacking only a decent editor"
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.
Frank M. schrieb:> Nano schrieb:>> Vim ist in erster Linie ein Texteditor, keine IDE.>> Das ist reine Ansichtssache.>> Dieses>> ....>> und vieles mehr findet man bei google, wenn man dort nach "vim als IDE"> sucht.
Ich habe mir durchaus solche Artikel angesehen, selbst Videos auf
Youtube zum Thema VIM und IDE habe ich mir angesehen.
Auch habe ich versucht mit VIM zu arbeiten.
Aber nichts davon hat mich wirklich davon überzeugt.
Das Kernproblem bleibt. VIM muss alles über den Zeichensatz darstellen,
damit ist er in der Darstellung einer grafischen IDE schon einmal
unterlegen.
Auch das navigieren mit Maus kann bei Entwicklungen, die man sowieso mit
der Maus testen muss, ein Vorteil sein. Bei VIM ist die Maus allerdings
eher ein Fremdkörper, es soll schließlich alles per Tastatureingaben
möglich sein und man muss nicht zwischen Maus und Tastatur wechseln. Mit
diesem Merkmal wird vim auch immer beworben, sobald man aber eine
Anwendung mit GUI entwickelt, ist das hinfällig.
GUI Oberflächen zusammenklicken geht mit VIM meines Wissens nach nicht,
die beiden Links zeigen diesbezüglich auch nichts, dass das irgendwie
möglich wäre. Es macht auch keinen Sinn, da vim auch im Textmodus
funktionieren muss und die GUI Toolkits eine grafische Oberfläche
erwarten. Wenn man die ausprobieren will und sehen will, wie die
aussehen, braucht man also ohnehin den grafischen Modus.
Beim Debuggen ist er auch im Nachteil, was auch an den Einschränkungen
beim Darstellen liegt.
Soll vim bspw. eine Linie Zeichen, dann muss er dazu den Zeichensatz
fester breite bemühen und dieses Zeichen ist dann gleich mal ein paar
Pixel breit.
Ob sichtbar oder nicht, dieser Platz wird dann immer verschwendet.
Bei einer grafischen IDE kann man auch eine Linie haben, die nur einen
Pixel breit ist und die Pixel links und rechts daneben, sind für andere
Sachen verwendbar.
Aber wenn ihr mit vim (oder emacs) glücklich seid, dann ist das für mich
okay. Ich würde auch niemandem an seinem Arbeitsplatz zum Arbeiten mit
einer IDE zwingen, solange er mit vim die Arbeit in der gleichen Zeit
hinkriegt.
Nano schrieb:> Auch habe ich versucht mit VIM zu arbeiten.> Aber nichts davon hat mich wirklich davon überzeugt.
mich schon.
WEnn man C-Libs verwendet, dann hat man unter Eclipse keine
Autoverfollständigung. Dort hat man diese Option nur bei Klassen.
Ich benutze you-complete-me-Plugin. Und dort wird alles ergänzt /
aufgelistet.
zitter_ned_aso schrieb:> bis eclipse gestartet ist, ist vim mit coc schon fertig ;-)
Bis Du Dein coc so konfiguriert hast daß es alles kann was Eclipse auch
kann (was wahrscheinlich niemals der Fall ist) hab ich mit Eclipse schon
das verbleibende Arbeitspensum bis zur Rente abgerissen und sitze im
Schaukelstuhl hinter dem Haus und rauch gemütlich ein Pfeifchen.
Frank M. schrieb:> Jörg W. schrieb:>> Emacs ist seit Jahrzehnten in erster Linie ein>> Lisp-Interpreter, der halt sehr viele "einfache" Tasten auf den Befehl>> "self-insert" abbildet,>> Perfekte Beschreibung ;-)
Etwas schmerzlich ist mir das mal klar geworden, als ich irgendwann
Anfang der 1990er Jahre an einer Datei editiert habe, die einen riesigen
{}-Funktionsblock enthielt (irgendein Kernel-Treiber). Im C-Modus wird
die schließende geschweifte Klammer ja durch den Befehl
"c-electric-brace" überschrieben, und der musste nun intern den ganzen
langen Block zurück wandern, um das passende Einrückungsniveau zu
finden, auf das er die Klammer setzen soll. Das dauerte gefühlt eine
Ewigkeit, und ich habe mir für das Editieren dieser Funktion dann
angewöhnt, "C-Q }" zu tippen (Control-Q erzwingt ein "quote", also ein
literales Einfügen des nächsten Zeichens unter Aufhebung der sonstigen
Tastenbindung).
Das dürfte noch auf einem i80368SX / 16 MHz gewesen sein, als der Joke
mit den "Eight Megabyte" zumindest noch für ein müdes Lächeln reichte.
Heute wäre mancher wohl froh, wenn seine IDE mit Eight Gigabyte flüssig
liefe. :-)
Bernd K. schrieb:> Er hat aber Recht, vim ist nun mal ein Editor und keine IDE, kann da> also nicht mithalten.
Auch du wirst nur durch "Er hat Recht!"-Rufen die Realität bloß nicht
ändern. Frank hatte vor dir schon schnell ergugelte Beispiele gepostet,
die deine (und Nanos) Behauptungen ziemlich deutlich widerlegen.
Da wir beim Thema vim und IDE sind.
Wie sieht's eigentlich mit der Integration von UML in vim inkl
Codegenerierung und Darstellung von UML Diagrammen aus? :)
Jörg W. schrieb:> Auch du wirst nur durch "Er hat Recht!"-Rufen die Realität bloß nicht> ändern. Frank hatte vor dir schon schnell ergugelte Beispiele gepostet,> die deine (und Nanos) Behauptungen ziemlich deutlich widerlegen.
Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen
intregiert ist.
Auch fehlt ein Beispiel, wie man die GUI zusammenklickt.
Nano schrieb:> VIM muss alles über den Zeichensatz darstellen
Ich gehe stark davon aus, dass diejenigen, die Vim als IDE benutzen,
dessen Grafikvariante benutzen und ihn nicht im Textterminal laufen
lassen. Zumindest läuft bei mir der Emacs zu weit mehr als 90 % im
GUI-Modus (Textmodus eigentlich nur, wenn ich über ssh und ein langsames
Netz arbeite).
Ich gebe zu, dass ich schon auch über manche Dinge im Emacs hin und
wieder überrascht bin, bspw. als ich mal mehr aus Versehen eine
PDF-Datei damit geöffnet habe. :-)
Nano schrieb:> Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen> intregiert ist.
Ja, das müsste jemand zeigen, der Vim wirklich aktiv benutzt.
Jörg W. schrieb:> Nano schrieb:>> VIM muss alles über den Zeichensatz darstellen>> Ich gehe stark davon aus, dass diejenigen, die Vim als IDE benutzen,> dessen Grafikvariante benutzen und ihn nicht im Textterminal laufen> lassen. Zumindest läuft bei mir der Emacs zu weit mehr als 90 % im> GUI-Modus (Textmodus eigentlich nur, wenn ich über ssh und ein langsames> Netz arbeite).
Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in
einem grafischen Fenster.
D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit
Textzeichen darstellen.
> Ich gebe zu, dass ich schon auch über manche Dinge im Emacs hin und> wieder überrascht bin, bspw. als ich mal mehr aus Versehen eine> PDF-Datei damit geöffnet habe. :-)
Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß.
also ich benutze neovim und die sagen seblst:
https://neovim.io/charter/
Non-goals
- Turn Vim into an IDE
- Limit third-party applications (such as IDEs!) built with Neovim
- ....
Und das ist doch absolut in Ordnung. Dafür gibt es ja die Plugins.
Und ein Debugger wird da auch nie integriert sein. Das haben sie selbst
geschrieben.
Aber sie wollen Schnittstellen anbieten dass man in einer IDE (neo)vim
als Editor einbinden kann. Ober bei Firefox/Chrom/etc..
Nano schrieb:> Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in> einem grafischen Fenster.> D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit> Textzeichen darstellen.
Für Texte: ja, na klar, wie jeder andere Texteditor einer IDE auch.
Ansonsten: siehe Anhang.
> Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß.
Naja, wenn hier über Eclipse und dergleichen geredet wird, da ist Emacs
ein Winzling. Wenn du ihn mit "nano" vergleichst, würde ich zustimmen,
aber es wurde ja hier immer die Leistungsfähigkeit von IDEs in den
Vordergrund gerückt, nicht die Kleinheit des Editors.
Jörg W. schrieb:> Nano schrieb:>>> Naja, gut aber das ist dann letzten Endes dann doch nur ein Textmodus in>> einem grafischen Fenster.>>> D.h. seine Darstellung innerhalb seines Fenstern muss er trotzdem mit>> Textzeichen darstellen.>> Für Texte: ja, na klar, wie jeder andere Texteditor einer IDE auch.
Wenn man mehrere Ebenen hat, die man mit einem Rahmen trennen will, dann
braucht der Zeichenmodus mehr Platz.
Ebenfalls muss man Hinweisgeber immer mit Zeichen machen.
> Ansonsten: siehe Anhang.
Das ist jetzt nur ein Bildbetrachtermodus. Ich meinte aber Fensterlogik.
>>> Emacs habe ich nie ernsthaftbenutzt. Dafür ist es mir auch zu groß.>> Naja, wenn hier über Eclipse und dergleichen geredet wird, da ist Emacs> ein Winzling. Wenn du ihn mit "nano" vergleichst, würde ich zustimmen,
Ja, ich vergleiche vi(m) und emacs eher mit anderen Editoren.
Nano schrieb:> Wenn man mehrere Ebenen hat, die man mit einem Rahmen trennen will, dann> braucht der Zeichenmodus mehr Platz.
Ja, aber siehe Screenshot oben: das ist dann einfach eine komplette
Statuszeile, was natürlich anderweitig sinnvoll ist.
> Ebenfalls muss man Hinweisgeber immer mit Zeichen machen.
Tooltips gibt's beispielsweise, die funktionieren dann natürlich nur im
Grafikmodus, nicht im Text-Pendant. Auch die Breakpoint-Markierung ist
ein grafisches Symbol, und farbliche Hervorhebung geht natürlich sogar
im Textmodus – allerdings im Grafikmodus mit feineren Nuancen.
Habe mal einen Screenshot eines Ausschnitts angehangen. Der rote Punkt
ist ein Breakpoint in der aktuellen Debuggersitzung. Die etwas dunkleren
Bereiche sind hard <TAB>s. Die wollen wir normalerweise vermeiden, daher
werden sie markiert (aber das hier ist 3rd-party code, deshalb bleiben
sie drin). Die auffällige gelbe Markierung ist whitespace am Ende der
Zeile, den wollen wir auch vermeiden. ;-)
Bei sonst üblichen IDEs habe ich immer nur eine Funktion gefunden, mir
alle Sonderzeichen (TABs, Spaces) hervorheben zu lassen, was ich
deutlich störender fand als hier nur die, die ich eigentlich vermeiden
will.
> Ja, ich vergleiche vi(m) und emacs eher mit anderen Editoren.
Dafür wurde aber hier verdammt viel mit IDEs wie Eclipse argumentiert.
;-)
zitter_ned_aso schrieb:> Bernd K. schrieb:>> Blödsinn.>> Endlich habe ich einen Experten erwischt, der mir helfen kann. Hier hat> sich bis jetzt keiner mit einer Lösung gemeldet:>> Beitrag "Eclipse CDT: Autocomplete-Funktion bei C-Programmen">> Bitte mal hier knowledge droppen ;-)
Gib mal den richtigen Link, denn in dem Thread den Du verlinkt hast
scheinen alle Fragen beantwortet zu sein und das angebliche Problem
> "WEnn man C-Libs verwendet, dann hat man unter Eclipse keine> Autoverfollständigung"
kommt darin auch nicht zur Sprache.
Kann vim eigentlich mittlerweile bedingte includes parsen oder nicht
parsen (je nachdem welche Symbole definiert sind) und das bei der
Autovervollständigung berücksichtigen? Kann vim den code der innerhalb
von unerfüllten #ifdef steht ausgrauen so daß man mehr Übersicht darüber
hat welcher Code benutzt wird und welcher nicht? kann vim Makros
expandieren oder Funktionssignaturen und Dokumentation anzeigen wenn man
die Maus drüber hält (oder den stechenden Blick drauf richtet falls
keine Maus existiert)? Kann es Aufrufer- und Aufrufbäume anzeigen?
Noch eine Ergänzung zur Diskussion vi(m) versus IDE:
Einen vim als IDE aufzuziegeln würde ich mir tatsächlich nicht antun
wollen.
Aber umgekehrt, die Möglichkeit eine IDE mit einem vim-editor zu
ergänzen nutze ich gerne.
Zumindest bei Eclipse und VSC funktioniert das sogar sehr gut.
Natürlich sind dabei einige Einschränkungen in Kauf zu nehmen, aber bei
den wichtigsten Funktionen fühle ich mich zuhause ;)
Andi schrieb:> Zumindest bei Eclipse und VSC funktioniert das sogar sehr gut.
Der Witz ist, dass manche VSC-Nutzer wahrscheinlich das gleiche Tool
benutzen, wie die vim-Nutzer mit dem ycm-Plugin. Nämlich clangd.
Und dann aktivieren einige wahrscheinlich noch vim's keybindings. Aber
vim, nein das geht natürlich nicht ;-)
https://clang.llvm.org/extra/clangd/Installation.html
Jörg W. schrieb:> Die auffällige gelbe Markierung ist whitespace am Ende der> Zeile, den wollen wir auch vermeiden. ;-)
Moderne Editoren verfügen über eine Option beim Speichern der Datei
Whitespace am Ende einer Zeile einfach zu entfernen.
Ich habe so eine Option immer an, insofern muss ich das nicht extra
anzeigen.
Nano schrieb:> Moderne Editoren verfügen über eine Option beim Speichern der Datei> Whitespace am Ende einer Zeile einfach zu entfernen.
Das ist anders K*cke. Wenn ich in einer Datei eine Zeile bearbeite, dann
möchte ich nicht, dass ggf. noch 25 andere Zeilen „unter der Hand“
verändert werden. Das bläht sinnlos die Diffs im VCS auf und obfuscated
das, was tatsächlich geändert worden ist – ganz zu schweigen davon, dass
es das Einpflegen von Updates an Code, der 3rd-party ist, massiv
behindern kann.
Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein
Tool auf meinem Computer. Daher ist es wichtig, dass ich sehe, was ich
im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder
<TAB>-Zeichen, die ich vielleicht gar nicht haben wollte).
Jörg W. schrieb:> Nano schrieb:>> Moderne Editoren verfügen über eine Option beim Speichern der Datei>> Whitespace am Ende einer Zeile einfach zu entfernen.>> Das ist anders K*cke. Wenn ich in einer Datei eine Zeile bearbeite, dann> möchte ich nicht, dass ggf. noch 25 andere Zeilen „unter der Hand“> verändert werden. Das bläht sinnlos die Diffs im VCS auf und obfuscated> das, was tatsächlich geändert worden ist – ganz zu schweigen davon, dass> es das Einpflegen von Updates an Code, der 3rd-party ist, massiv> behindern kann.
Bei eigenen VCS kann man sich darauf einigen, dass das jeder so macht.
Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur
Speicherplatz belegen und den Parser des Compilers verlangsamen.
Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug
auch beenden.
Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass
Whitespace am Ende von Zeilen erhalten bleiben.
> Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein> Tool auf meinem Computer.
Das kannst du durch, die Einstellung musst du schließlich selber
vornehmen.
Natürlich wäre es wünschenswert, dass so eine Einstellung standardmäßig
eingestellt ist, dann würden weitaus mehr Textdateien ohne Whitespace am
Zeilenende existieren und sich mehr Leute damit abfinden.
> Daher ist es wichtig, dass ich sehe, was ich> im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder> <TAB>-Zeichen, die ich vielleicht gar nicht haben wollte).
Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der
gleichen Begründung ja auch nicht entfernen.
Bernd K. schrieb:> Kann vim eigentlich mittlerweile bedingte includes parsen oder nicht> parsen (je nachdem welche Symbole definiert sind) und das bei der> Autovervollständigung berücksichtigen?
Ja. Das YCM-Plug-In wurde schon ein paar mal angesprochen. Es verwendet
clangd und damit den C/C++-Parser und weitere Teile von Clang. Damit
sind eine ganze Reihe semantischer Aktionen möglich. Hier gibt es eine
Übersicht:
https://github.com/ycm-core/YouCompleteMe#quick-feature-summary
Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im
krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde.
Bernd K. schrieb:>> und was noch viel wichtiger ist -und>> was ich jedem vim-Einsteiger empfehle- die Finger von den Cursortasten>> zu lassen ( am besten die Pfeiltasten remappen ).>> Navigiert wird ausschliesslich mit hjkl, auch wenn anfangs die Finger zu>> den Pfeiltasten zucken;-)>> Deswegen ist er inkompatibel mit dem Rest der weltweiten EDV. Diese> Tastenbelegung stammt noch aus einer Zeit als man noch elektrische> Schreibmaschinentastaturen in Terminals eingebaut hat.
Die EDV Welt ist sehr wohl kompatibel zu vim und dessen forks - bis auf
die Windowswelt - aber die ist ja zu Glück nicht die EDV-Welt ;-)
Nano schrieb:> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur> Speicherplatz belegen und den Parser des Compilers verlangsamen.
LOL! Wie viele Millionen unnötige Whitespaces hast du denn
typischerweise in deinem Quellcode, wenn du dadurch tatsächlich
Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst
und das sogar dein größtes Problem ist?
> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug> auch beenden.
Unfug sind Commits, die an allen möglichen Stellen Änderungen am
Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als
nerviges Rauschen bemerkbar.
> Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass> Whitespace am Ende von Zeilen erhalten bleiben.
Ein langjähriger Bug von Microsofts Mail- und Newsgroups-Software war,
dass vor dem Versenden ungefragt und nicht abstellbar alle Whitspaces an
Zeilenenden entfernt wurden. Das war deshalb ein Problem, weil der
übliche Signaturtrenner eine Zeile ist, die aus "-- " besteht, also mit
einem Space am Ende, damit man immer noch innerhalb des Textes ein "--"
machen kann, ohne dass das fälschlicherweise als Signaturtrenner erkannt
wird. So ziemlich jede Software hat das benutzt, um beim Antworten
automatisch die Signatur des ursprünglichen Posts zu entfernen.
Und ich hatte auch schon File-Formate, die ähnlich wie CSV waren, aber
wo die Felder durch TAB getrennt waren. Die Zahl der Felder pro Zeile
war fix, aber der Inhalt eine Feldes konnte durchaus auch leer sein. Das
heißt, es konnten auch am Zeilenende TABs stehen, die zwingend
erforderlich waren. Da ist es ziemlich doof, wenn der Editor die einfach
wegwirft.
>> Ich möchte, dass ich festlege, was geändert wird, und nicht irgendein>> Tool auf meinem Computer.>> Das kannst du durch, die Einstellung musst du schließlich selber> vornehmen.
Dann ist das ja ok. Wenn man das erst einschalten muss, damit das
passiert oder man es manuell antriggern muss, ist das vollkommen ok. Die
Software soll aber nicht eigenmächtig und quasi heimlich irgendwas am
Code ändern.
>> Daher ist es wichtig, dass ich sehe, was ich>> im Begriff bin zu tun (eben auch die Leerzeichen am Zeilenende oder>> <TAB>-Zeichen, die ich vielleicht gar nicht haben wollte).>> Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der> gleichen Begründung ja auch nicht entfernen.
Er will nur sehen dass sie da sind, damit er selbst entscheiden kann, ob
er sie entfernt. Was er nicht will, ist, dass die Software das von
selbst tut.
Rolf M. schrieb:>> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur>> Speicherplatz belegen und den Parser des Compilers verlangsamen.>> LOL! Wie viele Millionen unnötige Whitespaces hast du denn> typischerweise in deinem Quellcode,
Vor zig Jahren war es auf IBMs Mainframes üblich, Textfiles in festem
Zeilenformat zu speichern, quasi wie Lochkartenstapel. Jede Zeile hatte
ihre 80 Zeichen, egal ob was drin stand oder nicht.
Rolf M. schrieb:>> Was machst du wenn die TAB Zeichen da sind? Dann kannst du sie mit der>> gleichen Begründung ja auch nicht entfernen.>> Er will nur sehen dass sie da sind, damit er selbst entscheiden kann, ob> er sie entfernt. Was er nicht will, ist, dass die Software das von> selbst tut.
So ist es.
Noch schlimmer als TABs und trailing whitespace sind Werkzeuge, die
glauben, „klug“ sein zu müssen und ungefragt Dinge tun.
> Wenn man das erst einschalten muss, damit das passiert oder man es> manuell antriggern muss, ist das vollkommen ok.
Nur, dass man dann nicht nur keine Änderungen hat, sondern auch keine
Kennzeichnung, dass da etwas ist, was man vielleicht gar nicht haben
will.
Nano schrieb:> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug> auch beenden.
Soso. Du meinst, es interessiert Atmicrochip irgendwie, dass wir die
TABs in den von ihnen gelieferten Treibern als „Unfug“ ansehen, und
deshalb wären sie sofort bereit, all ihren Kram umzuschreiben?
Ein wenig weltfremd kommt mir das schon vor.
Rolf M. schrieb:> Unfug sind Commits, die an allen möglichen Stellen Änderungen am> Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als> nerviges Rauschen bemerkbar.
Es sei denn, man schaltet "ignore whitespaces" für den diff ein.
Es nervt mich auch wenn durch entfernte whitespaces ein diff kaum noch
lesbar ist. Allerdings ist das auch nur einmal, danach passt es ja
wieder. So dramatisch ist es nun auch wieder nicht.
Wenn man im Code einen Block eine Ebene tiefer einrücken muss, hat man
das Problem ja auch.
Ich lasse mir den diff auch immer mit einem grafischen Tool farbig
anzeigen. Dann kann man trotz entfernter whitespaces einigermaßen
erkennen, was man sehen möchte.
Ich nutzte keinen vi, höchstens mal nano für config Dateien.
In meiner Eclipse IDE lasse ich immer alle trailing whitespaces
entfernen. Aber nicht des Speicherplatzes wegen ;)
Yalu X. schrieb:> Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im> krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde.
Neovim ist noch schneller!
...und einfacher zu konfigurieren - die .vimrc wird in die
~/.config/nvim/init.vim uebernommen.
Die meisten Dinge die jeder in der .vimrc hat, wie set nocompatible sind
im Neovim default und werden in der init.vim somit nur aus historischen
Gründen gesetzt
Ein :checkhealth sagt einem dann im nvim auch, wo es denn klemmt - wenn
irgendwas mal falsch gesetzt ist.
Ich weiß nicht, warum so ein Bohei um die Trailing Whitespaces gemacht
wird. Da macht man einmal ein
1
:1,$s/\s\s*$//g
und der Drops ist gelutscht.
Das geht nicht nur im vi(m), sondern in jedem (vernünftigen) Editor, der
reguläre Expressions beherrscht.
Wenn ein Editor die Trailing Spaces beim Speichern "abstreifen" kann -
auch gut. Aber nur, wenn man das für die jeweiligen Dateitypen
ab-/einschalten kann. Bei C-Dateien ist es sinnvoll, aber nicht bei
strukturierten Dateien, die zum Beispiel feste Satz-/Feldlängen haben.
Frank M. schrieb:> und der Drops ist gelutscht
Es geht ja darum, sie bereits bei Editieren sehen zu können.
Dass man sie global wegwerfen kann, ist einfach. :)
Jörg W. schrieb:> Es geht ja darum, sie bereits bei Editieren sehen zu können.
Finde ich ein gutes Feature, werde ich in meinem Editor einbauen :-)
Beim Lesen von fremden Code ist das übrigens für mich ein
Qualitätskriterium. Sehe ich da Massen von Trailing Spaces, zeugt das
nicht unbedingt von besonderer Sorgfalt.
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?
900ss D. schrieb:> Weshalb möchtest du diese sehen?
Damit ich gleich weiß, wenn ich was falsch mache. Aber wie oben genannt,
fremde Codezeilen sind beim Editieren tabu, daher kein pauschales
Entfernen aller trailing whitespaces. (Ausnahme: wir einigen uns
explizit im Team, dass irgendwas so schlimm missraten ist, dass man mit
einem Rundumschlag irgendwas ändert.)
...und auch dann ist es nett, wenn man funktionale Änderungen von "ich
hab die Datei sowieso angefasst und deswegen mal die ganzen Trailing
Whitespaces gelöscht" zumindest in zwei separaten Commits ins VCS
einchecken kann.
Könnte man natürlich auch, wenn der Editor beim Öffnen automatisch alle
Trailing Whitespaces entfernt, aber das muss man merken, Speichern,
committen und sich dann noch daran erinnern, warum man die Datei
überhaupt geöffnet hat ;)
MfG, Arno
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?
Das ist ja zumindest konsistent.
Aber sowas hier sieht doch einfach nur hingeschludert aus. (Ich habe mir
jetzt einfach wahllos eine Datei aus irgendwelchem 3rdparty-Code
rausgegriffen, bei der ich per grep besonders viel trailing whitespace
gefunden habe – dass es gerade diese ist, hat also keine weitere
Bedeutung.)
A. K. schrieb:> Wenn hinter einem \ wahlweise ein Leerzeichen oder ein [CR]LF steht.
Oh ja, stimmt.... in makefiles ist das auf nicht so hübsch mit trailing
Spaces ;)
Ich falle zu selten auf die Klappe deshalb waren mir die Situationen
nicht eingefallen. Wenn ich dann mal Falle, brauch ich auch immer bis
ich darauf komme. Und dann "klatsch" vor die Stirn :)
Jörg W. schrieb:> Aber wie oben genannt, fremde Codezeilen sind beim Editieren tabu
Hmm.... das ist aber auch eine Philosophiefrage ;)
Egon D. schrieb:> Ich schreibe Texte blind im 10-Finger-System; daher habe ich mir> angewöhnt, auch am Zeilenende immer ein Leerzeichen zu machen, damit die> Worte nicht zusammen- kleben, wenn ich den Umbruch ändere.
Wie das Leerzeichen, welches ich in Deiner Formulierung
1
"zusammen- kleben"
sehe?
Du machst also vorsorglich hunderte bis tausende Trailing Spaces in
den Quellcode, damit Du nicht nicht eines nachträglich einfügen musst,
wenn Du mal den Umbruch änderst?
Wie verfährst Du dann bei mehrzeiligen C-Makros, wo das Backslash als
letztes Zeichen in der Zeile stehen muss, wie A.K. bereits schrieb? Da
lässt Du sie dann inkonsequenterweise weg?
Aber zu Deiner ursprünglichen Frage: Ich meinte es so, wie Jörg es
darstellte, nämlich die inkonsistente Anwendung. Bei globalen
Ersetzungen können solche eingestreuten Trailing Spaces im Fall von
Regular Expressions schon mal zum Stolperstein werden...
Egon D. schrieb:> Ich schreibe Texte blind im 10-Finger-System; daher> habe ich mir angewöhnt, auch am Zeilenende immer ein> Leerzeichen zu machen, damit die Worte nicht zusammen-> kleben, wenn ich den Umbruch ändere.
Da wir hier im Vi-Thread sind:
Der Vi fügt automatisch ein Leerzeichen ein, wenn zwei oder mehr Zeilen
mit J zu einer einzigen verbunden werden. Da muss man die Leerzeichen
nicht schon prophylaktisch ans Ende jeder Zeile schreiben.
Yalu X. schrieb:> Der Vi fügt automatisch ein Leerzeichen ein, wenn zwei oder mehr Zeilen> mit J zu einer einzigen verbunden werden.
Stimmt! Schon 1000mal genutzt und niemals über diese
"Selbstverständlichkeit" nachgedacht, sondern immer einfach so
hingenommen.
> Da muss man die Leerzeichen> nicht schon prophylaktisch ans Ende jeder Zeile schreiben.
Ja, das ist wirklich praktisch.
Frank M. schrieb:> Du machst also vorsorglich hunderte bis tausende Trailing> Spaces in den Quellcode, damit Du nicht nicht eines> nachträglich einfügen musst, wenn Du mal den Umbruch> änderst?
Nein. (Man merkt, dass Du nicht blind schreibst...)
Ich versuch's nochmal neu und von Anfang an:
Ich schreibe überwiegend natürlichsprachliche Texte;
Programmquelltexte sind in der Unterzahl. Blindschreiben
haben ich primär dafür erlernt, natürlichsprachliche
Texte flüssig schreiben zu können. (Blindschreiben schadet
beim Programmieren nicht, hilft aber auch nicht viel.)
In natürlichsprachlichen (in meinem Fall: deutschsprachigen)
Texten folgt auf jedes Wort ein Leerzeichen. Ich muss also
OHNEHIN nach jedem Wort ein Leerzeichen tippen!
Es ist daher für mich eine merkbare zusätzliche Anstrengung,
alle soundsoviele Worte eine AUSNAHME zu machen und das
(eigentlich unnötige) Leerzeichen am Ende der Zeile zu
unterdrücken.
Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte
außerdem eine Reihe von Nachteilen: Manche Programme (wie
z.B. "Write" unter Windows, das ich eine Weile lang benutzt
habe), bieten automatischen Umbruch. In diesem Falle weiss
ich sowieso nicht, welches das "letzte" Leerzeichen auf der
Zeile ist -- und kann es also auch nicht weglassen. Auch bei
manuellem Umbruch ist es lästig, bei Änderungen dauernd
nachträglich Leerzeichen einfügen zu müssen.
In der Summe ist es für mich seit 30 Jahren am praktikabelsten,
einfach nach jedem Wort ein Leerzeichen zu machen und mich
nicht darum zu scheren, ob dieses Wort am Zeilenende steht
oder nicht.
> Wie verfährst Du dann bei mehrzeiligen C-Makros, wo das> Backslash als letztes Zeichen in der Zeile stehen muss,> wie A.K. bereits schrieb? Da lässt Du sie dann> inkonsequenterweise weg?
Ja, muss ich ja. Was bleibt anderes übrig?
Das sind die Stellen, die ich dreimal kontrolliere, damit
auch WIRKLICH KEIN Leerzeichen dasteht...
> Aber zu Deiner ursprünglichen Frage: Ich meinte es so,> wie Jörg es darstellte, nämlich die inkonsistente> Anwendung. Bei globalen Ersetzungen können solche> eingestreuten Trailing Spaces im Fall von Regular> Expressions schon mal zum Stolperstein werden...
Okay... so ist das nachvollziehbar.
Egon D. schrieb:> Ich schreibe überwiegend natürlichsprachliche Texte; Programmquelltexte> sind in der Unterzahl.
Okay, das sind zwei vollkommen unterschiedliche Anwendungen. Ich bezog
mich auf Quellcode, nicht auf Romantexte.
Frank M. schrieb:> Egon D. schrieb:>> Ich schreibe überwiegend natürlichsprachliche Texte;>> Programmquelltexte sind in der Unterzahl.>> Okay, das sind zwei vollkommen unterschiedliche> Anwendungen. Ich bezog mich auf Quellcode, nicht auf> Romantexte.
Wenn Du mehr als die ersten vier Zeilen gelesen hättest,
wüsstest Du, dass ich AUCH von Quelltexten rede.
Ist aber nicht so wichtig.
Yalu X. schrieb:> Da muss man die Leerzeichen nicht schon prophylaktisch> ans Ende jeder Zeile schreiben.
Ich schreibe es ja nicht prophylaktisch an das Ende
jeder Zeile -- ich lasse nur das ohnehin jedem Wort
folgende Leerzeichen nicht ausnahmsweise am Zeilenende
weg!
Egon D. schrieb:> Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte> außerdem eine Reihe von Nachteilen: Manche Programme (wie> z.B. "Write" unter Windows, das ich eine Weile lang benutzt> habe), bieten automatischen Umbruch.
Vim auch. Du tippst einfach munter darauf los, mit einem Leerzeichen
nach jedem Wort. Ist die Zeile voll (die Textbreite ist ein änderbarer
Parameter), hüpft das letzte Wort automatisch an den Anfang der nächsten
Zeile, und das nun überflüssige Leerzeichen davor wird gelöscht.
Du kannst auch einen ganzen Textblock (oder den gesamten Text
neuformatieren, wenn nach dem Löschen von Text nicht mehr alle Zeilen
die Textbreite ausfüllen.
/*
* Dieses Umformatieren funktioniert auch in Quelltextkommentaren wie
* bspw. diesem hier. Die Sternchen am Anfang jeder Zeile bleiben dabei
* erhalten, ggf. werden auch neue hinzugefügt.
*/
# In Python und Bash-Skripten (mit der Raute als Kommentarsyntax)
# funktioniert das ebenso.
Yalu X. schrieb:> Egon D. schrieb:>> Das Fehlen dieses eigentlich unnötigen Leerzeichens hätte>> außerdem eine Reihe von Nachteilen: Manche Programme (wie>> z.B. "Write" unter Windows, das ich eine Weile lang benutzt>> habe), bieten automatischen Umbruch.>> Vim auch. Du tippst einfach munter darauf los, mit einem> Leerzeichen nach jedem Wort. Ist die Zeile voll (die> Textbreite ist ein änderbarer Parameter), hüpft das letzte> Wort automatisch an den Anfang der nächsten Zeile, und das> nun überflüssige Leerzeichen davor wird gelöscht.
Sehr hübsch.
Das bedeutet letztlich, dass vim etwas intelligenter ist
als Microsoft "write" oder mcedit -- was ja nicht wirklich
überrascht :)
Mal sehen. Vielleicht wage ich doch das Abenteuer meines
Lebens und wechsele vom mcedit auf irgendwas anderes...
Yalu X. schrieb:> Und das Beste: Trotz dieser mächtigen Erweiterung startet Vim (im> krassen Gegensatz zu Eclipse) immer noch in weniger als 1 Sekunde.
Das würde ich von einem Editor auch erwarten.
Ich achte grundsätzlich darauf, dass sich auch GUI Editoren schnell
öffnen lassen.
Ich mache deswegen sogar den gewählten Editor vom verwendeten Desktop
Environment abhängig. Denn GUI Bibliotheken, die schon im Speicher
liegen, müssen nicht erst geladen werden.
Unter KDE sind das bspw. qt und die kde libs, also muss es ein Editor
sein, der auf solchen Bibliotheken basiert, damit der schnell da ist,
wenn man ihn braucht.
Unter Mate, das gtk verwendet, würde ich daher bspw. kein Kate
verwenden.
Bei der IDE ist das aber alles nicht wichtig, denn die startet man am
Morgen einmal und beendet sie am Abend.
Die Startzeit ist daher bei dieser gar nicht so wichtig.
Rolf M. schrieb:> Nano schrieb:>> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur>> Speicherplatz belegen und den Parser des Compilers verlangsamen.>> LOL! Wie viele Millionen unnötige Whitespaces hast du denn> typischerweise in deinem Quellcode, wenn du dadurch tatsächlich> Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst> und das sogar dein größtes Problem ist?
Du kannst mir gerne einen Gegenbeweis liefern, warum man Whitespace am
Zeilenende unbedingt benötigt.
Für mich ist das Verschwendung von Ressourcen, die mit einer einfachen
Einstellung im Editor behoben werden kann und keinerlei weiteren Aufwand
kostet.
>>> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug>> auch beenden.>> Unfug sind Commits, die an allen möglichen Stellen Änderungen am> Whitespace haben. Wenn man sich die Diffs anschaut, machen die sich als> nerviges Rauschen bemerkbar.
Sie treten nicht auf, wenn andere sich daran halten würden ihren Editor
so einzustellen, dass sie die Whitespaces am Ende entfernen.
>>> Zumal mir auch kein sinnvoller Nutzen bekannt ist, der Sinn macht, dass>> Whitespace am Ende von Zeilen erhalten bleiben.>> Ein langjähriger Bug von Microsofts Mail- und Newsgroups-Software war,> dass vor dem Versenden ungefragt und nicht abstellbar alle Whitspaces an> Zeilenenden entfernt wurden. Das war deshalb ein Problem, weil der> übliche Signaturtrenner eine Zeile ist, die aus "-- " besteht, also mit> einem Space am Ende, damit man immer noch innerhalb des Textes ein "--"> machen kann, ohne dass das fälschlicherweise als Signaturtrenner erkannt> wird. So ziemlich jede Software hat das benutzt, um beim Antworten> automatisch die Signatur des ursprünglichen Posts zu entfernen.
Schön, das ist aber ein Mailprogramm, kein Texteditor.
Und es ist nur ein einziges Whitespace.
Es würde auch nichts dagegen sprechen, wenn man alle Whitespaces
entfernt, bis auf eines. Dann wäre das eigentliche Problem auch
entschäft und das mit der Signatur würde trotzdem funktionieren.
> Und ich hatte auch schon File-Formate, die ähnlich wie CSV waren, aber> wo die Felder durch TAB getrennt waren. Die Zahl der Felder pro Zeile> war fix, aber der Inhalt eine Feldes konnte durchaus auch leer sein. Das> heißt, es konnten auch am Zeilenende TABs stehen, die zwingend> erforderlich waren. Da ist es ziemlich doof, wenn der Editor die einfach> wegwirft.
Tabs sind keine Whitespacezeichen.
Jörg W. schrieb:> Nano schrieb:>> Bei 3rd Party Projekten wäre Kommunikation ratsam, damit die den Unfug>> auch beenden.>> Soso. Du meinst, es interessiert Atmicrochip irgendwie, dass wir die> TABs in den von ihnen gelieferten Treibern als „Unfug“ ansehen, und> deshalb wären sie sofort bereit, all ihren Kram umzuschreiben?>> Ein wenig weltfremd kommt mir das schon vor.
Hast du Atmicrochip schonmal gefragt?
Vielleicht ist das denen gar nicht klar, aber einleuchtend.
Vielleicht wären sie sogar dankbar, für den Hinweis, weil sie selbst
noch nie daran gedacht haben.
Von nichts kommt jedenfalls nichts.
Mit Stillstand kriegst du da nie etwas geändert.
Egon D. schrieb:> Mal sehen. Vielleicht wage ich doch das Abenteuer meines> Lebens und wechsele vom mcedit auf irgendwas anderes...
Da du oft natürlichsprachliche Texte schreibst, würde dir sicher auch
die automatische Einrückung (auch nach Neuformatierung) von Strichlisten
und Aufzählungen durch Vim gefallen:
- Dieses ist der erste Eintrag in der Strichliste. Wenn das Zeilenende
erreicht ist, wird automatisch umgebrochen und die nächsten Zeilen
passend eingerückt.
1. Dasselbe geschieht auch in Aufzählungen. Auch hier wird am Ende der
Zeile automatisch umgebrochen und passend eingerückt.
Kurz: Vim ist keine IDE wie Eclipse, kein Textverarbeitungsprogramm wie
Word und kein Betriebssystem wie Emacs ;-), hat aber ein Bisschen von
allem. Deswegen ist er für mich das Allround-Tool für die Eingabe und
Bearbeitung sämtlicher Texttypen, darunter auch meine Forenbeträge hier.
Anmerkung: Die obigen Einrückungen werden von der Forensoftware nur auf
gewöhnlichen PCs und Laptops korrekt dargestellt, Für Mobilgeräte wird
statt des Monospace- ein Proportional-Font verwendet, die Einrückungen
werden dabei entfernt.
Nano schrieb:> Hast du Atmicrochip schonmal gefragt?
Nein. Es gibt schließlich kein Gesetz, welches die Benutzung von <TAB>
verbieten würde, und in vielen Umgebungen ist das durchaus gängig.
Sie nicht zu verwenden, ist rein unsere eigene Konvention (die
allerdings natürlich auch eine ganze Menge anderer Entwickler nutzen),
aber irgendein Grund zur Beanstandung ist es nun wirklich nicht.
Wenn du schon mit eingesparten Zeichen argumentierst: ein <TAB> spart 4
oder 8 (je nach Konvention, da ist man sich halt noch viel weniger
einig) Leerzeichen. Das wäre also eher ein Argument pro <TAB>. :)
Egon D. schrieb:>> Wieso ist das jetzt ein Zeichen mangelnder Sorgfalt?
Es ist schlechter Programmierstil.
Der Parser des Compilers muss unnötig ein paar Zeichen mehr
durchwandern, braucht also länger. Auf moderner Hardware merkt man das
zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn
deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren
Teil zum CO2 beitragen.
Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim
Übertragen ohne Komprimierung die Datenmenge.
Gut möglich, dass es auch den Codeparser der IDE bzw. des Editors
ausbremst.
Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen
keinerlei nutzen. Sollte es eine Programmiersprache geben, wo man das
braucht, dann ist mir die nicht bekannt.
Frank M. schrieb:> Da macht man einmal ein:1,$s/\s\s*$//g> und der Drops ist gelutscht.
1,$s ist viel zu kompliziert. %s reicht auch ;-)
Nano schrieb:> Rolf M. schrieb:>> Nano schrieb:>>> Nichts ist schlimmer als sinnlose Whitespaces am Zeilenende, die nur>>> Speicherplatz belegen und den Parser des Compilers verlangsamen.>>>> LOL! Wie viele Millionen unnötige Whitespaces hast du denn>> typischerweise in deinem Quellcode, wenn du dadurch tatsächlich>> Platzprobleme oder irgendwie merklich verlängerte Compilezeiten bekommst>> und das sogar dein größtes Problem ist?>> Du kannst mir gerne einen Gegenbeweis liefern, warum man Whitespace am> Zeilenende unbedingt benötigt.
Es gibt auch noch etwas zwischen "nichts ist schlimmer" und "das braucht
man zwingend". Zum Beispiel: "stört überhaupt keinen".
Abgesehen davon habe ich dir ein Beispiel genannt, wo ich das benötigt
habe.
> Tabs sind keine Whitespacezeichen.
Doch, natürlich sind sie das.
Nano schrieb:> Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen> keinerlei nutzen. Sollte es eine Programmiersprache geben, wo man das> braucht, dann ist mir die nicht bekannt.
Whitspace ist eine davon:
https://de.wikipedia.org/wiki/Whitespace_(Programmiersprache)
Bei dieser Sprache erhöht Syntax-Highlighting die Lesbarkeit enorm,
weswegen Vim sie natürlich unterstützt. Aus Whitespace wird dann
Red-/Greenspace :)
Nano schrieb:> Der Parser des Compilers muss unnötig ein paar Zeichen mehr> durchwandern, braucht also länger. Auf moderner Hardware merkt man das> zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn> deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren> Teil zum CO2 beitragen.
Das ist doch Unsinn. Die zusätzliche Zeit zum Parsen im Compiler wird
vermutlich im Nanosekundenbereich liegen, oder zumindest mal weeeeeit
unterhalb der Grenze des Messbaren. Das ist so, als ob du Sprit sparen
willst, indem du das Auto öfters aussaugst, weil du dann 5 Gramm weniger
Dreck durch die Gegend fährst.
> Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim> Übertragen ohne Komprimierung die Datenmenge.
Auch hier ist das nicht signifikant. Wäre das ein Problem, dann müsstest
du auch deine Funktionsnamen besonders kurz wählen (was im übrigen
sicherlich auch die Compilezeit deutlich stärker reduziert als ein paar
weniger Whitspaces).
> Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen> keinerlei nutzen.
Aber produziert auch keinerlei signifikanten Schaden.
Jörg W. schrieb:> Nano schrieb:>> Bei der IDE ist das aber alles nicht wichtig, denn die startet man am>> Morgen einmal und beendet sie am Abend.>> Du meinst, sowas hier:>>
1
> $ ps aux | fgrep emacs
2
> j 1568 0.0 0.1 206172 40236 - S 14Nov19
3
> 25:04.06 emacs (emacs-26.1)
4
> j 57361 0.0 0.0 6652 2556 6 S+ 18:00
5
> 0:00.00 fgrep emacs
6
> j 77204 0.0 0.1 153336 40652 11 S 21Nov19
7
> 24:09.24 emacs (emacs-26.1)
8
>
>> Aber immerhin, das System wurde schon am 1. September gebootet, aus> irgendeinem Grund wurden die Emacse erst im November (neu) gebootet. ;-)
Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach
dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher
ihren Ursprung darin hat, bei manchen, insbesondere alten
Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen.
Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn
die schlecht geschrieben wurden.
Suspend to Disk oder irgendein anderer Modus (z.b. Standby) nutze ich
nur, wenn ich weiß, dass ich sowieso in sagen wir mal ner Stunde wieder
an den Rechner gehe.
Nano schrieb:> Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach> dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher> ihren Ursprung darin hat, bei manchen, insbesondere alten> Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen.> Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn> die schlecht geschrieben wurden.
Wer aus der Windows-Ecke kommt, ist das ja gewöhnt. Es hat anscheinend
Jahre gedauert, bis jemand gemerkt hat, dass Windows 95 nach knapp 50
Tagen reproduzierbar abstürzt. Das hat einfach nie einer so lange laufen
lassen ;-)
In der Unix-Ecke dagegen war man eher gewöhnt, dass die Maschinen
eigentlich niemals ausgeschaltet und höchstens mal alle paar Jahre neu
gebootet wurden. Da war allerdings ein Reboot dann auch schon mal mit
einem größeren Aufwand verbunden.
Rolf M. schrieb:>> Da macht man einmal ein:1,$s/\s\s*$//g>> und der Drops ist gelutscht.>> 1,$s ist viel zu kompliziert. %s reicht auch ;-)
:g/\ $/s///g
Viele Wege führen nach Rom ;)
Rolf M. schrieb:> Nano schrieb:>> Der Parser des Compilers muss unnötig ein paar Zeichen mehr>> durchwandern, braucht also länger. Auf moderner Hardware merkt man das>> zwar nicht, aber Kleinvieh macht irgendwo auch Mist und selbst wenn>> deswegen weltweit 10 Liter Öl mehr verbrannt werden müssen und ihren>> Teil zum CO2 beitragen.>> Das ist doch Unsinn. Die zusätzliche Zeit zum Parsen im Compiler wird> vermutlich im Nanosekundenbereich liegen,
Dann ist es kein Unsinn, denn auch Nanosekunden sind eine Einheit für
eine Zeitdauer.
> oder zumindest mal weeeeeit> unterhalb der Grenze des Messbaren. Das ist so, als ob du Sprit sparen> willst, indem du das Auto öfters aussaugst, weil du dann 5 Gramm weniger> Dreck durch die Gegend fährst.
Nunja, das Absaugen kostet Energie.
Bei Whitespaces multipliziert sich der Energieverbrauch wenn es viele
Nutzer und viele Compilevorgänge gibt.
Nimm mal den Linuxkernel als Beispiel. Wer weiß schon, wie oft, von
Millionen von Leuten der in den letzten 30 Jahren compiliert wurde.
Da summieren sich viele Nanosekunden. Gut möglich, dass es schon Jahre
sind.
Durch den Skalierungseffekt geht das recht schnell.
Und 1 Jahr nen Rechner betreiben, das ist dann durchaus messbar und in
Liter verbranntem Erdöl umrechenbar.
Die Zeit ist jedenfalls nicht 0, daher sind diese Parserschritte nicht
umsonst.
>> Es vergrößert unnötig und nutzlos den Speicherplatzbedarf und beim>> Übertragen ohne Komprimierung die Datenmenge.>> Auch hier ist das nicht signifikant. Wäre das ein Problem, dann müsstest> du auch deine Funktionsnamen besonders kurz wählen (was im übrigen> sicherlich auch die Compilezeit deutlich stärker reduziert als ein paar> weniger Whitspaces).
Naja, das eine hat einen Nutzen zwecks besserer Lesbarkeit, das andere
ist durch wenig Aufwand vermeidbar und hat in den meisten
Programmiersprachen keinen Nutzen.
Da sollte man schon abwägen.
>> Auf jeden Fall hat es bei den meisten gängigen Programmiersprachen>> keinerlei nutzen.>> Aber produziert auch keinerlei signifikanten Schaden.
Ich benutze manchmal die Cursor nach rechts Taste um in die nächste
Zeile an den Zeilenanfang zu kommen. Wenn da noch Dutzende
Whitespacezeichen sind, dann dauert das deutlich länger. Es kostet also
sogar noch reale Arbeitszeit.
Rolf M. schrieb:> Nano schrieb:>> Ich fahre meine Rechner grundsätzlich herunter und boote sie normal nach>> dem einschalten. Das ist einfach eine Angewohnheit von mir, die sicher>> ihren Ursprung darin hat, bei manchen, insbesondere alten>> Betriebssystemen, keine Leichen im RAM zu haben bzw. Platz zu benötigen.>> Bei Treibern kann es in manchen Fällen auch heute noch Sinn machen, wenn>> die schlecht geschrieben wurden.>> Wer aus der Windows-Ecke kommt, ist das ja gewöhnt. Es hat anscheinend> Jahre gedauert, bis jemand gemerkt hat, dass Windows 95 nach knapp 50> Tagen reproduzierbar abstürzt. Das hat einfach nie einer so lange laufen> lassen ;-)> In der Unix-Ecke dagegen war man eher gewöhnt, dass die Maschinen> eigentlich niemals ausgeschaltet und höchstens mal alle paar Jahre neu> gebootet wurden. Da war allerdings ein Reboot dann auch schon mal mit> einem größeren Aufwand verbunden.
Das ist nicht der Grund.
Es ist einfach so, dass Früher die Rechner weder Suspend to Disk noch
Standby kannten und man sie Zwecks Energiesparen oder weil die Lüfter
lärmten, während man schlafen wollte, ausschaltete.
Rolf M. schrieb:> Es hat anscheinend Jahre gedauert, bis jemand gemerkt hat, dass Windows> 95 nach knapp 50 Tagen reproduzierbar abstürzt.
Es stürzte nicht ab, es war nur nicht mehr bedienbar. :) (Weil der
Mauszeiger sich nicht mehr bewegte, wimre.) Ich glaube, das war im Jahr
2000, dass der Bugfix dafür kam.
Nano schrieb:> keine Leichen im RAM zu haben bzw. Platz zu benötigen
Die einzig nennenswerte Leiche heutzutage ist Firefox. Den muss man
öfter mal neu booten, da er sich aufbläht.
Meine Workstation zu Hause ist eh zugleich Server für alles Mögliche.
Der Laptop ist das natürlich nicht, aber suspend to RAM genügt mir da
völlig, von da aus ist er in wenigen Sekunden wieder „am Leben“, und
zwar exakt so, wie ich ihn vorher verlassen habe. Der Energieverbrauch
im Suspend-Modus ist hinreichend gering, dass ich das nicht als
nennenswertes Problem sehe.
Rolf M. schrieb:> Da war allerdings ein Reboot dann auch schon mal mit> einem größeren Aufwand verbunden.
Und zwar weil beispielsweise die AIX Systeme von IBM beim Start endlose
Tests durchführten. Deren x86-Server starteten nicht minder zäh.
Einen virtuellen LAMP-Server kannst du im Betrieb neu starten, ohne dass
die meisten Anwender das merken, weils nur den Bruchteil einer Minute
dauert. Schieb ihn auf Blech und es dauert 5 Minuten.
Egon D. schrieb:> In natürlichsprachlichen (in meinem Fall: deutschsprachigen)> Texten folgt auf jedes Wort ein Leerzeichen.
Schon mit diesem Satz widerlegst du dich selbst.
Egon D. schrieb:>> Vim auch. Du tippst einfach munter darauf los, mit einem>> Leerzeichen nach jedem Wort. Ist die Zeile voll (die>> Textbreite ist ein änderbarer Parameter), hüpft das letzte>> Wort automatisch an den Anfang der nächsten Zeile, und das>> nun überflüssige Leerzeichen davor wird gelöscht.>> Sehr hübsch.> Das bedeutet letztlich, dass vim etwas intelligenter ist> als Microsoft "write" oder mcedit -- was ja nicht wirklich> überrascht :)
vim intelligenter als write?
keine Ahnung - Aber wenn man die Anwender vergleicht,
wird es eindeutig;-)
A. K. schrieb:> Andi schrieb:>> Viele Wege führen nach Rom ;)>> Ein weiterer: 1,$ lässt sich als % abkürzen, also :%s/...
Du hast offenbar nicht gesehen, dass das die Antwort darauf war:
Rolf M. schrieb:> 1,$s ist viel zu kompliziert. %s reicht auch ;-)
Uhu U. schrieb:> Egon D. schrieb:>> In natürlichsprachlichen (in meinem Fall: deutschsprachigen)>> Texten folgt auf jedes Wort ein Leerzeichen.>> Schon mit diesem Satz widerlegst du dich selbst.
Faszinierend.
Enorm kleinkariert -- aber faszinierend.
Ich spreche Dir meine Anerkennung aus und überreiche Dir den
Sonderpreis für gute Beobachtungsgabe.
Yalu X. schrieb:> michael_ schrieb:>> Findet man in LINUX eigentlich noch den Ur-VI?>> Zumindest in Arch-Linux wird er defaultmäßig installiert.>> Ein POSIX-konformes Betriebssystem, das für die interaktive Nutzung> vorgesehen ist, sollte die Option POSIX2_UPE unterstützen und damit auch> einen Vi mitbringen. Siehe hier:>> http://www.open-std.org/JTC1/SC22/WG15/docs/options.htm>> Hier ist eine Liste der zu POSIX2_UPE gehörenden Tools (zweimal nach> POSIX2_UPE suchen), darunter auch Ex und Vi:>> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html
+1
Koppix hätte ich jetzt nicht empfehlen wollen, ich fand die Version von
2006 aus dem ct-Heft mit am Besten.
Die Frage, die offen bleibt, ist, welche vi version auf Windows 10 dabei
ist. Vermutlich Vim+Vimtutor - bzw. nicht die schlechteste Variante,
weil Vim mehrere Undoschritte erlaubt - die sozusagen wie Stützräder für
den Anfänger funktionieren. Die braucht man normalerweise auch.
Auf vi zurückzugreifen ist oft notwendig wegen der userfeindlichen
Linux-Eigenheiten: es gibt zwar auf jedem System userfreundliche
Editoren, aber in bester Linux-Tradition wird deren Name vor einem
Neu-User geheimgehalten: einen editor nano zu nennen ist nicht nur
blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester
Linux-Tradition.
In einer Anleitung zu einem Linux-Programm stand mal der Satz:
"die Hilfe wird mit J aufgerufen - Hehe, kleiner Scherz von mir, weil
Help garkein J enthält."
Ja, genauso macht man das als Linux-Programmierer. Wer intuitive
Programme schreibt wird in der Linux-Szene nur verachtet.
Georg
Georg schrieb:> einen editor nano zu nennen ist nicht nur> blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester> Linux-Tradition.
Mitnichten. Der Vorgänger hiess "pico". ;-)
Georg schrieb:> einen editor nano zu nennen ist nicht nur> blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester> Linux-Tradition.
Naja, also wem der nano kein Begriff ist der wird den vi(m) wohl auch
eher nicht kennen bzw. mit ihm umgehen können.
Georg schrieb:> Auf vi zurückzugreifen ist oft notwendig wegen der userfeindlichen> Linux-Eigenheiten: es gibt zwar auf jedem System userfreundliche> Editoren, aber in bester Linux-Tradition wird deren Name vor einem> Neu-User geheimgehalten: einen editor nano zu nennen ist nicht nur> blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester> Linux-Tradition.
Blödsinn! vi war und ist der Standard aller unixoiden Betriebssysteme.
Egal ob man auf FreeBSDs, OpenBSD, NetBSD, Solaris, Minix, OSX, MacOS
oder eben auch Linux unterwegs ist.
Linux spielt da eh nur eine Nebenrolle, genau wie Windows.
Egon D. schrieb:> Faszinierend.> Enorm kleinkariert -- aber faszinierend.>> Ich spreche Dir meine Anerkennung aus und überreiche Dir den> Sonderpreis für gute Beobachtungsgabe.
Danke, ich revanchiere mich mit dem Alice-Schwarzer-Preis für
Humorlosigkeit ;-)
> [überflüssiger whitespace]Rolf M. schrieb:> Aber produziert auch keinerlei signifikanten Schaden.
Jedoch sieht es unaufgeräumt und schlampig aus, manch ordnungsliebender
Geist mag das durchaus bereits als signifikante Beschädigung empfinden.
joe ist ganz nett, den hab ich mal ne Zeit lang benutzt.
Das funktionierte aber auch nur deshalb so gut weil ich in der
Jungsteinzeit der Homecomputerei auf dem C64 lange Zeit eine
Assembler-IDE benutzt habe deren Editor exakt die selben
Tastenkombinationen wie Joe benutzte und mir dann viele viele Jahre
später als mir zufällig Joe über den Weg lief dessen Bedienung auf
seltsame, fast schon unheimliche Weise vertraut vorkam.
Bernd K. schrieb:> Das funktionierte aber auch nur deshalb so gut weil ich in der> Jungsteinzeit der Homecomputerei auf dem C64 lange Zeit eine> Assembler-IDE benutzt habe deren Editor exakt die selben> Tastenkombinationen wie Joe benutzte
Joe hat viele Tastenkombinationen von Wordstar und Emacs übernommen.
Beide – insbesondere aber Wordstar – waren auch in den 80er Jahren die
Vorbilder für viele andere Texteditioren, so dass sich vermutlich auch
die von dir auf dem C64 genutzte Assembler-IDE daran orientiert hat.
Mit "jstar" und "jmacs" kann man Joe auch in einem puren Wordstar- bzw.
Emacs-Modus starten.
A. K. schrieb:> Georg schrieb:>> einen editor nano zu nennen ist nicht nur>> blödsinnig, sondern absichtliche anti-intuitive Verschleierung in bester>> Linux-Tradition.>> Mitnichten. Der Vorgänger hiess "pico". ;-)
Pico war mein Standardeditor unter Linux in der Kommandozeile, bis
irgendwann dann nano kam.
Nano schrieb:> Sheeva P. schrieb:>> Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal>> eine Dokumentation oder eine Präsentation erstellen, also mit Markdown,>> HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch>> schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder>> womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für>> Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine>> klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein>> Python-, Ruby-, Perl- oder PHP-Skript...>> Eclipse kann auch gewöhnliche Textdateien bearbeiten.
Inklusive Syntax-Highlighting, Codeeinrückung, Autovervollständigung und
all den netten Features, die das Entwicklerleben vereinfachen?
Verzeihung, ich wollte darauf hinaus, daß es die große Stärke von
Editoren wie n?vim? und Emacs ist, eben viel mehr nur eine Sprache zu
beherrschen. Wenn Du all das in Deiner IDE konfigurieren willst, was ich
mit meinem Emacs und meine Kollegen mit ihren vims täglich machen, dann
hast Du mindestens denselben Konfigurationsaufwand -- also: sofern das
überhaupt geht, ohne Dir eigene Plugins und Erweiterungen zu schreiben.
>> Da ist es ganz schön, daß man sich nicht drölfzig Programme und deren>> Bedienung merken muß, sondern einen Killer wie n?vim?>> Denkfehler!
Leider befürchte ich, daß der Denkfehler vielmehr auf Deiner Seite
liegt.
> Nano und kate erschließen sich intuitiv, da muss man keine Lernwoche> einplanen, wie bei vim.
Das ist zweifellos absolut richtig. Aber Kate gibt es nur auf Rechnern
mit GUI, Nano ist hinsichtlich seiner Funktionalität sehr begrenzt...
und ob Nano intuitiv ist, darüber ließe sich zwar streiten, aber:
geschenkt.
> Und was die IDE betrifft, in der sollte man ohnehin Zuhause sein.
Wenn man denn eine IDE benutzt... aber das muß man ja nicht. Und ich
denke, daß ebendies Dein Denkfehler ist: die weit verbreitete, dennoch
aber irrige Annahme, daß man unbedingt eine IDE bräuchte. Es geht auch
ohne, wenn man seine Werkzeuge beherrscht -- und zwar genauso effizient
und komfortabel, und häufig obendrein auch noch flexibler.
> Zum Entwicklen kann vim da ohnehin nicht mithalten.
Au contraire, mein Lieber. Ganz im Gegenteil kenne ich eine lange Reihe
von sehr fähigen Profis, die mit dem n?vim? arbeiten.
Ich persönlich habe mir solche IDEs immer mal wieder angeschaut und
werde mit den Dingern einfach nicht warm. Und die ausufernden Bereiche,
Menüs, Symbolleisten und was-nicht-alles verstellen mit den Blick auf
das mit Abstand Wichtigste: meinen Code. Die einzige Ausnahme (bei mir!)
sind Qt und Ähnliche, bei denen man schnell mal GUIs malen kann -- aber
auch da schreibe ich meinen Code dann wieder mit meinem Editor. Und das
SQL, die Elasticsearch-Suche, die Konfigurationsdateien, meine
Dokumentation und Präsentation in Markdown und LaTeX...
Wobei, mittlerweile entwickle ich nur noch sehr wenig klassische GUIs,
sondern eher Webapplikationen. Diesen Trend gibt es schon seit einigen
Jahren, weil Webapplikationen viel einfacher zu deployen und zu pflegen
sind, und ich wähne mich in guter Gesellschaft: die
PostgreSQL-Entwickler haben ihr Fatclient-GUI Pgadmin3 mittlerweile
eingestellt und setzen für Pgadmin4 auf eine webbasierte Lösung -- auch
für lokale Installationen.
Schon die meisten nicht vollkommen trivialen Webapps benötigen aber eine
Sprache, um die Handler zu implementieren, dazu eine Template-Sprache
für HTML, Ecmascript und CSS, häufig SQL, in meinem speziellen Fall oft
auch JSON, YAML (schon für Docker Compose), Dockerfiles,
Konfigurationsdateien für WSGI, Apache, ... das kann ich alles mit einem
einzigen Editor machen, und zwar mit allen klassischen IDE-Features und
ja, auch über eine dünne Verbindung von der Marina Frapa.
Was wäre Deine Empfehlung für diesen Fall? Eine IDE für den Code, dann
eines für HTML, CSS und JS und noch eins für SQL, JSON, YAML,
Dockerfiles, Konfigdateien? Und wnen ich eine Erweiterung mit
Boost::Python, also C++, oder ein Plugin zur Integration unserer
Java-Software schreibe, dann muß ich mir wieder eine neue IDE aneignen?
Sei mir nicht böse, aber ich habe schon drölfundölfzig Programme, die
ich beherrschen muß. Und wenn ich bei einer so zentralen Kernsoftware
wie meinem Editor die Möglichkeit habe, fünf bis zehn spezialisierte
Programme einzusparen... yay! ;-)
Aber, klar, das ist meine persönliche Sicht auf die Dinge. Jemand, der
weniger oft unterwegs ist und nicht mit Verbindungsproblemen zu tun hat,
oder wer im Wesentlichen nur in einer Sprache entwickelt, klar, der kann
natürlich zu einem anderen Schluß kommen. Kein Problem, ich will niemand
bekehren -- aber andererseits verbitte ich mir Versuche, mich zu
bekehren oder meine Werkzeuge als "falsch" oder Ähnliches
abzuqualifizieren. (Das ist im Übrigen auch hochgradig unprofessionell
und dumm, IMHO.)
> Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den> auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist> deutlich umständlicher, als die Buttons und Tastaturkombinationen in der> IDE.
Deswegen benutze ich den GDB einfach auf der Kommandozeile -- meistens
aufgerufen über ein Makefile. Klar ist es ganz nett, mit einem Druck auf
$Funktionstaste einen Debug-Build anzustoßen und den dann gleich im
Debugger zu starten, keine Frage. Aber dann habe ich wieder dieses
Thema, daß mein Debugfenster winzig klein ist und mit den Blick aufs
Wesentliche verstellt, so daß ich ständig hin- und herscrollen müßte
oder gar meine Bereiche in der IDE verstellen müßte. Ob das so viel
komfortabler ist als ein M+Tab und zweimal die Pfeiltaste zu betätigen?
Für mich nicht.
> Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt> sehen können möchte. Bei gdb muss man erst den step eingeben und dann> sagen, welche Variablen man anschauen will. Bei der IDE sieht man die> Variablenzustände immer und man drückt einfach seine Taste oder den> Button.
Sorry, aber das kann ich nicht gelten lassen, schließlich kann man den
GDB ganz wunderbar konfigurieren und steuern -- und zwar sogar
individuell und perfekt an das jeweilige Projekt angepaßt, genau wie man
es gerade braucht. Warum der in ein GUI-Programm eingebettet sein muß?
Keine Ahnung, sorry, und in etlichen Diskussionen über das Thema hat mir
leider auch noch kein Mensch ein überzeugendes Argument geliefert, warum
diese hohe Integration von verschiedenen Werkzeugen in ein GUI nötig
oder für mich nützlich sein sollte. Ich halte an meiner Arbeitsweise ja
nicht zwanghaft fest, ganz im Gegenteil ändere ich mich gerne, wenn ich
meine Arbeit dadurch besser (im Sinne von: komfortabler, schneller, ...)
machen kann. Vielleicht bist Du derjenige, der mich überzeugen kann? Nur
zu, viel Erfolg! ;-)
Sheeva P. schrieb:> Was wäre Deine Empfehlung für diesen Fall? Eine IDE für den Code, dann> eines für HTML, CSS und JS und noch eins für SQL, JSON, YAML,> Dockerfiles, Konfigdateien? Und wnen ich eine Erweiterung mit> Boost::Python, also C++, oder ein Plugin zur Integration unserer> Java-Software schreibe, dann muß ich mir wieder eine neue IDE aneignen?> Sei mir nicht böse, aber ich habe schon drölfundölfzig Programme, die> ich beherrschen muß. Und wenn ich bei einer so zentralen Kernsoftware> wie meinem Editor die Möglichkeit habe, fünf bis zehn spezialisierte> Programme einzusparen... yay! ;-)
Das ist aber beim besten Willen kein Alleinstellungsmerkmal von vim...
Visual studio code kann genauso syntax highlight für die meist
verbreiten sprachen, und mit Plugins gehen dann auch erweiterte
Funktionen wie Syntax Vervollständigung, Debugging und Code Analyse.
Das gleiche gilt für IDEs wie intellJ IDEA da kann man auch quasi alle
verbreiteten Sprechen sinnvoll benutzen.
Selbst mit Eclipse würde das gehen, auch wenn das da vermutlich etwas
Arbeit ist und es auch ansonsten eine ziemlich lahme Gurke ist...
Nano schrieb:> Wie sieht's eigentlich mit der Integration von UML in vim inkl> Codegenerierung und Darstellung von UML Diagrammen aus? :)
UML-Diagramm mit dia [1] bauen, Codegenerator laufen lassen. Nein, nicht
integriert -- aber trotzdem nicht weniger komfortabel -- und häufig mit
deutlich mehr Kontrolle über den generierten Code.
[1] https://de.wikipedia.org/wiki/Dia_(Software)
vim ist ein Texteditor und keine IDE.
Man kann mit plug-ins jede Menge erreichen aber eben nicht alles. Wie
kann man etwas mit vim vergleichen was 10-20 mal größer ist als vim?
Nano schrieb:> Auch fehlt ein Beispiel, wie man die GUI zusammenklickt.
GUIs klickt man mit einem GUI-Zusammenklick-Programm zusammen. Die
klugen Leute von QT haben das verstanden und bieten neben der IDE
Creator auch den GUI-Builder Designer an. ;-)
Jörg W. schrieb:> Nano schrieb:>> Die Beispiele haben nicht aufgezeigt, wie gut in vim das Debuggen>> intregiert ist.>> Ja, das müsste jemand zeigen, der Vim wirklich aktiv benutzt.
Entschuldige, Jörg, aber Du läßt Dich dabei gerade auf sein "Argument"
ein, daß alle Entwicklungswerkzeuge in einem einzigen Programm
integriert sein müßten. Aber das ist de facto nicht richtig und
widerspricht natürlich auch der guten alten UNIX-Philosphie, daß jedes
Programm idealerweise nur genau eine Aufgabe erledigt, die aber richtig
gut. ;-)
Mit NerdTree hat man den Überblick über seine Verzeichnissbäume - den
Windowmanager braucht man eigentlich nur für den Browser ... und wenn
man klug ist, nimmt man einen Tiling WM und navigiert in dessen Fenstern
mit hjkl - genau wie im tmux
Egon D. schrieb:> In natürlichsprachlichen (in meinem Fall: deutschsprachigen)> Texten folgt auf jedes Wort ein Leerzeichen.
Verzeihung, aber nein, und dafür ist Dein eigener Text ein gutes
Beispiel: hinter "Fall", "deutschsprachigen" und "Leerzeichen" folgt
eben kein Leer-, sondern jeweils ein Satzzeichen. ;-)
Sheeva P. schrieb:> Entschuldige, Jörg, aber Du läßt Dich dabei gerade auf sein "Argument"> ein, daß alle Entwicklungswerkzeuge in einem einzigen Programm> integriert sein müßten.
Psst, auch bei anderen IDEs sind die Debugger üblicherweise als
separates Tool, das halt dann mit dem Framework kommuniziert. ;-) Erzähl
ihm jetzt nicht, dass der GDB das auch kann …
Ich meinte eigentlich, wie eine Debug-Sitzung mit einem Vim so aussieht.
Ich könnte sie für den Emacs zeigen, aber das ist ja gerade nicht das
Thema hier.
Sheeva P. schrieb:> Verzeihung, aber nein, und dafür ist Dein eigener Text ein gutes> Beispiel:hinter "Fall", "deutschsprachigen" und "Leerzeichen" folgt> eben kein Leer-, sondern jeweils ein Satzzeichen. ;-)
Alle Achtung! Du bist ja fast so ein scharfer Hund wie Uhu. Nur dass
dieser denselben Sachverhalt schon 1 Tag früher aufgedeckt hat :)
Damit Egon nicht dieselbe Antwort zweimal schreiben muss:
Egon D. schrieb:> Faszinierend.> Enorm kleinkariert -- aber faszinierend.>> Ich spreche Dir meine Anerkennung aus und überreiche Dir den> Sonderpreis für gute Beobachtungsgabe.
Max H. schrieb:> Das ist aber beim besten Willen kein Alleinstellungsmerkmal von vim...
Nein, das stimmt... aber ich bin ein Emacs-User. ;-)
> Visual studio code kann genauso syntax highlight für die meist> verbreiten sprachen, und mit Plugins gehen dann auch erweiterte> Funktionen wie Syntax Vervollständigung, Debugging und Code Analyse.
Visual Studio Code ist ja auch keine IDE, sondern ein Editor -- wie
n?vim? oder Emacs auch. Und mit entsprechenden Konfigurationen und
Plugins können die das auch alle.
Ich finde es übrigens ausgesprochen spannend, daß es mittlerweile sogar
wieder Bewegung im Bereich der Editoren gibt. Über Jahre hinweg wurden
Monolithen und IDEs in den Markt gedrückt, und die wohl
höchstentwickelten Editoren für Windows waren aus meiner (sehr
beschränkten) Sicht UltraEdit und Notepad++. Aber seit einigen Jahren
tut sich wieder etwas: Atom und Sublime haben den Markt betreten, und
sogar Microsoft selbst baut nach den vielen Jahren, in denen Visual
Studio als das Maß aller Dinge gepriesen würde, mit Visual Studio Code
wieder etwas, das im Prinzip "nur" ein leistungsfähiger Editor ist.
> Das gleiche gilt für IDEs wie intellJ IDEA da kann man auch quasi alle> verbreiteten Sprechen sinnvoll benutzen.
Für viele verbreitete Programmiersprachen stimmt das, aber auch für
YAML, Markdown, JSON, Dockerfiles? Zudem ist IDEA leider GUI-only, also
wird es mit meiner dünnen Connection im Wattenmeer leider auch nichts...
Und dann, und das ist mein wesentlicher Punkt: IDEA ist nach allem, was
ich davon gesehen habe, ein wirklich feines Werkzeug, aber: es ist halt
kommerzielle Software, und ich habe ehrlich gesagt überhaupt keine Lust,
Geld für ein Werkzeug auszugeben oder meinen Chef von dieser Ausgabe zu
überzeugen, wenn ich die Funktionen mit einem OSS-Werkzeug abdecken
kann, bei dem ich sogar mitarbeiten und meine Bugfixes und Erweiterungen
beitragen kann.
> Selbst mit Eclipse würde das gehen, auch wenn das da vermutlich etwas> Arbeit ist und es auch ansonsten eine ziemlich lahme Gurke ist...
Einer meiner Entwicklerkollegen, die -- mit einer Ausnahme -- allesamt
Eclipse benutzen, hat vor einigen Wochen einen neuen Rechner bekommen.
Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil
zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte. Ich
möchte mir anhanddessen kein Urteil über IDEs im Allgemeinen, Eclipse im
Besonderen oder gar IDEA erlauben, aber... "\(".)/"
Sheeva P. schrieb:> Nano schrieb:>> Sheeva P. schrieb:>>> Auch in so einem Entwicklerleben kommt es vor, daß man zum Beispiel mal>>> eine Dokumentation oder eine Präsentation erstellen, also mit Markdown,>>> HTML oder LaTeX arbeiten will. Hin und wieder schreiben Entwickler auch>>> schonmal Code in JSON, XML, SQL, ein Shellscript, eine Batchdatei, oder>>> womöglich ein Dockerfile, eine docker-compose.yml, eine Deployment für>>> Kubernetes oder AWS, ein Ansible-Playbook, ... oder einfach mal so eine>>> klassische INI-Datei, ja, sowas gibt's auch noch. Oder, meine Güte, ein>>> Python-, Ruby-, Perl- oder PHP-Skript...>>>> Eclipse kann auch gewöhnliche Textdateien bearbeiten.>> Inklusive Syntax-Highlighting, Codeeinrückung, Autovervollständigung und> all den netten Features, die das Entwicklerleben vereinfachen?> Verzeihung, ich wollte darauf hinaus, daß es die große Stärke von> Editoren wie n?vim? und Emacs ist, eben viel mehr nur eine Sprache zu> beherrschen. Wenn Du all das in Deiner IDE konfigurieren willst, was ich> mit meinem Emacs und meine Kollegen mit ihren vims täglich machen, dann> hast Du mindestens denselben Konfigurationsaufwand -- also: sofern das> überhaupt geht, ohne Dir eigene Plugins und Erweiterungen zu schreiben.
Wenn eine Programmiersprache oder Aussschreibungssprache für eine IDE
Relevanz hat, dann wird es bei einer vielfach genutzten IDE, die nicht
nur für eine Sprache geschrieben wurde, über kurz oder lang dafür auch
Support geben.
Der Schwerpunkt einer IDE ist nunmal das Programmieren und mehr braucht
es auch nicht.
Will ich einen Editor, dann nehme ich auch einen Editor.
> Was wäre Deine Empfehlung für diesen Fall? Eine IDE für den Code, dann> eines für HTML, CSS und JS und noch eins für SQL, JSON, YAML,> Dockerfiles, Konfigdateien?
Ich schreibe keine Webapps.
Ich brauche eine gute Integration des Debuggers und da hat eine IDE ihre
stärken.
> Und wnen ich eine Erweiterung mit> Boost::Python, also C++, oder ein Plugin zur Integration unserer> Java-Software schreibe, dann muß ich mir wieder eine neue IDE aneignen?
Eclipse kann C++ und Java.
> Sei mir nicht böse, aber ich habe schon drölfundölfzig Programme, die> ich beherrschen muß. Und wenn ich bei einer so zentralen Kernsoftware> wie meinem Editor die Möglichkeit habe, fünf bis zehn spezialisierte> Programme einzusparen... yay! ;-)
Ich halte dich davon nicht ab.
Du kannst vim auch in die IDE integrieren.
Wurde oben ja schon erwähnt.
Ich will eine gute Debuggerintegration und da hat mich vim noch nicht
überzeugen können.
Die meisten Artikel machen an dem Punkt zu dem noch stopp und zeigen
nichts.
> oder meine Werkzeuge als "falsch" oder Ähnliches> abzuqualifizieren. (Das ist im Übrigen auch hochgradig unprofessionell> und dumm, IMHO.)
Das habe ich nirgendwo getan.
Ich sagte nur, das vim die Spezialisierung fehlt, die eine IDE hat und
das stimmt auch. Gibst du ja mit deinem Qt Beispiel und GUI
zusammenklicken selbst zu.
>> Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den>> auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist>> deutlich umständlicher, als die Buttons und Tastaturkombinationen in der>> IDE.>> Deswegen benutze ich den GDB einfach auf der Kommandozeile
Und das ist nicht besser.
Wie ich bereits sagte, ich habe einfach keinen Bock, jedes mal nach
jedem n(ext) den Variablenzustand abzufragen.
Ich will den Zustand von ausgewählten Varibalen in nem extra Kasten bei
jedem Schritt sehen ohne dem Debugger extra sagen zu müssen,
aktualisiere nen Kasten bzw. spuck die Liste aus. Und das auch dann,
wenn sich die Variablen nicht verändert haben.
gdb war mir deswegen zu viel Tipparbeit.
Und in vim war's nicht wesentlich besser gelöst, schon gar nicht mit den
Defaulteinstellungen.
Eine IDE hat eine Debuggeransicht und zeigt das alles auf einen Blick.
>> Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt>> sehen können möchte. Bei gdb muss man erst den step eingeben und dann>> sagen, welche Variablen man anschauen will. Bei der IDE sieht man die>> Variablenzustände immer und man drückt einfach seine Taste oder den>> Button.>> Sorry, aber das kann ich nicht gelten lassen, schließlich kann man den> GDB ganz wunderbar konfigurieren und steuern -- und zwar sogar> individuell und perfekt an das jeweilige Projekt angepaßt, genau wie man> es gerade braucht.
Warum soll das nicht gelten?
Das Problem hatte ich, als ich mich vor Jahren mit gdb gründlich
auseinandergesetzt habe. Kann sein, dass ich die Details nicht mehr so
genau wiedergeben kann, aber danach bin ich zu ner IDE gewechselt und
die Welt war wieder in Ordnung.
> Warum der in ein GUI-Programm eingebettet sein muß?
Der soll mir ne Sicht zu jeder Zeit geben.
So arbeitet er aber nicht, er schiebt die Zeilen von unten nach oben und
wenn man nen Überblick will, muss man den wieder abfragen oder macht es
so, dass man nur dann was mitgeteilt kriegt, wenn sich der Wert einer
variable verändert hat, das reicht mir aber nicht.
Sheeva P. schrieb:> Nano schrieb:>> Wie sieht's eigentlich mit der Integration von UML in vim inkl>> Codegenerierung und Darstellung von UML Diagrammen aus? :)>> UML-Diagramm mit dia [1] bauen,
Das letzte mal, als ich dia zum UML Diagramm bauen getestet habe, war
2004.
Und das war damals Murks, weil der Workflow grottig war und dia zwar
Vektordiagramme erstellen konnte, aber die Integration der Semantik im
Bezug auf UML einfach nicht gut von der Hand ging.
Da gab es schon damals weitaus bessere UML Editoren mit Spezialisierung
auf UML und gibt es heute erst Recht.
Dia ist mehr so nen Allrounder für allgemeine Diagramme, vergleichbar
mit Viso, aber nichts für UML (damals). Wie es heute ist, keine Ahnung,
ist mir aber auch Wurst.
Jörg W. schrieb:> Sheeva P. schrieb:>> Entschuldige, Jörg, aber Du läßt Dich dabei gerade auf sein "Argument">> ein, daß alle Entwicklungswerkzeuge in einem einzigen Programm>> integriert sein müßten.>> Psst, auch bei anderen IDEs sind die Debugger üblicherweise als> separates Tool, das halt dann mit dem Framework kommuniziert. ;-) Erzähl> ihm jetzt nicht, dass der GDB das auch kann …
Das ist mir bekannt, keine Sorge.
Und ja, mir geht es um die Debug Sitzung an sich.
Sheeva P. schrieb:> Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil> zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte
Man muss fairerweise sagen, dass die grundsätzliche Lernzeit beim Vi
(beim Emacs ganz ähnlich) schon etwas länger ist. So grob geschätzt in
etwa so lange wie akustische Morsecodes verarbeiten lernen. Die passen
deswegen so gut als Analogie, weil man auch hier die Geschwindigkeit
steigern kann..
Beim nano braucht man wohl nicht so lange, aber ein Readme braucht man
schon, so richtig intuitiv wie vielleicht Notepad ist der noch lange
nicht.
Dann finde ich noch so interessant, dass oben nach den herausragenden
Stärken des Vi gefragt wurde, und sich hier die Emacs et al-Freunde
begeistert an der Diskussion beteiligen. Aber um den Emacs überholen zu
können, da müssten die Vi-Clones schon auch langsam mal an einem Konzept
als Ersatz-Desktop arbeiten. Ich denke mal, so weit sind die Vis noch
lange nicht ;)
Letztlich geht es mir eher so..in Fedora schreibe ich auch in gedit.
Aber das ist eben kein Notepad (und Notepad++ schon mal gar nicht) und
auch nicht so interessant wie vi. Früher hätte ich noch Assemlercode mit
Notepad++ zusammengestöpselt. Mittlerweile hat aber u.a. die Freude über
den Watcom-vi (den man ganz ähnlich wie den blöden EDLIN mit der Maus
bedienen kann! - aber EDLIN..*lach*) und auch die Editorerfahrung
generell eher dazu geführt, dass ich Vi (mehr und mehr) vorziehe und die
Alternativen verblassen..
Assemblerprojekte würde ich in Kombination mit Papier und Bleistift und
dem Vi machen.
Bei Java bleib ich auch lieber beim Vi, dann kann ich mich einfach
besser auf meinen eigenen Kram konzentrieren. Macht irgendwie auch mehr
Spaß.
rbx schrieb:> Beim nano braucht man wohl nicht so lange, aber ein Readme braucht man> schon, so richtig intuitiv wie vielleicht Notepad ist der noch lange> nicht.
Beim nano muss man nur 6 Sachen wissen.
STRG+W = Suchen
STRG+O = In Datei speichern
STRG+X = beenden
STRG+C = Cursorposition oder Abbruch (z.b. wenn man doch nichts
speichern will)
STRG+K = Zeile oder markierte Zeilen ausschneiden und in Zwischenablage
ablegen
STRG+U = Zeile oder Zeilen aus Zwischenablage einfügen
Und alle diese Befehle werden direkt unten eingeblendet und können
jederzeit abgerufen werden, solange man nur weiß, dass das Zeichen ^ für
die STRG Taste steht und der darauf folgende Buchstabe für die
Buchstabentaste.
Der Rest ergibt sich von selbst bzw. findet man nach und nach raus.
In dem Zustand ist er aber für Laien schon gut benutzbar um alle Arten
von Configdateien zu bearbeiten.
Er ist damit vielleicht nicht so intuitiv wie edit.exe unter MS-DOS >=
5.x,
aber mehr als intuitiv genug um ohne lange Einarbeitungszeit seinen
kleinen Job erledigt zu bekommen.
Sheeva P. schrieb:> daß mein Debugfenster winzig klein ist und mit den Blick aufs> Wesentliche verstellt, so daß ich ständig hin- und herscrollen müßte> oder gar meine Bereiche in der IDE verstellen müßte
Eclipse hat extra dafür zwei separat konfigurierbare Ansichten, startest
Du eine Debugsitzung schaltet es die Ansicht um.
Sheeva P. schrieb:> einen neuen Rechner bekommen.> Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil> zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte.
Das wäre mit vim nicht viel anders gelaufen, bis er da alle 42 Plugins
wieder drin hat und alles wieder so konfiguriert ist daß es als
IDE-Ersatz taugt wird auch nicht weniger Zeit vergehen.
Und Eclipse ist in weniger als 10 Minuten wieder frisch eingerichtet
wenn die Toolchain und alles schon installiert sind, das geht ratzfatz
wenn man es lang genug benutzt hat und schon gut genug kennt. Hab das
erst neulich gesehen als wir nen Kollegen von Windows auf Linux
umgestellt haben, die ganze Aktion ging an einem Tag (mit nur ganz
leichten und schnell abklingenden Nebenwirkungen danach) und die
Eclipse-Installation hat noch vor der Mittagspause schon wieder
vollumfänglich funktioniert, mit J-Link, Debuggen und allem.
Das war also sowieso ein Anfänger wenn der 3 Tage gebraucht hat, mit vim
wäre er demzufolge bis heute noch nicht fertig.
Bernd K. schrieb:> Sheeva P. schrieb:>> einen neuen Rechner bekommen.>> Danach war er drei Tage lang nur sehr eingeschränkt arbeitsfähig, weil>> zunächst sein neuinstalliertes Eclipse konfiguriert werden wollte.>> Das wäre mit vim nicht viel anders gelaufen, bis er da alle 42 Plugins> wieder drin hat und alles wieder so konfiguriert ist daß es als> IDE-Ersatz taugt wird auch nicht weniger Zeit vergehen.
Das ist kein Problem. Man kopiert die .vimrc und das Verzeichnis .vim
rüber, und schon tut alles wie gewohnt. Dauert keine 2 Minuten.
Ja, und bei Eclipse habe ich schon viele Plug-ins gesehen, die sich in
einer neuen Version nicht mehr installieren lassen. Werden sie nicht
angepasst, dann sind nicht kompatibel.
Bei Vim scheint aber alles zu laufen. Auch wenn plug-ins mehrere Jahre
alt sind.
Ein paar kleine Worte zum Thema Debugger:
Auch ich benutze Debugger, aber immer seltener. Das liegt nicht primär
daran, dass ich kaum noch Fehler mache (das natürlich auch ;-)) oder
weil es keine perfekte Debugger-Integration in Vim gibt, sondern weil
ich andere Software auf eine andere Weise als früher schreibe.
Während des Studiums war ein Debugger für mich das Größte, weil man
damit seinen Bubble-Sort-Code wunderschön dabei beobachten konnte, wie
das zu sortierende Array langsam immer mehr an Ordnung gewinnt. Auch
später habe ich bei der Programmierung unter Windows mit Visual Studio
den integrierten Debugger gerne eingesetzt.
Mit der Zeit wurden die Softwareprojekte immer komplexer und die zu
verarbeitende Datenmenge immer größer, wodurch es immer schwieriger
wurde, dem Debugger die zur Auffinden eines Fehlers benötigten
Informationen zu entlocken, denn:
- Ein Debugger kann immer nur eine relativ geringe Anzahl von Variablen
sinnvoll darstellen.
- Oft kennt man zwar die zu erwartenden Endergebnisse eines Algorithmus,
nicht aber die dorthin führenden korrekten Zwischenergebnisse.
- Bei Echtzeitanwendungen (bspw. Regelungen) kommt noch erschwerend
hinzu, dass ein Programm nicht ohne weiteres unterbrochen und wieder
fortgesetzt werden kann.
Beim Bubble-Sort, den man zu Testzwecken auf ein Array mit 10 Elementen
anwendet war das alles kein Problem. Man setzte einfach einen Breakpoint
auf das Ende der Swap-Operation und konnte dann nach jedem Schritt die
Korrektheit verifizieren.
Einen Kontrast dazu stellen bspw. Bildverarbeitungsanwendungen dar, wo
dieses Vorgehen nicht einmal ansatzweise funktioniert. Wer möchte sich
schon die numerischen RGB-Werte von ein paar Millionen Pixel anschauen
und entscheiden, ob diese korrekt sind oder nicht? Entsprechendes gilt
für praktisch alle Anwendungen, die mit großen Datenmengen arbeiten und
die zu Testzwecken nicht herunterskaliert werden können.
Das Hauptproblem besteht IMHO darin, dass sich die Debugger-Technik in
den letzten 30 Jahren bei Weitem nicht so schnell weiterentwickelt hat
wie die Komplexität von Softwareprojekten gestiegen ist.
Deswegen sind zusätzliche Debugging-Tools gefragt, bspw.
- Tools zur grafischen Aufbereitung von Daten
- Logging-Tools
- Tools für Analyse der geloggten Daten
- u.v.m.
Hinzu kommen noch einige nicht anwendungsspezifische Tools bspw. zum
Auffinden von Memory-Leaks, Buffer-Overflows und dergleichen (Valgrind)
und noch vieles mehr.
Es wäre völlig unsinnig, all diese Tools in eine IDE packen zu wollen,
zumal es sich dabei oft um anwendungsspezifische Entwicklungen handelt,
die man deswegen auch selber in die IDE integrieren müsste. Das würde
viel Zeitaufwand mit wenig resultierendem Nutzen bedeuten.
So gesehen ist klassische Debugger nicht das zentrale Debugging-Tool,
sondern nur eines von vielen, die gleichberechtigt nebeneinander stehen.
Genauso wie alle anderen wird der Debugger bei Bedarf für eine ganz
bestimmte Klasse von Fehlern herangezogen. Hat er seine Aufgabe erfüllt,
liegt er vielleicht wieder eine Woche lang ungenutzt herum.
Ich verwende Debugger nach wie vor, aber nicht integriert in einen
Editor oder eine IDE, sondern als Stand-Alone-Anwendung, die erst dann
gestartet wird, wenn sie wirklich gebraucht wird. Die Auswahl reicht vom
nackten GDB über einfache GUI-Frontends (kdbg, nemiver) bis hin zum
Stand-Alone-Debugger von Eclipse.
Für die paar Male pro Monat, wo ich tatsächlich einen Debugger benötige,
ist GDB-TUI völlig ausreichend. Ich habe dabei Zugriff auf sämtliche
GDB-Features (auch die ganz neuen, die noch in keine IDE Einzug gehalten
haben), und das bei durchaus akzeptabler Ergonomie.
Das allerwichtigste Debugging-Tool ist aber immer noch der eigene Kopf.
Er kann in mehreren unterschiedlichen Modi betrieben werden, die beiden
wichtigsten sind:
- Man liest den Quellcode in der Umgebung, wo der Fehler vermutet wird,
durch und fragt sich bei jedem Abschnitt, warum man das so gemacht
hat. Wenn man für diese Überlegung länger als eine Minute braucht,
schreibt man das Ergebnis am Besten gleich als Kommentar in den Code.
Des Weiteren überlegt man sich, mit welchen fiesen Daten man den
Algorithmus am ehesten zum Versagen bringen könnte, und ob diese Daten
tatsächlich in dieser Form auftreten können. Die Chancen stehen gut,
dabei auch Fehler zu finden, die bisher gar nicht aufgetreten sind.
- Man schaltet den PC aus und tut etwas Entspannendes (bspw. spazieren
gehen, duschen oder auf dem Sofa liegen). Dann lässt man den
Programmablauf im Geiste vorüberziehen. Aber nicht im Single-Step und
mit detaillierten Datentypen wie im Debugger, sondern mathematisch/
logisch auf hoher Abstraktionsebene. Irgendwann macht es dann Klick,
also ob man gerade in eine Breakpoint hineingelaufen wäre, und man hat
den Fehler (oder zumindest einen Kandidaten dafür) gefunden.
Auf diese Weise habe ich tatsächlich schon des Öfteren extrem
hartnäckige Fehler gefunden, die sich zuvor trotz größter Anstrengung
mit keinem Software-Tool lokalisieren ließen.
Vielleicht gibt es für so etwas ja irgendwann einen KI-Debugger, aber
derzeit muss dafür noch die NI herhalten, und das wird sicher noch viele
Jahre so bleiben.
Während ich dies schrieb, habe ich mich gefragt, ob ich mit meiner
Arbeitsweise alleine dastehe, und deswegen mal gegoogelt, was andere
über dieses Thema denken. Dabei bin ich u.a. auf zwei interessante
Artikel gestoßen:
https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/https://blog.jgc.org/2007/01/tao-of-debugging.html
Im ersten werden einige prominenter Softwareentwickler genannt, die dem
klassischen Debugger ebenfalls skeptisch und teilweise sogar ablehnend
gegenüberstehen. Sie heißen
Linus Torvalds (Linux), Guido van Rossum (Python), Brian W. Kernighan
(Unix), Rob Pike (Unix, Go) und Robert C. Martin (Agile Programming).
Wenn man länger suchen würde, würde man sicher noch weitere finden.
Aber zurück zum Thema:
Ich habe gerade entdeckt, dass bei Vim seit gut eineinhalb Jahren ein
Frontend (Termdebug) für GDB im Lieferumfang enthalten ist. Mal sollte
vielleicht öfter mal die Release-Notes lesen ;-)
Hier ist ein Screenshot von Bram:
https://www.vim.org/images/terminal_debugger.png
Mein erster Eindruck: Spartanisch, Vim-typisch nicht als Eye-Catcher
ausgelegt, aber funktionell und vollständig. Man könnte es vielleicht
beschreiben als GDB-TUI im Editor mit ein paar netten Mausfunktionen
(Buttons für Step, Next usw. und Anzeige von Variableninhalten per
Mouse-Hover). Ich werde evtl. noch ein paar Shortcuts hinzufügen und es
dann künftig anstelle von GDB-TUI verwenden (die paar Male, wo ich so
etwas tatsächlich brauche).
Du musst den in einer IDE vorhandenen Debugger nicht benutzen, aber du
darfst und kannst bei Bedarf.
Ich z.B. starte aue Eclipse heraus eine ganze Reihe von Debuggern
(MPLABX, Lauterbach Trace32, Green Hills...).
Das geht also nach wie vor dass du externe Tools in deinen Workflow
integrierst.
Lediglich für den gdb bringt Eclipse per default eine recht gute
Integration mit, wobei Eclipse nur die GUI mitbringt, im Hintergrund
läuft ein handelsüblicher gdb oder avr-gdb
(Wobei ich diesen unter Linux leider nie verlässlich zusammen mit
avarice und dem Dragon zum laufen gebracht habe, egal ob mit oder ohne
Eclipse).
Aber du hast recht, komplexe Applikationen debuggt man heute eh ganz
anders.
Der Hardware-Debugger ist eigentlich nur hei hardwarenahem Zeugs noch
richtig nützlich.
Yalu X. schrieb:> Auf diese Weise habe ich tatsächlich schon des Öfteren extrem> hartnäckige Fehler gefunden, die sich zuvor trotz größter Anstrengung> mit keinem Software-Tool lokalisieren ließen.
Ich habe gestern auch erst wieder einen Bug gefunden, den ich vorher
trotz intensiver Suche und Testcode nicht gesehen habe … Daraufhin habe
ich beschlossen, das existierende API neu mit selbst geschriebenem
Inhalt zu befüllen (der vorherige stammte teilweise aus Atmels ASF) –
und beim drüber Nachdenken fiel mir sofort wie Schuppen aus den Haaren,
was im ASF-geerbten Code falsch war. ;-) (Zur ihrer Ehrenrettung: in
neueren Versionen hatten sie den Bug auch bereits korrigiert.)
Ansonsten debuggen wir auch häufig genug mit dem Logic Analyzer, da kann
man einfach mit ein paar GPIOs bestimmte interne Zustände verfolgen
lassen und so trotzdem noch alles in Echtzeit tuckern lassen.
Der GDB ist aber dennoch häufig mal mit von der Partie.
Le X. schrieb:> (Wobei ich diesen unter Linux leider nie verlässlich zusammen mit> avarice und dem Dragon zum laufen gebracht habe, egal ob mit oder ohne> Eclipse).
Ja, das liegt teilweise auch an der Art und Weise, wie diese Atmel-Tools
seinerzeit in AVR Studio eingebunden worden sind. Das war eine
grundlegend andere Herangehensweise als GDB, was dazu führt, dass GDB
unverhältnismäßig viele low-level-Aktionen auf den ICEs angeworfen hat,
die aber wiederum wegen der Arbeitsweise von Atmel Studio im ICE relativ
schwerfällig abgearbeitet worden sind.
Mit dem Übergang auf den Visual Studio hat sich das auch in den
Atmel-Tools geändert, denn deren Debugger ist von der Funktionsweise
grundlegend genauso low-level wie GDB. (Leider ist die
AVaRICE-Einbindung dieser Tools nie wirklich komplett vernünftig fertig
geworden. Das berührt dich aber für den Dragon sowieso nicht. ;-)
Jörg W. schrieb:> Ansonsten debuggen wir auch häufig genug mit dem Logic Analyzer, da kann> man einfach mit ein paar GPIOs bestimmte interne Zustände verfolgen> lassen und so trotzdem noch alles in Echtzeit tuckern lassen.
Oh noch einer mit dieser Idee. Ich hab das mit dem PCI-Bus Analyzer
gemacht, einfach auf Read only Register Werte geschrieben :) Die
Kollegen haben mich vorher für verrückt erklärt bis die dann sahen wie
gut das geht. Ist super für Echtzeit. :)
Jörg W. schrieb:> Das war eine grundlegend andere Herangehensweise als GDB, was dazu> führt, dass GDB unverhältnismäßig viele low-level-Aktionen auf den ICEs> angeworfen hat, die aber wiederum wegen der Arbeitsweise von Atmel> Studio im ICE relativ schwerfällig abgearbeitet worden sind.
Ja, so ungefähr hat sich das angefühlt.
Sehr träge und nach kurzer Zeit ging die Verbindung zum Target verloren
und mein PC in die Knie ;-)
Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig
zu debuggen?
Le X. schrieb:> Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig> zu debuggen?
Du könntest dir mal den SVN-Stand von AVaRICE mit einem aktuellen
Debug-Tool (Atmel-ICE, EDBG *) ansehen. Ich bin mit der Stabilität nicht
wirklich zufrieden, allerdings wäre das nur mit einem Rundumschlag zu
korrigieren, zu dem ich keine Energie habe. (OpenOCD kann mit den
Dingern praktikabel umgehen, es geht also, wenn man es ordentlich
aufzieht.)
*) EDBG ist der eingebaute Debugger, der auf vielen Xplained-Boards zu
finden ist. Den kann man auch abtrennen, ist dann eine deutlich
preiswertere Variante als das Atmel-ICE. Das Atmel-ICE gibt's auch als
reines PCB, das war mal in der gleichen Preisklasse wie der Dragon,
inzwischen hat Microchip das aber alles massiv verteuert.
>Gibt es denn momentan ne Möglichkeit die ATmegas unter Linux vernünftig zu
debuggen?
Kommt auf den Typ an. Wenn es gut läuft, hält der SNAP eine komplette
Debugsession unter MPLABX durch. Manche AVR werden erst unter dem PK4
einigermaßen zugänglich.
>Arbeitet von euch noch jemand mit dem vi?
Unter SSH mein std editor. Natürlich vim bevorzugt, aber hat ja nicht
jedes altbackene Linux.
Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen
könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken
hätten, und manche gar animierte Menüs, hat mal jemand ein Video
gemacht, das ich recht nett fand:
https://www.youtube.com/watch?v=84qoMxS-iqQ
Jack V. schrieb:> Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen> könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken> hätten, und manche gar animierte Menüs,
Es gibt doch auch joe, ohne bunte Schaltflächen. Der funktioniert auch
in der Console, ist aber bedienbar.
Joe schrieb:> Es gibt doch auch joe, ohne bunte Schaltflächen. Der funktioniert auch> in der Console, ist aber bedienbar.
Mag sein, es geht im Grunde aber nicht um bunt oder nicht bunt, und auch
nicht um GUI vs. CLI/TUI. Es geht auch nicht darum, dass Vim per se
überlegen wäre, und am besten jeder Vim lernen müsse. Einfach mal das
Video schauen, falls gerade sieben Minuten Lebenszeit übrig sind.
Jack V. schrieb:> https://www.youtube.com/watch?v=84qoMxS-iqQ
Sehr gutes Video, vielen Danlk für den Link. Entscheidend für die
Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von
Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und
die "Expressiveness". Die Diskussionen zu "Software1 vs Software2"
verlaufen oft nur deswegen (unnötigerweise) so hitzig, weil die
Diskutanten die beiden Größen individuell sehr unterschiedlich
gewichten. So kann ein Gelegenheitsnutzer einer Software, der naturgemäß
ein hohes Gewicht auf die Discoverability legt, nur schwer
nachvollziehen, dass für einen Vielnutzer die Expressiveness viel
wichtiger ist, und umgekehrt.
Yalu X. schrieb:> Entscheidend für die> Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von> Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und> die "Expressiveness"
Das mag schon so sein. Ich verstehe allerdings kein Wort. Oder muss das
so sein, wenn man von vi spricht? Oder fühlen sich manche Leute besser,
wenn sie sich unverständlich ausdrücken? Hatte zwar Englisch als
Prüfungsfach im Abi, aber das geht mir wirklich etwas zu weit. Man
sollte einen Text im Forum schon so schreiben, dass er von vielen
verstanden wird.
Karl schrieb:> Yalu X. schrieb:>> Entscheidend für die>> Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von>> Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und>> die "Expressiveness">> Das mag schon so sein. Ich verstehe allerdings kein Wort.
Das Video nicht geschaut? Das erklärt doch gerade, was diese Wörter
bedeuten.
Andi schrieb:> Das ist natürlich richtig.> Allerdings sind einige der Tasten wie "<>~' am US-Layout einfach> effizienter zu erreichen.
Also <> und ~ sind auf einer deutschen Tastatur sehr bequem zu
erreichen.
Ringfinger auf Shift + Mittelfinger auf > direkt daneben. Das ist jetzt
nicht wirklich schwer.
Ein richtiges Gewürge wird es erst bei {} und [], da muss man sich dann
schon richtig verrenken. Je weiter Links das Zeichen auf der Tastatur
ist, desto schlimmer.
\ geht noch.
} ist noch hinnehmbar.
Aber alles was weiter links liegt, da verrenkt man sich die Hand.
> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit> deutschem Layout programmieren kann.
Geht schon. Ist aber in der Tat umständlich.
Jörg W. schrieb:> Andi schrieb:>> Ganz abgesehen davon: Ich habe nie wirklich verstanden wie man C mit>> deutschem Layout programmieren kann.>> Ich auch nicht. Seit ich eine deutsche Tastatur habe, habe ich daher ein> Keyboard-Mapping, bei dem die äöü-Tasten [\]/{|} geben und nur dann die> Umlaute, wenn man zugleich AltGr drückt (das passt gut mit dem rechten> Daumen zusammen).
Womit setzt du das Keypboard Mapping um?
Jack V. schrieb:> Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen> könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken> hätten, und manche gar animierte Menüs, hat mal jemand ein Video> gemacht, das ich recht nett fand:> https://www.youtube.com/watch?v=84qoMxS-iqQ
Das Video fängt schon mit einem Denkfehler an.
Discoverability und Expressiveness schließen sich nämlich nicht
gegenseitig aus. Im Video wird das aber behauptet.
Auch ist die Behauptung falsch, dass man Expressivness nicht richtig in
der GUI unterbringen könnte. Der Typ hat offenbar noch nie etwas von
Menüs gehört.
Es spricht zudem nichts dagegen, einen Editor mit einer einfachen
Programmiersprache für den Editor zu kombinieren und den Plugins dann
einen Button mit gegebenenfalls einem GUI Untermenü zu geben.
Die einfachste Form davon dürften wohl Makros sein und das ganz bereits
jeder halbwegs gescheite Editor.
Nano schrieb:> Jack V. schrieb:>> Zu der hier im Thread auftretenden Frage, warum man sowas wie Vim wollen>> könnte, wo doch andere Editoren so schöne Schaltflächen zum Klicken>> hätten, und manche gar animierte Menüs, hat mal jemand ein Video>> gemacht, das ich recht nett fand:>> https://www.youtube.com/watch?v=84qoMxS-iqQ>> Das Video fängt schon mit einem Denkfehler an.>> Discoverability und Expressiveness schließen sich nämlich nicht> gegenseitig aus. Im Video wird das aber behauptet.
Sie schließen einander nicht streng aus, aber eine Tendenz gibt es
durchaus. Man kann eben nicht beliebig viele Funktionen einbauen, ohne
dass es irgendwann schwierig wird, alle schnell zu erfassen.
> Auch ist die Behauptung falsch, dass man Expressivness nicht richtig in> der GUI unterbringen könnte.
Kann man, aber mit Einschränkungen.
> Der Typ hat offenbar noch nie etwas von Menüs gehört.
Wenn du jede Funktion, die vim kann, in Menüs oder womöglich gar
Toolbars stecken willst, wird das kein Mensch mehr überblicken können.
Mit fünnfach verschachtelten Untermenüs, von denen jedes die komplette
Höhe des Bildschirms braucht, ist das Ganze dann am Ende auch nicht mehr
sonderlich discoverable.
Nano schrieb:> Womit setzt du das Keypboard Mapping um?
xkb
Nano schrieb:> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen> Programmiersprache für den Editor zu kombinieren
elisp? :-))
Jörg W. schrieb:> Nano schrieb:>> Womit setzt du das Keypboard Mapping um?>> xkb
Danke. Könntest du deine xkb Datei hier mal reinstellen?
Ich würde sie gerne ausprobieren.
> Nano schrieb:>> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen>> Programmiersprache für den Editor zu kombinieren>> elisp? :-))
Ich bin zwar weder EMACS noch LISP Fan, aber ja, als Beispiel das es
geht, ist das auch erwähnenswert.
Nano schrieb:> Discoverability und Expressiveness schließen sich nämlich nicht> gegenseitig aus. Im Video wird das aber behauptet.
Hast du dasselbe Video angeschaut wie ich? Die Stelle, wo dies behauptet
wird, kann ich nämlich nicht finden.
Rolf hat die wesentlichen Aussagen des Videos IMHO gut zusammengefasst:
Rolf M. schrieb:> Sie schließen einander nicht streng aus, aber eine Tendenz gibt es> durchaus.> ...Nano schrieb:> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen> Programmiersprache für den Editor zu kombinieren
Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche
Programmierprachen mit :)
Nano schrieb:>> xkb>> Danke. Könntest du deine xkb Datei hier mal reinstellen?> Ich würde sie gerne ausprobieren.
Bitte.
Ich gehe dabei aber üblicherweise so vor, dass ich mir die existierende
Belegung dumpen lasse und diese dann editiere.
Yalu X. schrieb:> Nano schrieb:>> Discoverability und Expressiveness schließen sich nämlich nicht>> gegenseitig aus. Im Video wird das aber behauptet.>> Hast du dasselbe Video angeschaut wie ich? Die Stelle, wo dies behauptet> wird, kann ich nämlich nicht finden.
Guck dir doch die grafische Darstellung an, wo das Gegensätzlich
angezeigt wird, links das eine, rechts das andere.
Als ob man sich für eine der Seiten entscheiden müsste, man aber nicht
beides haben könne. Und letzteres wird auch gesagt, guck es nochmal an.
> Nano schrieb:>> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen>> Programmiersprache für den Editor zu kombinieren>> Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche> Programmierprachen mit :)
Der Punkt ist, man kann auch eine schöne GUI mit intuitiven Menüs und
trotzdem eine Programmiersprache haben.
Und nein, warum vi nichts für mich ist, habe ich bereits eine Seite
vorher erklärt.
Die Programmiermöglichkeit allein ersetzt nämlich nicht die miserable
GUI.
Beim Debugger geht's schon los. Jede IDE ist da besser.
Und für stinknormale Configfiles brauche ich die Features eines vi
nicht, da reicht nano.
Rolf M. schrieb:> Karl schrieb:>> Yalu X. schrieb:>>> Entscheidend für die>>> Akzeptanz von Bedienkonzepten von Anwendungssoftware (nicht nur von>>> Editoren) sind im Wesentlichen die beiden Größen "Discoverability" und>>> die "Expressiveness">>>> Das mag schon so sein. Ich verstehe allerdings kein Wort.>> Das Video nicht geschaut? Das erklärt doch gerade, was diese Wörter> bedeuten.
Geschaut schon. Verstanden, nein. Mir ist es aber auch nicht so wichtig,
jetzt massiv Zeit in die Übersetzung zu stecken.
Nano schrieb:> Guck dir doch die grafische Darstellung an, wo das Gegensätzlich> angezeigt wird, links das eine, rechts das andere.
Diese Darstellung (die beiden Begriffe verbunden mit einer Linie) und
den Text dazu ("fundamentally user interfaces can be placed on a
spectrum of sorts") habe ich so verstanden, dass es zwischen dem linken
und dem rechten Ende beliebig viele Zwischenstufen gibt, also
vergleichbar mit einer Schwarz-Weiß-Skala, die nicht nur die beiden
Extremwerte, sondern auch alle Zwischenwerte (Graustufen) enthält.
Nano schrieb:> Der Punkt ist, man kann auch eine schöne GUI mit intuitiven Menüs und> trotzdem eine Programmiersprache haben.
Empfindest du die Menüs von gvim als unintuitiv? Ich würde sagen,
intuitiv und "discoverable" sind sie schon, nur halt sehr unvollständig
(also wenig "expressive"), weswegen sie kaum ein Vim-User benutzt.
vi(m) ist heute doch wirklich obsolet. Nutzen nur noch ein paar ergraute
Nerds, die früher nichts anderes hatten.
Um nicht missverstanden zu werden. Gute Editoren auf der Shell sind
unverzichtbar. Nicht nur wenn man mit SSH arbeitet. Aber nano ist viel
einfacher und mittlerweile gibt es selbst für Programmierer auf der
Shell moderne Alternativen wie den NiceEditor. Und warum nutzt man
heutzutage keine Curortasten und muss erst in verschiedene Modi
umschalten um navigieren zu können? Und selbst die Möglichkeiten mit
grafischen Editoren Dateien remote zu bearbeiten sind heute gegeben.
Ich habe auch schon in den 80ern mit dem Programmieren begonnen. Bin
aber mit der Zeit gegangen und nicht bei vi hängen geblieben.
Nano schrieb:> Der Typ hat offenbar noch nie etwas von> Menüs gehört.
Hattest du das Video wirklich geschaut? Bei etwa 2m55s wird das Problem
damit anschaulich dargestellt.
Das größere Problem ist, dass Jobs, die im Vim mit drei, vier
Tastendrücken erledigt sind, sich nicht mal sinnvoll in Menüs abbilden
lassen. So simple Sachen, wie beispielsweise „lösch doch bitte alle
Buchstaben zwischen den aktuellen Quotes“, oder auch „lösch doch bitte
alles bis zum nächsten Auftreten von Zeichen x“ oder auch „ersetze doch
bitte alle x in der aktuellen Zeile durch y“, und so weiter.
Das noch viel größere Problem ist, dass jemand, der nahezu
ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei
Strg-Tastenkombis nutzt, keine Vorstellung davon hat, wie’s ist, gar
nicht drüber nachzudenken, wie etwas zu machen ist, sondern das
einfach macht. Ist, wie das Zehnfingerschreiben: so, wie ich nicht
drüber nachdenke, welche Tasten ich drücken muss, damit ein bestimmtes
Wort auf dem Bildschirm erscheint, muss ich bei einem Editor, mit dem
ich mich auskenne, nicht drüber nachdenken, welche Tasten ich drücken
muss, damit eine bestimmte Aktion ausgeführt wird. Und dass jeder Griff
zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich
und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden,
der’s halt nicht kennt, auch nicht mental zu erfassen.
Insofern bringt’s eigentlich auch nichts, da weiter Zeit zu versenken.
Wen’s interessiert, warum manche Menschen solche Programme mögen, der
findet im verlinkten Video eine mögliche Erklärung. Für den habe ich das
verlinkt. Wer hingegen drauf aus ist, alle, die Sachen anders als sie
selbst machen, als doof hinzustellen, der wird sich einzelne Ausdrücke
aus dem Video herauspicken und solange darauf rumreiten, bis er sich
überlegen fühlt. War schon immer so, wird immer so sein – so what?
member of the big Johnson community schrieb:> Ne vi diskussion - im Jahre 2022. Die 90er haben gerade angerufen.nerd schrieb:> vi(m) ist heute doch wirklich obsolet. Nutzen nur noch ein paar> ergraute Nerds, …
Tja, bei euren hochgradig cleveren Kommentaren drängt sich dem
Beobachter sofort der Verdacht eines kreisförmigen Familienstammbaums
auf.
Jörg W. schrieb:> Nano schrieb:>>>> xkb>>>> Danke. Könntest du deine xkb Datei hier mal reinstellen?>> Ich würde sie gerne ausprobieren.>> Bitte.>> Ich gehe dabei aber üblicherweise so vor, dass ich mir die existierende> Belegung dumpen lasse und diese dann editiere.
Danke.
Bisher habe ich eine x Keymap nicht bearbeitet.
Yalu X. schrieb:> Nano schrieb:>> Es spricht zudem nichts dagegen, einen Editor mit einer einfachen>> Programmiersprache für den Editor zu kombinieren>> Dann ist ja Vim genau richtig für dich, der bringt gleich drei solche> Programmierprachen mit :)
Aus dem Kontext und meinen vorherigen Kommentaren weißt du ab er, das
Vim viel fehlt und es viel zu kritisieren gibt.
Also nein, er ist nicht die Lösung.
Jack V. schrieb:> Das größere Problem ist, dass Jobs, die im Vim mit drei, vier> Tastendrücken erledigt sind, sich nicht mal sinnvoll in Menüs abbilden> lassen. So simple Sachen, wie beispielsweise „lösch doch bitte alle> Buchstaben zwischen den aktuellen Quotes“, oder auch „lösch doch bitte> alles bis zum nächsten Auftreten von Zeichen x“ oder auch „ersetze doch> bitte alle x in der aktuellen Zeile durch y“, und so weiter.
Es gibt zu Menüs auch Shortcuts.
Beispielstring:
1
string str = "Das ist ein Text.";
In Nano:
Cursor in Zeile platzieren.
ALT + G
STRG + T
" eingeben + Enter drücken
1 cursor nach rechts
ALT + A = Markerung gesetzt
ALT + G
STRG + T
" eingeben + Enter drücken
STRK + K
Fertig.
Und wenn du es schneller willst, erstellt du halt ein Makro.
Und wenn du das hier willst:
> "„lösch doch bitte> alles bis zum nächsten Auftreten von Zeichen x“
dann ersetzt du das zweite " durch ein x.
> "„ersetze doch> bitte alle x in der aktuellen Zeile durch y“,
Und so etwas kann so gut wie jeder Editor mit einer Suchen und Ersetzen
Funktion.
In der Regel genügt es, den Cursor in die gewünschte Zeile zu bringen
und
dann die S&E Funktion zu starten. Die meisten Editoren beginnen dann
genau in der Zeile. Trivial.
> Das noch viel größere Problem ist, dass jemand, der nahezu> ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei> Strg-Tastenkombis nutzt, keine Vorstellung davon hat, wie’s ist, gar> nicht drüber nachzudenken, wie etwas zu machen ist, sondern das> einfach macht.
Blödsinn.
Die Menüs nutzt man für selten benötigte Funktionen, die sich dann
allein dadurch, dass man sieht, was in den Menüs verfügbar ist,
erschließen.
Für Dinge, die man öfters nutzt, lernt man die Shortcuts, also
Tastaturkürzel oder legt sich Makros an.
Beim Vim müsstest du jetzt bei Ersterem ewig im Handbuch oder deinen
Notizen, falls du welche erstellt hast, suchen um nochmal zu sehen, wie
es ging
und eine gescheite Debugger Ansicht (siehe 1. Seite) hat Vim damit immer
noch nicht.
Vim ist nämlich halt keine IDE und das ist das, was ich brauche, wenn
ich mehr machen will, als nur simple Configs editieren möchte.
Und für die Configs reicht mir nano, der in seinen Editiermöglichkeiten
Ausdrucksstark genug ist, siehe oben.
> Ist, wie das Zehnfingerschreiben:
Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine
10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem
nach Lehrbuch, sondern macht sich was eigenes.
> so, wie ich nicht> drüber nachdenke, welche Tasten ich drücken muss, damit ein bestimmtes> Wort auf dem Bildschirm erscheint,
Das muss ich auch nicht und ich nutze das 10 Fingersystem nicht, sondern
nur meine 10 Finger.
Und ja, ich kann das auch im Dunkeln.
> muss ich bei einem Editor, mit dem> ich mich auskenne, nicht drüber nachdenken, welche Tasten ich drücken> muss, damit eine bestimmte Aktion ausgeführt wird.
Natürlich musst du das, gerade bei seltener benutzen Funktionen, die du
ganz selten brauchst musst du das. Und das müsstest du auch in einer
Shell, wenn wir jetzt mal die Analogie der CLI dazu nehmen.
Und ab hier gewinnt dann der Editor mit intuitivem Menü.
> Und dass jeder Griff> zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich> und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden,> der’s halt nicht kennt, auch nicht mental zu erfassen.
Du verschwendest deine Zeit zum Suchen selten benutzter Funktionen und
einer unzureichenden Debugger Ansicht. Da gewinnt jede IDE.
Zumal man beim Programmieren mehr Zeit zum Nachdenken verbringt, als zum
Tippen. Daher würde auch ein Wechsel zur Maus nicht viel ausmachen.
Zumal der ab und zu Wechsel zur Maus gesund ist. Es ist nämlich
ungesund, immer in der gleichen Position zu verharren. Übrigens auch der
Grund, warum das 10 Fingersystem überholt ist.
> Wer hingegen drauf aus ist, alle, die Sachen anders als sie> selbst machen, als doof hinzustellen, ...
Du sprichst von dir selbst, deine Wortwahl:
1.
> dass jemand, der nahezu> ausschließlich an den Menüs hängt, und allenfalls mal noch ein, zwei> Strg-Tastenkombis nutzt, keine Vorstellung davon hat,
2.
> Und dass jeder Griff> zur Maus für jemanden, der mit der Tastatur umgehen kann, umständlich> und ein Zeit-/Konzentrationsverlust ist, ist vermutlich für jemanden,> der’s halt nicht kennt, auch nicht mental zu erfassen.
Ich will deinen Text nun nicht in Gänze zerlegen: Dass Vim nix für dich
ist, hast du ja nun zur Genüge dargelegt, und ich habe auch überhaupt
kein Problem damit – insbesondere käme mir nicht mal die Idee, dir die
überhaupt die weitere Beschäftigung mit dem Programm nahelegen zu
wollen.
Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es
niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst,
es schlechtzumachen; deswegen gehe ich mal auf ein Beispiel ein:
Nano schrieb:> Beispielstring:string str = "Das ist ein Text.";>> In Nano:> Cursor in Zeile platzieren.> ALT + G> STRG + T> " eingeben + Enter drücken> 1 cursor nach rechts> ALT + A = Markerung gesetzt> ALT + G> STRG + T> " eingeben + Enter drücken> STRK + K>> Fertig.
Beim Vim:
Cursor in der Zeile irgendwo vor oder innerhalb der Quotes positionieren
di" [Enter]
Fertig.
Vergleiche halt selbst, ob du tatsächlich das gezeigt hast, was du
gezeigt haben wolltest – möglicherweise ist das nicht ganz gelungen.
Selbst, wenn du alles mit Makros nachstellen könntest (was ich
bezweifele, denn es fehlen die dazu notwendigen Modi): warum, um Bobs
Willen, sollte man sich dann ein Jahr lang hinsetzen und einen anderen
Editor anpassen, statt einfach Vim zu nehmen?
Nano schrieb:> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem> nach Lehrbuch, sondern macht sich was eigenes.
Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du
meinst das Layout – QWERTZ ist in der Tat nicht optimal. Ich nutze daher
Neo2 – was übrigens ziemlich gut mit Vim harmoniert.
Aber das war gar nicht der Punkt – ich ich hoffe wirklich sehr, dass du
das selbst weißt. Der Punkt war, dass man nach einiger Zeit nicht drüber
nachdenken muss, wie man zu dem gewünschten Ergebnis kommt, sondern es
reicht, das gewünschte Ergebnis vor Augen zu haben. Was übrigens auch
ein Grund sein mag, warum Nichtzehnfingerschreiber das nicht erfassen
können: die Tastenfolgen (Obacht: keine Tastenkombinationen) sind
letztlich kurze Wörter, die übrigens sogar einem leicht merkbaren Schema
folgen, so dass man sich eben nicht hinsetzen und auswendig lernen muss.
Und es ist keine Abwertung, wie du hier reindichten zu wollen scheinst,
sondern eine Feststellung.
Auch in den anderen Punkten zeigst du zeigst du gerade anschaulich, was
ich hier mit Worten zu sagen versuchte:
Jack V. schrieb:> Wer hingegen drauf aus ist, alle, die Sachen anders als sie> selbst machen, als doof hinzustellen, der wird sich einzelne Ausdrücke> aus dem Video herauspicken und solange darauf rumreiten, bis er sich> überlegen fühlt.
Was ist eigentlich dein Problem damit, dass Leute mit dem Vim ziemlich
gut klarkommen und ihn gar mögen? Trauma vom ersten Start vom Vim, als
du gefangen warst und nicht wieder rausgefunden hattest? Ging eigentlich
jedem so, den ich kenne und der mit Vim in Berührung gekommen ist – aber
so eine Auswirkung, wie hier zu beobachten, hat’s bei keinem gehabt.
Jack V. schrieb:> Trauma vom ersten Start vom Vim, als du gefangen warst und nicht wieder> rausgefunden hattest?
Manche benutzen ihn seit 30 Jahren weil sie bisher nicht rausgekommen
sind. Andere kennen kill -9
Walter K. schrieb:> Grundkenntnisse des vi oder dessen forkes gehören zu den Basics> für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht!
Seh ich auch so.
Zumindest wie man rauskommt sollte man wissen.
Le X. schrieb:> Walter K. schrieb:>> Grundkenntnisse des vi oder dessen forkes gehören zu den Basics>> für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht!>> Seh ich auch so.> Zumindest wie man rauskommt sollte man wissen.
Na wie man's bei Windows gelernt hat:
Alt-Ctrl-Del, warten bis der Bildschirm dunkel wird(**), warten bis der
Bildschirm hell wird, fertig.
(**) Für die schweren Fälle gibt's auch noch:
›Have you tried turning it off and on again?‹
Le X. schrieb:> Zumindest wie man rauskommt sollte man wissen.
Stimmt, und das ist auch das Einzige, was ich kann :-)
Ansonsten verwende ich den Nano in den seltenen Fällen, wenn ich auf
einer reinen Textshell arbeite. Der ist dem alten WordStar nachempfunden
(kennt den noch jemand? 80er Jahre? CP/M? Z80-Dampfmaschinen mit
ASCII-Terminals? Grüne BAS-Monitore? Ach war dat schön damals...) Damit
habe ich meine ersten Assembler- und Pascal-Sourcecodes geschrieben und
bin daher mit Nano sofort klargekommen, obwohl zwischen CP/M und Linux
das beinahe 15 Jahre andauernde dunkle DOS/Windows-Zeitalter lag.
vi, emacs ist doch in Wahrheit eine medizinische Anwendung. Die endlosen
Tastaturkürzel dort dienen wunderbar als Übungen für Gelenkartrose und
Gicht.
Fitnessprogramm für die Gichtkrallen.
Leute die sowas nutzen, können keine Maus bedienen, damit rosten die
Fingergelenke ein und schmerzen, mit vi+emacs sind die Gelenke immer in
Bewegung und beugen weiteren Entzündungen vor.
nerd schrieb:> Nutzen nur noch ein paar ergraute Nerds, die früher nichts anderes hatten.member of the big Johnson community schrieb:> Leute die sowas nutzen, können keine Maus bedienen
Warum muss eigentlich immer gleich gegen die Nutzer der Software
gegiftet werden? Ich könnt auch sagen: "Leute, die Klickibunti-Editoren
benutzen, sind zu blöd, sich Tastenkürzel zu merken oder ins Handbuch zu
schauen". Das sage ich nur nicht (hier steht's nur zu demonstrativen
Zwecken), weil ich verstehe, dass es Leute gibt, die das bevorzugen, und
weil es mich überhaupt nicht stören sollte, wenn andere keinen vim
benutzen.
member of the big Johnson community schrieb:> können keine Maus bedienen, damit rosten die> Fingergelenke ein und schmerzen,
Bei der Mausbedienung hingegen werden die Fingergelenke ständig
trainiert, besonders bei den heute üblichen beidhändigen
Zehntastenmäusen mit Bildschirmtastatur.
Rolf M. schrieb:> Warum muss eigentlich immer gleich gegen die Nutzer der Software> gegiftet werden?
Weil man seine eigene Entscheidung gegen sich selbst verteidigen muss?
Das geht am einfachsten, indem man alle anderen für doof und unfähig
erklärt.
Nano schrieb:> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem> nach Lehrbuch, sondern macht sich was eigenes.
Wichtig ist, blind schreiben zu können. Kannst Du das?
Jack V. schrieb:> Nano schrieb:>> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine>> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem>> nach Lehrbuch, sondern macht sich was eigenes.>> Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du> meinst das Layout – QWERTZ ist in der Tat nicht optimal.
IMHO meint er damit sein individuelles Zehnfingersystem auf einem
normalen Tastaturlayout.
Das Lehrbuchzehnfingersystem ordnet jeder Taste einen bestimmten Finger
zu, die Hände bleiben dabei immer mehr oder weniger an derselben
Position. Das ist ein recht starres, speziell auf das Tippen von
Fließtext auf einer Schreibmaschine optimiertes Konzept.
Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur
eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten
usw.) aus der fixen Handposition heraus gar nicht erreichbar sind. Wenn
man aber die Hände sowieso bewegen muss, kann man auch gleich die feste
Zuordnung von Fingern zu Tasten aufheben. Stattdessen wird eine Taste
immer von demjenigen Finger betätigt, der sich gerade in der jeweils
günstigsten Position befindet, so wie es auch ein Klavierspieler tut.
Durch die Einbeziehung von Armbewegungen in die Tipparbeit verlieren
auch die auf dem deutschen Tastaturlayout erforderlichen "krummen"
Tastenkombinationen für einige Sonderzeichen (bspw. AltGr+{) viel von
ihrem Schrecken.
Auch ich nutze ganz intuitiv dieses "dynamische" Zehnfingersystem, muss
allerdings gestehen, dass ich das klassische Zehnfingersystem trotz
einiger Anläufe nie richtig gelernt und somit keinen direkten Vergleich
habe.
Jack V. schrieb:> Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es> niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst,> es schlechtzumachen;
Das machst du, siehe oben, da habe ich das belegt.
Ich habe lediglich meine Meinung dazu gesagt und jetzt hast du ein
Problem damit, sie zu akzeptieren, auch wenn du in deinem Eingangssatz
gegenteiliges behauptest, so sieht man es hier.
> deswegen gehe ich mal auf ein Beispiel ein:>> Nano schrieb:>> Beispielstring:string str = "Das ist ein Text.";>>>> In Nano:>> Cursor in Zeile platzieren.>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> 1 cursor nach rechts>> ALT + A = Markerung gesetzt>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> STRK + K>>>> Fertig.>> Beim Vim:> Cursor in der Zeile irgendwo vor oder innerhalb der Quotes positionieren> di" [Enter]>> Fertig.
Mit anderen Worten, du kannst und willst nicht akzeptieren, dass andere
Editoren das auch können.
Das ist dein Problem, arbeite mal an dir!
Und ich sagte dir bereits, dass nano Makros beherrscht, falls dir
bekannt sein sollte, was das ist. Die kann man anlegen, dann ist das ein
Tastendruck.
Übrigens und das ist auch so ein Punkt, der dir hier nicht auffällt.
Nano zeigt Kontextabhängig die Tastaturkommandos in der unteren Leiste
an.
Deswegen lässt sich obiges bei Nano auch ganz leicht intuitiv
erschließen.
Die angezeigten Tastaturkommandos sind somit praktisch bereits ein Menü.
Du musst da also nicht di auswendig lernen.
Mal abgesehen davon, das dein Befehl nicht das tut, was du hier
behauptest.
Selbst wenn ich ein : davor setze, macht er nicht das, was du
behauptest.
Da kommt dann:
[code]
System str = "Dies ist ein Text.\n";
~
~
~
:di
Type Name Content
c ": id
c "% test.txt
Press ENTER or type command to continue
[/quote]
Und wenn man ENTER drückt, passiert gar nichts.
Wenn ich das : weglasse und nur den Cursor in den String zwischen den "
plaziere und dann di eingebe, dann passiert erst mal gar nichts und wenn
man es dann gleich nochmal schreibt, wird "di" in den StrinG
eingetragen.
Was wohl daran liegt, so weit ich mich an Vim noch erinnern kann, dass
das erste i als Insert Kommando verstanden wird.
Wie dem auch sein, so wie du deine Anweisung beschreibst funktioniert es
nicht.
Getestet mit VIM - Vi IMproved 8.2 auf dem Raspberry Pi.
> Vergleiche halt selbst, ob du tatsächlich das gezeigt hast, was du> gezeigt haben wolltest – möglicherweise ist das nicht ganz gelungen.
Keine Ahnung was du jetzt wieder sagen willst, die nano Anweisung tut
was sie soll und nano kann das. Du wurdest also wiederlegt, finde dich
damit ab.
> Selbst, wenn du alles mit Makros nachstellen könntest (was ich> bezweifele, denn es fehlen die dazu notwendigen Modi): warum, um Bobs> Willen, sollte man sich dann ein Jahr lang hinsetzen und einen anderen> Editor anpassen, statt einfach Vim zu nehmen?
Warum ich vim nicht als IDE Ersatz nehme, habe ich dir ja jetzt zur
Genüge erklärt. Lies dazu vor allem auch mal meine alten Kommentare eine
Seite vorher. Warum ist es so schwer für dich zu akzeptieren, dass nicht
jeder das nehmen will, was du nimmst?
> Nano schrieb:>> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine>> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem>> nach Lehrbuch, sondern macht sich was eigenes.>> Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt.
NEIN! Das Zehnfingersystem ist ein Eigenname und es ist ein System,
das damit anfängt, dass man, ich glaube es war der Zeigefinger, die
Hände in einer Grundhaltung so auf die Tastatur legt, dass der linke
Zeigefinger (bei einem deutschen oder US Layout) auf dem F liegt und der
rechte auf dem J.
Diese beiden Tasten haben nämlich, wenn du mal auf deine Tastatur
guckst, auf den meisten Tastaturen dafür eine kleine Erhebung auf diesen
beiden Taste, so dass sie sich vom Rest der anderen Tasten abheben und
blind ertasten lasen.
Diese sind für das Zehnfingersystem da.
Die anderen drei Finger werden dann entsprechend links bzw. rechts davon
dann auf die Tasten A, S, D und K, L, Ö platziert und wenn man dann die
beiden Hände so über der Tastatur hält, dann ist das die Grundhaltung
des 10 Fingersystems.
Ziel des ganzen ist nun, von dieser Grundposition alle anderen Tasten
schnell und effizient zu erreichen.
Und falls du dich fragst, warum diese ASDF und JKLÖ Tasten keine
Buchstaben sind, die extrem häufig benöntigt werden, dann liegt das
daran, dass die klassischen Schreibmaschinenlayout deswegen kein Dvorak
Tastaturlayout ist, weil die Schreibmaschinen kleine Hammer hatten, die
beim Drück der Taste auf das Papier geschleudert wurden und somit einen
Hin- und Rückweg hatten und die sich beim Schreiben möglichst nicht mit
anderen Tastenhammern verharken sollten.
Mit den Computern fiel dieses Problem weg, aber Mio Schreibkräfte waren
bereits an die Schreibmaschine gewöhnt, so dass man das Layout
beibehielt.
> Du> meinst das Layout – QWERTZ ist in der Tat nicht optimal.
Nein, lerne was DAS ZehnfingerSYSTEM ist.
Das kommt schon vom Namen SYSTEM her.
Da geht es nicht einfach nur darum, dass man 10 Finger benutzt, sondern
dass man die 10 Finger auf eine ganz bestimmte Weise verwendet.
Und dieses System wurde viele Jahre lang in den Schreibmaschinenkursen,
die es früher noch gab, beigebracht.
> Was ist eigentlich dein Problem damit, dass Leute mit dem Vim ziemlich> gut klarkommen und ihn gar mögen?
Was kapierst du eigentlich nicht?
Deine Erwartungshaltung ist:
"Wer mit Vim einmal beginnt, der wird es als einzige Wahre Braut ansehen
und noch noch damit schreiben."
Und wenn deine Erwartungshaltung dann nicht erfüllt wird, dann lautet
dein Motto:
"Gegen jeden, der es wagt vim zu kritisieren und nicht als Editor zu
nutzen, gegen den ziehe ich in den Krieg."
Das ist deine Einstellung, die du hier an den Tag legst und dann fragst
du mich ernsthaft so einen Blödsinn wie oben?
Warum ich Vim nicht nutze, das habe ich oben bereits argumentativ und
objektiv erklärt, lerne mal damit umzugehen. Ist ja schlimm so ein
Verhalten.
Und hier sieht man dann auch, dass du jeden persönlich angreifst, der
vim nicht nutzen will:
Jack V. schrieb:> Trauma vom ersten Start vom Vim, als> du gefangen warst und nicht wieder rausgefunden hattest?
Man wird also, wenn man dir nicht folgt und auch vim nutzt, von dir
persönlich angegriffen und bekommt von dir dann vorgeworfen:
1. ein Trauma zu haben.
2. gefangen zu sein.
Und aus deinen vorherigen Postings:
3. keine Vorstellung zu haben.
4. und mental nicht in der Lage zu sein, es zu erfassen.
Fazit:
Komm mal mit dir klar Junge!
Norbert schrieb:> Le X. schrieb:>> Walter K. schrieb:>>> Grundkenntnisse des vi oder dessen forkes gehören zu den Basics>>> für jeden, dessen Horizont über die Windows-Power-User-Welt hinausgeht!>>>> Seh ich auch so.>> Zumindest wie man rauskommt sollte man wissen.>> Na wie man's bei Windows gelernt hat:> Alt-Ctrl-Del, warten bis der Bildschirm dunkel wird(**), warten bis der> Bildschirm hell wird, fertig.
Dein letztes Windows hatte wohl noch einen DOS Kernel.
Unter einem Windows NT System landest du mit ALT+CTRL+DEL im
Loginbildschirm und kannst dich dann als Administrator anmelden.
Siehe hier:
https://www.youtube.com/watch?v=9pSIgX29dP4
Die Tastenkombination CTRL+ALT+DEL um den Rechner neu zu starten ist
übrigens eine BIOS Funktion und kommt daher vom BIOS und nicht von
Windows.
DOS nutzt noch die BIOS Funktionen, Windows NT aber nicht mehr.
Nano schrieb:> dass nano Makros beherrscht, falls dir bekannt sein sollte, was das ist.> Die kann man anlegen, dann ist das ein Tastendruck
Der Haken ist: die musst du eben auch erst anlegen.
Emacs hat auch welche, habe ich aber noch nie gebraucht.
Ich finde die diversen Modi bei vi auch ätzend, wirklich zeitgemäß waren
sie wohl schon zu Zeiten seiner Einführung nicht *), aber trotzdem kann
ich akzeptieren, dass es viele Leute gibt, die damit gut zurecht kommen
und würde diejenigen nicht als altmodisch betiteln.
*) Diskussionen dazu kann man im Netz genügen nachlesen, müssen wir hier
nicht wiederkäuen.
vancouver schrieb:> Le X. schrieb:>> Zumindest wie man rauskommt sollte man wissen.>> Stimmt, und das ist auch das Einzige, was ich kann :-)>> Ansonsten verwende ich den Nano in den seltenen Fällen, wenn ich auf> einer reinen Textshell arbeite. Der ist dem alten WordStar nachempfunden> (kennt den noch jemand? 80er Jahre? CP/M? Z80-Dampfmaschinen mit> ASCII-Terminals? Grüne BAS-Monitore? Ach war dat schön damals...) Damit> habe ich meine ersten Assembler- und Pascal-Sourcecodes geschrieben und> bin daher mit Nano sofort klargekommen, obwohl zwischen CP/M und Linux> das beinahe 15 Jahre andauernde dunkle DOS/Windows-Zeitalter lag.
Nano hat seinen Ursprung in Pico. Pico ist ein Editor mit E-Mailclient
aus dem Jahre 1989 und wurde früher bei einigen Linux Distributionen
mitgeliefert.
Pico gibt es sogar auch als DOS Version.
Weil es Unklarheiten bei der Lizenz gab, wurde irgendwann Nano gestartet
und der hat dann ab so ca. 2003 pico als Texteditor auf den
Linuxsystemen nach und nach ersetzt.
Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt.
https://en.wikipedia.org/wiki/Pico_(text_editor)
Touch Typist schrieb:> Nano schrieb:>> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine>> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem>> nach Lehrbuch, sondern macht sich was eigenes.>> Wichtig ist, blind schreiben zu können. Kannst Du das?
Dass ich das kann, habe ich oben bereits im gleichen Kommentar, das du
hier zitierst, geschrieben.
Siehe:
Nano schrieb:> Das muss ich auch nicht und ich nutze das 10 Fingersystem nicht, sondern> nur meine 10 Finger.> Und ja, ich kann das auch im Dunkeln.
Wichtig ist also auch, Texte komplett zu erfassen und Kommentare zu Ende
zu lesen. Kannst du das?
Nano schrieb:> Dein letztes Windows hatte wohl noch einen DOS Kernel.>> Unter einem Windows NT System landest du mit ALT+CTRL+DEL im> Loginbildschirm und kannst dich dann als Administrator anmelden.
Und den Taskmanager erreicht man damit nicht?
Und dort einen Neustart veranlassen kann man damit nicht?
Bemerkenswert!
Nano schrieb:> Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt.
WordStar war zu der Zeit ein ziemlicher de-facto-Standard, insofern ist
das nicht verwunderlich, dass diese Editoren daraus eine Reihe von
Kommandos übernommen haben.
Jörg W. schrieb:> Nano schrieb:>> dass nano Makros beherrscht, falls dir bekannt sein sollte, was das ist.>> Die kann man anlegen, dann ist das ein Tastendruck>> Der Haken ist: die musst du eben auch erst anlegen.
Ja, das ist richtig. Anlegen tut man so etwas aber nur, wenn es sich
wirklich lohnt und man die Funktion ohnehin öfters braucht.
Ich gehe meist anders vor und bin dann genauso schnell am Ziel.
Nach dem " drück ich die Entertaste, dann landet der String in der
nächsten Zeile. Dort mach ich ein CTRL+K und der String mitsamt "; ist
weg.
Dann nutze ich die Rücktaste, lande somit wieder in meiner vorherigen
Zeile und dann kann ich den neuen String eintragen und mit ";
abschließen.
Die RISC Technik funktioniert somit auch beim Menschen, da braucht man
nicht immer CISC.
CTRL+K und das Gegenstück CTRL+U gehören bei mir unter nano zu den
Häufigsten von mir benutzten Tastaturkürzel.
> Emacs hat auch welche, habe ich aber noch nie gebraucht.
Emacs habe ich nie benutzt.
Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI.
Und es ist auch, anders als vi, nie immer vorinstalliert, also habe ich
es nie benutzt.
> Ich finde die diversen Modi bei vi auch ätzend, wirklich zeitgemäß waren> sie wohl schon zu Zeiten seiner Einführung nicht *), aber trotzdem kann> ich akzeptieren, dass es viele Leute gibt, die damit gut zurecht kommen> und würde diejenigen nicht als altmodisch betiteln.
Habe ich auch nicht, das war jemand anderes.
Yalu X. schrieb:> Jack V. schrieb:>> Nano schrieb:>>> Das 10 Finger System ist ungesund und veraltet. Wichtig ist nur, seine>>> 10 Finger zu nutzen, dazu braucht man aber nicht das 10 Fingersystem>>> nach Lehrbuch, sondern macht sich was eigenes.>>>> Das Zehnfingersystem bedeutet, dass man alle zehn Finger nutzt. Du>> meinst das Layout – QWERTZ ist in der Tat nicht optimal.>> IMHO meint er damit sein individuelles Zehnfingersystem auf einem> normalen Tastaturlayout.>> Das Lehrbuchzehnfingersystem ordnet jeder Taste einen bestimmten Finger> zu, die Hände bleiben dabei immer mehr oder weniger an derselben> Position. Das ist ein recht starres, speziell auf das Tippen von> Fließtext auf einer Schreibmaschine optimiertes Konzept.>> ...>> Durch die Einbeziehung von Armbewegungen in die Tipparbeit verlieren> auch die auf dem deutschen Tastaturlayout erforderlichen "krummen"> Tastenkombinationen für einige Sonderzeichen (bspw. AltGr+{) viel von> ihrem Schrecken.
++
Genau so ist es.
Danke!
Nano schrieb:> Es kann sein, dass Pico sich an WordStar anlehnte, das weiß ich jetzt.
Ups, da fehlt ein "nicht" am Satzende.
Keine Ahnung wie das passieren konnte, vielleicht lag es auch am
Raspberry Pi 3, das Browsen ist mit dem leider ziemlich lahm und wenn er
beschäftigt ist, hängt er leider auch etwas beim Tippen.
Temp ist trotz nachträglich angebrachter Kühlkörper 62.3'C, da kann es
also auch sein, dass er runterdrosselt.
Nano schrieb:> Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI.
Letzteres kann nur jemand sagen, der damit noch nicht gearbeitet hat
:-), aber das gehört nicht in diesen Thread.
Nano schrieb:> Du musst da also nicht di auswendig lernen.> Mal abgesehen davon, das dein Befehl nicht das tut, was du hier> behauptest.
Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma)
eingeben.
Das 'd' steht für "delete" und das 'i' für "inner" und das '"' für
"quoted string". Der Befehl sucht, ausgehend von der aktuellen
Cursorposition nach links und rechts jeweils das nächste '"' und löscht
alles, was dazwischen liegt. Dabei werden ggf. escapete '"' bei der
Suche übersprungen. Beispiel:
1
person="Forenbenutzer \"Nano\"";
Nach der Eingabe von 'di"' steht da:
1
person="";
Statt 'i' kannst du auch 'a' nehmen (also 'da"'), dann werden auch die
Anführungszeichen und ggf. nachfolgender oder vorangehender Whitespace
gelöscht:
1
person=;
Möchtest du den Inhalt des Strings nicht löschen, sondern ändern, geht
das mit 'c' statt 'd' am Anfang, also mit 'ci"' ('c' = "change"). Damit
wird der Inhalt wie bei 'di"' gelöscht und in den Insert-Modus
umgeschaltet, so dass du den neuen Inhalt eingeben kannst. Mit 'y'
("yank") wird der Stringinhalt kopiert. Mit 'v' ("visual") wird er grau
markiert, so dass man vorab sehen kann, wie Vim den Befehl
interpretiert. Danach kann man bei Bedarf die Grenzen des markierten
Bereichs mit den Cursortasten verschieben und mit 'd', 'c' oder 'y' den
markierten Text löschen, ändern oder kopieren.
Statt des '"' am Ende des Befehls kann auch ein '(', '[', '{' oder '<'
verwendet werden, um den Inhalt eines Klammerpaars zu löschen, zu ändern
oder zu kopieren. Dabei werden Verschachtelungen korrekt berücksichtigt.
Hat man das Prinzip erst einmal verstanden, kann man einige wenige,
leicht zu merkende Kürzel in vielfältiger Weise kombinieren. Auch das
ist eine Form von Discoverability. Ich wüsste auch nicht, wie man so
etwas in sinnvoller Weise in Menüs packen könnte.
Jack V. schrieb:> „lösch doch bitte alle Buchstaben zwischen den aktuellen Quotes“> „lösch doch bitte alles bis zum nächsten Auftreten von Zeichen x“> „ersetze doch bitte alle x in der aktuellen Zeile durch y“, und> so weiter.
Du bist aber wirklich sehr höflich zu Deiner Software. Find' ich gut!
;-)
Jörg W. schrieb:> Nano schrieb:>> Als Editor war mir Emacs zu groß und als IDE ist es keine grafische UI.>> Letzteres kann nur jemand sagen, der damit noch nicht gearbeitet hat> :-), aber das gehört nicht in diesen Thread.
Eine TUI ist keine GUI.
Ich möchte bspw. als Fensterabgrenzung keine dicken Textblöcke wie "█",
"║", "▓" oder "│", sondern dünne < 2 Pixel Breite Linien und die Pixel
daneben sollten sich auch gleich direkt für etwas anderes nutzen lassen
können.
Das geht mit einer Textblöcke basierten TUI grundsätzlich nicht.
Ist so, da gibt es auch kein wenn und aber.
Yalu X. schrieb:> Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur> eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten> usw.) aus der fixen Handposition heraus gar nicht erreichbar sind.
Das ist mit einer der Gründe, aus denen ich Neo so mag: die meisten
Sachen sind ohne große Handbewegungen erreichbar. \/{}() sind gar auf
der Grundlinie, und selbst Cursor- und einige Funktionstasten, wie Home,
End, Backspace, Escape sind in der vierten Ebene auf dem
Haupttastenfeld. Gerade Escape ohne die Handhaltung zu ändern zu
erreichen, ist in Verbindung mit dem Vim sehr geschickt (um grad noch so
die Kurve zum Threadthema zu bekommen …) :)
Yalu X. schrieb:> Nano schrieb:>> Du musst da also nicht di auswendig lernen.>> Mal abgesehen davon, das dein Befehl nicht das tut, was du hier>> behauptest.>> Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma)> eingeben.
Und genau das habe ich gemacht und nichts passiert.
Nach deinem Kommentar habe ich sogar extra nochmal nachgeguckt, ob ich
wirklich im Normalmode bin:
https://linuxhint.com/vim_modes/
Und ja, bin ich, funktioniert aber nicht. Und ja, ich habe es auch ohne
Hochkomma eingegeben.
Entweder nutzt ihr also eine andere, neuere Version als ich, wie schon
gesagt, nutze ich hier vim von Rasbian oder eure Anleitung ist schlecht.
In jedem Fall zeigt es aber, das vim nicht intuitiv ist.
Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es
anzeigt, in welchem Mode es ist, ist auch schlecht.
Schon interessant, dass man Tastatukommandos, wie im Link beschrieben,
z.b. Taste k drücken muss, um auf andere Weise festzustellen, ob man
überhaupt im Normalmode ist.
Und k ist dann auch noch vom Artikelschreiber doof gewählt, denn der
Cursor landet für gewöhnlich, bei einer geöffneten Datei ohnehin ganz
oben.
> Das 'd' steht für "delete" und das 'i' für "inner" und das '"' für> "quoted string".
Das weiß ich, ich habe schon vor Jahren mit vim angesehen und Tutorials
durchgearbeitet. Spätestens bei der Debuggeransicht hat er dann
verloren.
> Der Befehl sucht, ausgehend von der aktuellen> Cursorposition nach links und rechts jeweils das nächste '"' und löscht> alles, was dazwischen liegt. Dabei werden ggf. escapete '"' bei der> Suche übersprungen. Beispiel:> person = "Forenbenutzer \"Nano\"";
Apropo Escape, nichtmal die Eingabe von di\" geht.
Was geht ist D, das löscht dann alles ab Cursor bis Zeilenende.
> Nach der Eingabe von 'di"' steht da:> person = "";
Nö.
> Statt 'i' kannst du auch 'a' nehmen (also 'da"'), dann werden auch die> Anführungszeichen und ggf. nachfolgender oder vorangehender Whitespace> gelöscht:> person =;
Nö.
Was geht ist yy um ein paar dieser String Zeilen zu kopieren und mit P
einzufügen.
Aber euer Befehl geht nicht, weder di" noch da".
> Möchtest du den Inhalt des Strings nicht löschen, sondern ändern, geht> das mit 'c' statt 'd' am Anfang, also mit 'ci"' ('c' = "change").
Geht auch nicht.
Vielleicht liegt es auch einfach daran:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 01 2021 01:51:08)
7
....
> Ich wüsste auch nicht, wie man so> etwas in sinnvoller Weise in Menüs packen könnte.
Das muss man nicht. Man kann trotzdem einen intuitiven GUI Editor mit
Menüs und gescheiter Debuggeransicht und Co haben und trotzdem eine
Befehlseingabe ermöglichen die genau das gleiche kann.
Wenn man das aber macht, dann macht man es richtig, mit der richtigen
visuellen Rückmeldung und nicht so ein Gewürge, wie bei vim.
Es gibt z.B. IDEs mit vi Eingabe, vi sind die dadurch trotzdem nicht.
Nano schrieb:> /usr/bin/vim.tiny
Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie
eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum?
Erstaunlich …
Nano schrieb:> Ich möchte bspw. als Fensterabgrenzung … dünne < 2 Pixel Breite Linien …
Da hast du dir ja eine Menge Spielraum gelassen.
Zwei ist zu viel und Null ist tendenziell eher schlecht zu erkennen… ;-)
Nano schrieb:> Yalu X. schrieb:>> Du musst im Normalmodus 'di"' (ohne die umschließenden Hochkomma)>> eingeben.> Und genau das habe ich gemacht und nichts passiert.
Hmmm,
vim 8.1.1401: geht, gvim geht auch.
@Yalu X
›di"‹ kannte ich noch nicht, ist aber extrem praktisch. Habe ich sofort
verinnerlicht. Danke!
Nano schrieb:> Eine TUI ist keine GUI.
Emacs GUI gibt's seit 30 Jahren.
Mag dir nicht zusagen, aber es ist trotzdem eine - den TUI-Modus benutze
ich höchstens via ssh, wenn mir die Verbindung zu lahm für die GUI ist.
Jack V. schrieb:> Nano schrieb:>> /usr/bin/vim.tiny>> Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie> eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum?> Erstaunlich …
Mit Recht, den eure Aussage ist ja:
"vim ist überall installiert."
Ist ja nicht mein Problem, dass vim unter Rasbian so ne Krücke ist.
Nano ist dort vollständig.
Und es stellt sich hier dann auch gleich noch die Frage, warum man unter
Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt.
Der Raspberry Pi 3 hat 1 GiB RAM, selbst mein Pentium 2 hatte nichtmal
1/4 davon, aber bei dem war Vim damals unter einem meiner ersten Linux
Distris, die ich benutzt habe, vollständig.
Da stellt sich also auch die Frage, ob die neuen Versionen von vim
bloatware sind.
Nano schrieb:> Jack V. schrieb:>> Nano schrieb:>>> /usr/bin/vim.tiny>>>> Du nutzt also eine eingeschränkte Version und wunderst dich, dass sie>> eingeschränkt ist? Und mehr noch: du rantest auf dieser Basis wild rum?>> Erstaunlich …
Ergänzung:
Zumal du mir hier ja Grundfeatures aufzeigen wolltest, die ein Editor
können soll.
Also bspw. einen String zwischen zwei " löschen.
Schon komisch, dass man dafür eine Bloatwareversion braucht.
Nano schrieb:> Mit Recht, den eure Aussage ist ja:> "vim ist überall installiert."
Zumindest meine war’s nicht. Auf meinen Systemen ist installiert, was
ich installiere.
Nano schrieb:> Und es stellt sich hier dann auch gleich noch die Frage, warum man unter> Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt.
Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der
Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama
– dauert keine Minute, bis man das behoben hat.
Nano schrieb:> Da stellt sich also auch die Frage, ob die neuen Versionen von vim> bloatware sind.
Wenn du 1,5MB mehr, für die du dann eben auch die entsprechende
Funktionalität hast, Bloat nennst – bitte. In meinem Sprachgebrauch
steht Bloat etwa für höheren Platzbedarf ohne entsprechende zusätzliche
Funktionalität – und das ist hier ganz offensichtlich nicht der Fall.
Jörg W. schrieb:> Nano schrieb:>> Eine TUI ist keine GUI.>> Emacs GUI gibt's seit 30 Jahren.
Als TUI ja, TUI = Text User Interface.
https://de.wikipedia.org/wiki/Zeichenorientierte_Benutzerschnittstelle
Und wenn eine GUI dabei ist, dann ist das nur, wie auch bei gvim, dran
geflanscht, während aber eigentliche Hauptarbeitsoberfläche, in dem Fall
dann bspw. verschiedene Fensteransichten dann immer noch als TUI
realisiert sind und darum geht es ja, das will ich nicht.
Eine moderne IDE hat das Problem nicht, die ist vollständig grafisch.
Norbert schrieb:> Nano schrieb:>> Schon komisch, dass man dafür eine Bloatwareversion braucht.>> Du merkst aber schon das es dir so langsam entgleist, oder?
Ist doch wahr, da will er mir ein paar Grundfeatures von vim zeigen und
dann kann das nicht einmal jede vim Installation.
Das wäre so, als wenn ich bei Kate alle Plugins dazu nehme.
Jack V. schrieb:> Nano schrieb:>> Und es stellt sich hier dann auch gleich noch die Frage, warum man unter>> Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt.>> Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der> Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama> – dauert keine Minute, bis man das behoben hat.
Ja, man kann die Vollversion aus dem Repo nachinstallieren, das ist war.
Vorinstalliert ist es in der Form nicht, nano ist es.
Interessanterweise gibt's auch ein nano-tiny im Repo, aber das ist nicht
vorinstalliert.
> Nano schrieb:>> Da stellt sich also auch die Frage, ob die neuen Versionen von vim>> bloatware sind.>> Wenn du 1,5MB mehr, für die du dann eben auch die entsprechende> Funktionalität hast, Bloat nennst – bitte.
Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine
tiny Version brauchen.
Vielleicht gibt's Leute, die Debian auf einem Pentium MMX mit 64 MiB RAM
installieren wollen, keine Ahnung, ausschließen möchte ich es nicht.
Nano schrieb:> Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine> tiny Version brauchen.
Warum sollte ich das klären? Du argumentierst doch auf der Basis einer
abgespeckten Version … ich weiß, was es damit auf sich hat, und ich
würde mir nicht die Blöße geben, wild rumzuranten und gar persönlich
beleidigend zu werden, weil ich nicht einmal erkenne, dass ich nicht die
Upstream-Version, sondern eine vom Distributor künstlich verkleinerte
Version nutze.
Abgesehen davon hab ich schon geschaut: es ist als Ersatz für ›vi‹
gedacht, der früher™ immer dabei war, aber nicht mehr weiterentwickelt
wird. Wie auch immer – wer Vim möchte, wird Vim installieren können. Und
dass die Debianleute jede Upstream-Software in ihre Einzelteile zerlegen
und feingranulierte Pakete draus bauen, wirst du ja wohl kaum den
Vim-Entwicklern anhängen wollen, oder?
Wo du grad bei Bloat warst: vim.tiny und nano sind etwa gleichgroß. Wenn
du also unter dem Gesichtspunkt erwartest, dass beim Vim die wirklich
umfangreiche Funktionalität dabei wäre, während Nano sich zugunsten
einfacher Bedienung auf einige Grundfunktionen beschränkt, wäre doch
wohl Nano an dieser Stelle der Bloat?
Wie auch immer … ist abzusehen, wo die „Diskussion“ mit dir hinführt:
ins Tal der verbrannten Zeit. Das ist ein öder Ort – bitte reise alleine
weiter.
Nano schrieb:> Eine moderne IDE hat das Problem nicht, die ist vollständig grafisch.
Ich weiß nicht, was das für dich ist. Wenn man in den Fenstern JPEGs,
PNGs und PDFs darstellen kann, dann ist das für mich schon "vollständig
grafisch". (Bunte Icons für Menüs kann er auch schon lange, aber die
verplempern mir zu viel Platz, die schalte ich immer als erstes aus.)
Ich sag ja: du kennst das einfach nicht. Ist auch nicht schlimm, du
musst das GUI davon ja nicht mögen, aber dann red doch lieber nicht
drüber.
Jack V. schrieb:> Nano schrieb:>> Ja, was kann ich dafür. Kläre das mit den Debianleuten wofür die eine>> tiny Version brauchen.>> Warum sollte ich das klären? Du argumentierst doch auf der Basis einer> abgespeckten Version
Nö, du hast gesagt, VIM kann das immer und überall. Grundfunktion halt.
> … ich weiß, was es damit auf sich hat, und ich> würde mir nicht die Blöße geben, wild rumzuranten und gar persönlich> beleidigend zu werden,
Also letzteres machst ja genau du, siehe mein altes Posting von heute
Nachmittag, wo ich dir das bereits gesagt habe:
Beitrag "Re: Vi Editor ausgestorben?"> weil ich nicht einmal erkenne, dass ich nicht die> Upstream-Version, sondern eine vom Distributor künstlich verkleinerte> Version nutze.
Bitte erzähle hier keine Lügen. Ich habe es erkannt. Siehe mein obiges
Posting, wo ich die Shellauszüge poste, ich hätte das nicht gepostet,
wenn mir das nicht aufgefallen wäre. Und genau das ändert trotzdem
nicht, dass vim dein Feature eben nicht überall und immer kann, wie du
anfangs behauptet hast.
> Wo du grad bei Bloat warst: vim.tiny und nano sind etwa gleichgroß. Wenn> du also unter dem Gesichtspunkt erwartest, dass beim Vim die wirklich> umfangreiche Funktionalität dabei wäre, während Nano sich zugunsten> einfacher Bedienung auf einige Grundfunktionen beschränkt, wäre doch> wohl Nano an dieser Stelle der Bloat?
Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu
deinem vim-tiny.
> Wie auch immer … ist abzusehen, wo die „Diskussion“ mit dir hinführt:> ins Tal der verbrannten Zeit.
Sag mal, hast du jetzt ernsthaft gelaubt, dass du mich von vim
überzeugen kannst, wenn du mich nur oft genug persönlich angreifst, so
wie du es oben getan hast oder jetzt mir Dinge unterstellst, die ich
nicht getan habe?
Ich habe dir bereits meine Kritikpunkte zu vim gesagt und die konntest
du h alt nicht entkräften.
Auch habe ich dir dargelegt, dass dein Feature, das deine vim-tiny
Version nicht kann, ein normaler nano Editor kann und somit hast du
nichts gezeigt, was vim irgendwie außergewöhnlich macht. Stattdessen
habe ich dir dargelegt, dass all das auch ein normaler intuitiv
erschließbarer Editor kann und so eine Befehlszeile auch immer einbaubar
ist.
Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein
vim und für Configfiles reicht mir nano.
Akzeptiere das endlich.
Ich finde es jetzt auch nicht zielführend wenn jede Linuxdistri ihre
eigene Version eines abgespekten vim benutzt. Sollen sie doch den
richtigen vim nutzen, dann gibts auch keine Inkompatibilitäten in der
Bedienung und auch mit Bugfixes hat man es dann einfacher. Eine
Erstellung einer extra abgespeckten Version ist sinnlos vergeudete
Arbeitszeit. Ja die Installation des richtigen vim dauert vielleicht
weniger als 2 Minuten. Trotzdem ist es ärgerlich wenn man es machen muss
und nicht davon ausgehen kann, dass auch auf allen fremden Systemen die
richtige Version installiert ist.
Nano schrieb:> Nö, du hast gesagt, VIM kann das immer und überall. Grundfunktion halt.
Meine Güte, merkst du es wirklich nicht? Da hat ein Dritter
Funktionalität zugunsten kleinerer Größe rausgepatched, es ist nicht
„der“ Vim. Der behauptet nicht einmal, dass es „der” Vim wäre, sondern
nennt es treffend „vim.tiny“. Und wenn du jetzt gar noch behauptest,
dass dir das die ganze Zeit über bewusst gewesen wäre: was genau hast du
dann mit dieser Farce bezweckt?
Falls du wirklich ein solches Verständnisproblem damit hast, versuch’s
dir doch einfach mal andersrum vorzustellen: Ich nehme mir den
Nano-Code, patche einige Funktionen, die du oben gepostet hast, raus und
behaupte dann, dass „der“ Nano das ja gar nicht könne; was du da
behauptest, wär’ Stuss, die ursprüngliche Nano-Version wär’ Bloat, und
würde dir noch ’n paar andere Sachen an den Kopf knallen, wie du weiter
oben selbst abgesondert hast. Würdest du mir dann Recht geben? Rein
logisch müsstest du – aber bist du in der Lage, das zu erkennen? Ich
fürchte leider, dass nicht :(
Nano schrieb:> Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein> vim und für Configfiles reicht mir nano.> Akzeptiere das endlich.
Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen,
dass das für mich vollkommen in Ordnung ist, und ich das mehrfach,
direkt und eigentlich unmissverständlich so geschrieben habe. Das
Problem liegt an deinem schon fast fanatisch erscheinenden Kampf gegen
Vim und seine User – darin, dass du mit allen Mitteln versuchst, es als
generell, für jeden gleichermaßen, untauglich darzustellen. Und da fügt
sich die Episode mit vim.tiny auch irgendwie wunderbar ein. Bleibt nur
die Frage: was könntest du davon haben?
Ich denke, Norbert hat Recht: es ist dir wirklich entglitten. Grüß den
Kaktus im Tal der verbrannten Zeit o/
Rolf M. schrieb:> Warum muss eigentlich immer gleich gegen die Nutzer der Software> gegiftet werden?
Es gehört in diesem Forum leider zum "guten Ton" dass überwiegend gegen
Leute gegiftet wird anstatt sachlich über das Thema zu diskutieren. Ist
hier so schlimm wie nirgends sonst. Leider...
OT Ende
abcde schrieb:> Ich finde es jetzt auch nicht zielführend wenn jede Linuxdistri ihre> eigene Version eines abgespekten vim benutzt.
Ist es auch nicht, aber erzähl' das mal den Leuten bei Debian. Aber ach,
wenn es denn nur den vim beträfe -- aber bei denen geht das ja leider
noch viel weiter, zum Beispiel mit der dash. Die spart ungefähr ein
vierzehntel Kilobyte Arbeitsspeicher und bootet das System etwa eine
halbe Tausendstel Sekunde schneller -- also, würde sie, wenn Debian
nicht auf systemd gewechselt wäre -- und dafür nehmen sie einfach mal
subtile Inkompatibilitäten mit dem Rest der Linux-Welt in Kauf und
wundern sich (oder ärgern sich sogar), wenn erfahrene Linux-Profis
Debian zwar selbst benutzen, es Anfängern aber trotzdem nicht empfehlen
wollen.
Jack V. schrieb:> Und da fügt> sich die Episode mit vim.tiny auch irgendwie wunderbar ein. Bleibt nur> die Frage: was könntest du davon haben?
Ich denke es ging darum, dass nano bei fast jedem Linux standardmäßig
mitinstalliert wird und deshalb fast überall vorhanden ist. Vim wird
hingegen nicht überall (zumindest nicht bei Debian und davon
abgeleiteten Distros) automatisch mitinstalliert, stattdessen wird ein
vim.tiny geliefert, der weniger kann als nano. Die Aussage, dass ein
Vorteil von vim eben diese wäre, dass er überall installiert ist, stimmt
also einfach nicht.
abcde schrieb:> Die Aussage, dass ein> Vorteil von vim eben diese wäre, dass er überall installiert ist, stimmt> also einfach nicht.
Naja, die Aussage war, dass er überall verfügbar wäre. Das hat eine
leicht andere Bedeutung.
Weiterhin ist nano vielleicht bei Debian per default installiert
(bestätigen kann ich es nicht: die letzten zehn Jahre oder so hab ich
Debian mittels debootstrap zusammengesteckt, und da ist dann weder Vim,
noch Nano installiert), bei anderen Systemen sieht’s halt auch schon
wieder anders aus. Und wenn ich dann einen Editor installiere, dann doch
den, der mir zusagt. Wenn mich dann jemand von der Seite anmacht und
mir erzählen will, dass ich doof wäre und mein Editor sowieso nix taugen
würde, dann frage ich mich schon ein wenig: WTF? Und wenn ich dann kurz
erläutere, warum ich diesen Editor einem anderen gegenüber bevorzuge,
und mir dann das entgegengeschleudert wird, was der Gast da rausgehauen
hat, dann frage ich mich zusätzlich auch noch: WTF??
Yalu X. schrieb:> Für das Eingeben von Quellcode über die PC-Tastatur ist das System nur> eingeschränkt übertragbar, da viele Tasten (Cursor-, Funktionstasten> usw.) aus der fixen Handposition heraus gar nicht erreichbar sind.
Bei vi(m) und emacs braucht man die Cursor- und Funktionstasten gar
nicht. Im vi(m) (im command mode) bewegt man den Cursor mit h, j, k, l
und im emacs mit C-b, C-f, C-p, C-n.
Hallo,
hier wird ja immer wieder von den Vi(m)-Benutzern angeführt wie effektiv
und schnell man mit Vi(m) gegenüber einem grafischen Editor mit seinen
Auswahlmenüs arbeiten kann.
Jetzt würde mich aber doch mal interessieren wie viel schneller man
tatsächlich wird. Vielleicht kann ja mal jemand, der mit Programmen aus
beiden Welten arbeitet, was dazu sagen.
rhf
abcde schrieb:> Ich denke es ging darum, dass nano bei fast jedem Linux standardmäßig> mitinstalliert wird und deshalb fast überall vorhanden ist. Vim wird> hingegen nicht überall (zumindest nicht bei Debian und davon> abgeleiteten Distros) automatisch mitinstalliert, stattdessen wird ein> vim.tiny geliefert, der weniger kann als nano.
Trotzdem kann auf so ziemlich jedem UNIXioden System unter dem Befehl
"vi" ein Programm aufgerufen werden, mit dem seine Benutzerin ihre
Dateien editieren kann. Also gut, wenn sie kann natürlich, das trifft ja
nicht auf jede Benutzerin zu, wie wir hier im Thread wieder einmal
eindrucksvoll bewundern durften. Aber das ist eine ganz andere Nummer:
beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall
gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine
Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also
beispielsweise zu dem Paketmanagement des Systems eine Paketquelle
hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs,
XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann. Und genau
deswegen, weil es den vi und seine Klone und Abarten unter jedem
UNIXoiden System gibt und man damit Textdateien editieren kann, ist es
sinnvoll, dieses Werkzeug zumindest rudimentär zu beherrschen.
Wenn ich eine Reifenpanne habe, muß ich mir leider auch mit dem
verkrüppelten Witz behelfen, den mein KFZ-Hersteller unter der
Bezeichnung "Wagenheber" beigelegt hat, und so ist das auch mit Debians
bescheuertem "vim.tiny". Wenn ich planmäßig meine Sommer- oder
Winterreifen aufziehen will, benutze ich meine komfortable Hebebühne,
und wenn ich richtige Entwicklungsarbeit machen will, meinen Emacs.
So ist das auch mit einem Editor: wenn ich einen Editor als
Entwicklungsplattform benutze, ist eine ganz andere Nummer, als wenn
ich nur mal schnell eine Konfigdatei editieren will. Den konfiguriert
man sich, der wird gehätschelt, gepflegt, erweitert und über die Wochen,
Monate und Jahre perfekt an die eigenen Bedürfnisse, Ideen und Ideale
angepaßt. Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr
(den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt
hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano"
installieren können).
Roland F. schrieb:> Jetzt würde mich aber doch mal interessieren wie viel schneller man> tatsächlich wird.
Das hängt wohl wirklich davon ab, wieviel du damit machst.
Musst du nur jede Woche dreimal eine Config-Datei anpassen, dann
brauchst du einen möglichst simplen Editor.
Sitzt du den halben Tag (oder mehr) davor, dann willst du möglichst
effizient sein. Dann wiederum gibt es Leute, die sind effizient, sich
immer mal wieder durch ein paar Menüs zu hangeln und ansonsten viel
tippen, während andere möglichst viel mit möglichst wenig Tastendrücken
gemacht haben wollen. Das schließt nun keineswegs nur vi(m) oder Emacs
ein, auch mit dem in letzter Zeit recht populär gewordenen VSCode
(immerhin mal Opensource by Microsoft) kann man auf diese Weise
arbeiten.
Roland F. schrieb:> Jetzt würde mich aber doch mal interessieren wie viel schneller man> tatsächlich wird.
Einen Eindruck davon kann man auch in einigen (youtube) Videos bekommen.
Z.B. "Vim Can Save You Hours Of Work"
https://www.youtube.com/watch?v=bshMXXX40_4
oder "50+ Vim Tips and Tricks from Beginner to Expert"
https://www.youtube.com/watch?v=ZEIpdC_klDI
Wie bei anderen Sachen auch, hängt die Geschwindigkeit davon ab wie oft
und lange man seinen Editor nutzt.
P.S. Es gibt sicher bessere Videos, aber ich nutze youtube nicht oft.
Für alle die "Was ist besser: emacs oder vim?" nicht mehr hören können.
Zur Abwechslung:
"Nano Or Vim? Which Terminal Text Editor Should You Use?"
https://www.youtube.com/watch?v=vAwo7CLWlUc
:-)
Nano schrieb:> Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es> anzeigt, in welchem Mode es ist, ist auch schlecht.
Natürlich hat Vim eine Statusleiste und zeigt dort, sobald man den
Normal-Mode verlässt, auch den Mode an ("-- INSERT --" oder "-- VISUAL
--"). Das ist auch beim vim-minimal von Arch-Linux und wahrscheinlich
auch beim vim-tiny von Debian so.
Nano schrieb:> Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu> deinem vim-tiny.
Jetzt machst du dich aber langsam lächerlich. Natürlich kann man das mit
jedem Editor, nur nicht mit jedem so einfach wie mit Vim. Selbst im
Ur-vi (und damit erst recht auch im vim-tiny) geht das recht einfach mit
1
T"d,
allerdings werden dabei im Gegensatz zum Vim escapete Anführungszeichen
innerhalb des Strings nicht korrekt behandelt.
Zum Vergleich das oben von dir gepostete "Gewürge" (um deine
Ausdrucksweise zu übernehmen) für den Nano:
Nano schrieb:> ALT + G> STRG + T> " eingeben + Enter drücken> 1 cursor nach rechts> ALT + A = Markerung gesetzt> ALT + G> STRG + T> " eingeben + Enter drücken> STRK + K
Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel
schneller zeichenweise mit der Delete-Taste.
Nano schrieb:> Schon komisch, dass man dafür eine Bloatwareversion braucht.
Vi (ohne 'm') alles andere als Bloatware:
1
vi: Installed Size : 315.50 KiB
2
nano: Installed Size : 2.48 MiB
Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt,
ist auch Vi trotz seines Alters noch ein recht guter und effizient
nutzbarer Editor.
Ein T. schrieb:> beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall> gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine> Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also> beispielsweise zu dem Paketmanagement des Systems eine Paketquelle> hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs,> XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann.
Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung,
die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein
nano auch meist installiert ist). Wenn man dann richtig arbeiten muss,
nimmt man auch einen richtigen Editor.
Felix schrieb:> Ein T. schrieb:>> beim vi(m) geht es quasi um eine Art "Notfallwerkzeug", das es überall>> gibt und das einem erfahrenen Nutzer auf jedem UNIXoiden System eine>> Möglichkeit eröffnet, erste Konfigurationsarbeiten zu machen -- also>> beispielsweise zu dem Paketmanagement des Systems eine Paketquelle>> hinzuzufügen, von wo man einen richtigen Editor wie den GNU Emacs,>> XEmacs, Lucid-Emacs, Aquamacs oder SXEmacs installieren kann.>> Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung,> die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein> nano auch meist installiert ist). Wenn man dann richtig arbeiten muss,> nimmt man auch einen richtigen Editor.
Auch vi(m) kann ein richtiger Editor sein. Aber das ist dann eine andere
Nummer als der "vim.tiny" oder der "nano" von dem aggressiven Gast hier.
Jörg W. schrieb:> Das schließt nun keineswegs nur vi(m) oder Emacs> ein, auch mit dem in letzter Zeit recht populär gewordenen VSCode> (immerhin mal Opensource by Microsoft) kann man auf diese Weise> arbeiten.
VSCode ist deswegen ein guter Editor zum Programmieren, weil er das
Language Server Protocol versteht und nutzt.
https://en.wikipedia.org/wiki/Language_Server_Protocol
Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu
erfahren.
Es gibt hunderte Editoren die ein paar Dutzend Programmiersprachen als
unterstützt aufzählen, aber gemeint ist bei denen dann meist nur die
farbliche Hervorhebung und das erkennen von Schlüsselwörtern.
Eine Programmiersprachenunterstützung durch LSP ist aber weitaus mehr
als nur die Syntax des Codes einer Programmiersprache mit einem
entsprechenden Syntax Highligning darzustellen, bei LSP geht es darum,
die Sprache auch wirklich zu verstehen und das im Editor dann
entsprechend zu unterstützen.
Es erspart vor allem auch dem Editorschreiber das Rad jedes mal neu zu
erfinden und Fehler zu vermeiden, wenn er eine bestimmte
Sprachunterstützung nun in den Editor einbauen möchte.
Das LSP ist damit die Zukunft eines jeden ernsthaften Programmiereditors
und jeder ernsthaften IDE und da die Unterstützung bei VSCode
diesbezüglich sehr gut ist, zumal LSP mit VSCode anfing, ist VSCode
natürlich sehr beliebt.
Auch die neueren Versionen von KDevelop verfügen inzwischen über eine
LSP Unterstützung, während Programmiersprachen die bei KDevelop mal als
unterstützt bezeichnet wurden, aber es da meist nur um das Syntax
Highlightning und erkennen von Schlüsselwörtern ging, deswegen aus
KDevelop entfernt wurden.
Yalu X. schrieb:> Nano schrieb:>> Und dass vim in der Defaulteinstellung keine Statusleiste hat, in dem es>> anzeigt, in welchem Mode es ist, ist auch schlecht.>> Natürlich hat Vim eine Statusleiste und zeigt dort, sobald man den> Normal-Mode verlässt, auch den Mode an ("-- INSERT --" oder "-- VISUAL> --"). Das ist auch beim vim-minimal von Arch-Linux und wahrscheinlich> auch beim vim-tiny von Debian so.
Nein, bei vim-tiny von Debian bzw. Rasbian ist das nicht so, deswegen
habe ich das oben auch erwähnt.
Nur die Vollversion, die ich jetzt nachinstalliert habe, zeigt das an.
> Nano schrieb:>> Na nano kann dieses String zwischen den "" entfernen ja, im Gegensatz zu>> deinem vim-tiny.>> Jetzt machst du dich aber langsam lächerlich. Natürlich kann man das mit> jedem Editor, nur nicht mit jedem so einfach wie mit Vim.
Vim-tiny kann es nicht und Notepad wird das auch nicht können.
Man braucht dazu also schon einen erweiterten Editor.
PS:
Es geht nicht darum, den String zwischen zwei "" händisch zu entfernen,
das geht mit Notepad dann natürlich auch, war hier aber nicht gemeint.
> Selbst im> Ur-vi (und damit erst recht auch im vim-tiny) geht das recht einfach mit>>
1
> T"d,
2
>
>> allerdings werden dabei im Gegensatz zum Vim escapete Anführungszeichen> innerhalb des Strings nicht korrekt behandelt.
Das ist nicht die gleiche Kommandosequenz, die Jack angeführt hat.
Du hast jetzt halt einen anderen Weg gefunden, prima, das funktioniert
sogar in vim-tiny.
Es ist aber dann schon eure Aufgabe, euch auf die richtige
Kommandosequenz zu einigen. Natürlich beziehe ich mich bei meinen
vorherigen Kommentaren auf das, was zuerst genannt wurde und nicht das,
was ihr im Nachhinein alternativ noch herausfindet. Und das
erstgenannte, das geht in vim-tiny dann halt nicht.
> Zum Vergleich das oben von dir gepostete "Gewürge" (um deine> Ausdrucksweise zu übernehmen) für den Nano:>> Nano schrieb:>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> 1 cursor nach rechts>> ALT + A = Markerung gesetzt>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> STRK + K>> Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel> schneller zeichenweise mit der Delete-Taste.
Tja keine Ahnung wer das braucht, es ging ja nur darum zu
veranschaulichen das das auch geht und bei nano erschließt sich das
sogar intuitiv.
Wie ich das machen würde, mit STRG+K usw., das habe ich oben ja erklärt.
> Vi (ohne 'm') alles andere als Bloatware:>>
1
> vi: Installed Size : 315.50 KiB
2
> nano: Installed Size : 2.48 MiB
3
>
>> Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt,> ist auch Vi trotz seines Alters noch ein recht guter und effizient> nutzbarer Editor.
Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht?
> Yalu X. schrieb:>> Vi (ohne 'm') alles andere als Bloatware:>>>>> vi: Installed Size : 315.50 KiB>> nano: Installed Size : 2.48 MiB>>
So, habe jetzt mal pico nachgemessen.
pico: Installed Size : 116.11 KiB
Und der läuft sogar mit nur 528 KiB RAM.
Siehe Screenshots.
:p
>> Wenn man auf die "intelligenten" Funktionen von Vim keinen Wert legt,>> ist auch Vi trotz seines Alters noch ein recht guter und effizient>> nutzbarer Editor.
Ich habe übrigens nicht bestritten, dass er ineffizient wäre.
Für Configdateien werde ich trotzdem nano, pico oder meinetwegen
notepad.exe und edit.exe einsetzen, solange einer von denen verfügbar
ist.
Roland F. schrieb:> Hallo,> hier wird ja immer wieder von den Vi(m)-Benutzern angeführt wie effektiv> und schnell man mit Vi(m) gegenüber einem grafischen Editor mit seinen> Auswahlmenüs arbeiten kann.> Jetzt würde mich aber doch mal interessieren wie viel schneller man> tatsächlich wird. Vielleicht kann ja mal jemand, der mit Programmen aus> beiden Welten arbeitet, was dazu sagen.
Das wird eher schwierig, das in objektiven Zahlen auszurücken. Ich weiß
nur, dass Kollegen öfter mal beeindruckt sind, wie schnell ich manche
Dinge mit vim erledigt bekomme.
Nano schrieb:> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das> Language Server Protocol versteht und nutzt.>> https://en.wikipedia.org/wiki/Language_Server_Protocol>> Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu> erfahren.
Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende
Funktionalität (kontextsensitive Autovervollständigung, Anzeige von
Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.)
für einige Sprachen auch schon ohne Language Server mitbringt. Es kann
aber wohl auch mit Language Servern kommunizieren.
https://github.com/ycm-core/YouCompleteMe#semantic-completion-for-other-languages
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?
Selbstverständlich!
Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du
z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw.
Ich liebe es, dass man vi/m LERNEN muss und wenn man es gelernt hat, ist
die Arbeit damit sehr effektiv.
Das ist genau das Gegenteil von dem "user-friendly" Windows-Scheiß
(usw.), wo behauptet wird, dass alles so leicht und einfach gemacht ist,
dass es selbst kleine Kinder intuitiv beherrschen können. Wenn man aber
etwas nur ein bisschen Anspruchsvolleres braucht, dann klickt man sich
tot und es dauert eine Ewigkeit.
Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn
gesund hält...
neovim hätte nativen LSP-Support, für den ursprünglichen Vim gibt es
mehrere Möglichkeiten, das bei Bedarf einzurichten. Bevor der Gast nun
mit „ja, aber aber aber … aber das ist nicht nativ!!k“ kommt: bei den
meisten IDEs wird’s ebenfalls über Plugins oder Extensions realisiert,
und für Nano oder gar Pico gibt’s gar keine Möglichkeit – also STFU!
Nano schrieb:> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das> Language Server Protocol versteht und nutzt.
Aha. VSCode ist also deshalb ein "guter Editor", weil er ein selbst
definiertes Protokoll benutzt. Interessant. Mit dieser
Argumentationslinie kannst du wohl jeden Editor als "guten Editor"
deklarieren …
(Ich stelle natürlich nicht in Abrede, dass VSCode ein guter Editor ist,
nur die Argumentation ist Käse.)
Nano schrieb:> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das> Language Server Protocol versteht und nutzt.
Jaja, tollstes Feature seit geschnittenem Brot. Blöd halt, daß die
Entwicklung von Sourcecode seit etlichen Jahrzehnten ohne dieses tolle
Ding auskommt -- inklusive der Entwicklung von LSP selbst.
Weißt Du, ich hab' jetzt schon eine ganze Menge solcher "Gott-Features"
gesehen, ohne die Entwickler angeblich nicht mehr arbeiten können. Die
meisten davon sind nach kurzer Zeit wieder sang- und klanglos
untergegangen. Syntax-Highlighting, Autocompletion, -Brackets und
-Indentation haben sich allerdings gehalten.
> https://en.wikipedia.org/wiki/Language_Server_Protocol>> Keine Ahnung ob vim das auch kann,
Lesen bildet: [1]. Dein toller nano ist da übrigens nicht aufgeführt.
Emacs und vi dagegen schon.
[1]
https://microsoft.github.io/language-server-protocol/implementors/tools/
Nano schrieb:> Es ist aber dann schon eure Aufgabe, euch auf die richtige> Kommandosequenz zu einigen.
Warum sollten sie?
>> Nano schrieb:>>> ALT + G>>> STRG + T>>> " eingeben + Enter drücken>>> 1 cursor nach rechts>>> ALT + A = Markerung gesetzt>>> ALT + G>>> STRG + T>>> " eingeben + Enter drücken>>> STRK + K>>>> Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel>> schneller zeichenweise mit der Delete-Taste.>> Tja keine Ahnung wer das braucht, es ging ja nur darum zu> veranschaulichen das das auch geht und bei nano erschließt sich das> sogar intuitiv.
Äh... also wenn das "intuitiv" ist, haben wir beide fundamental
unterschiedliche Vorstellungen von der Bedeutung dieses Wortes.
>> Vi (ohne 'm') alles andere als Bloatware:>>>>
1
>> vi: Installed Size : 315.50 KiB
2
>> nano: Installed Size : 2.48 MiB
3
>>
>> Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht?
Egal, nano ist offensichtlich Bloatware. 2,5 MB für einen Editor, dem
obendrein auch noch Features fehlen, die Du hier anpreist wie
geschnittenes Brot... wow.
Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei
benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich
vorher ein paar Stunden oder Tage einarbeiten zu müssen. Irgendwelche
kryptischen Tastenkombinationen sind da nicht das Mittel der Wahl, die
vergisst man auch ganz schnell wieder wenn man sie nicht jeden Tag
braucht. So ein kleiner Editor muss auch nicht alles können, aber
Cursortasten sollte er schon kennen. Man sollte die Datei auch
abspeichern und den Editor beenden können, ohne dazu ein Handbuch lesen
zu müssen. Für größere Programmierprojekte nimmt man dann natürlich was
anderes.
Siggi schrieb:> Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei> benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich> vorher ein paar Stunden oder Tage einarbeiten zu müssen.
Das ist richtig, sofern man ansonsten nicht mit einem anderen Editor
arbeitet. Ich würd’ mir ziemlich blöde vorkommen, würde ich zur
Anpassung einer Config-Datei etwa nano oder pico starten, während ich
ansonsten eigentlich ausschließlich Vim nutze.
--
Ich hab mir nun mal neovim genauer angeschaut und bin gerade fast
sicher, dass er den Vim bei mir ablösen wird.
Felix schrieb:> Na also. Das ist mal eine vernünftige Aussage. vi(m) ist eine Notlösung,> die man nimmt wenn gerade nichts anderes installiert ist (obwohl ein> nano auch meist installiert ist). Wenn man dann richtig arbeiten muss,> nimmt man auch einen richtigen Editor.
Was man eben so hören bzw. lesen will ...
Ich verwende den Vim gerne. Ist mein Lieblingseditor. Ich nutze
Vim-Plugins in jeder IDE. Eben weil es damit (für mich) schneller geht.
Mal eben zwei Worte oder Zeilen vertauschen, Ziffern in Variablennamen
Hoch- oder Runterzählen, Suchen und Ersetzen, Text bis zu einem
bestimmten Zeichen löschen/Ersetzen, ... und das alles ohne ein einziges
Mal die Hand von der Tastatur zu nehmen. Inklusive all der Features von
der IDE wie Codevervollständigung, Syntaxhighlighting etc. Einfach Mal
über den Tellerrand schauen!
Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die
Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam!
Jack V. schrieb:> Siggi schrieb:>> Ein kleiner Editor, den man nur mal zur Anpassung einer Config-Datei>> benutzt, muss vor allem leicht intuitiv zu bedienen sein ohne sich>> vorher ein paar Stunden oder Tage einarbeiten zu müssen.>> Das ist richtig, sofern man ansonsten nicht mit einem anderen Editor> arbeitet. Ich würd’ mir ziemlich blöde vorkommen, würde ich zur> Anpassung einer Config-Datei etwa nano oder pico starten, während ich> ansonsten eigentlich ausschließlich Vim nutze.
Ja wenn du vim sonst auch nutzt, ist es naheliegend, ihn auch für eine
kleine Config-Datei zu nutzen.
Rolf M. schrieb:> Nano schrieb:>> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das>> Language Server Protocol versteht und nutzt.>>>> https://en.wikipedia.org/wiki/Language_Server_Protocol>>>> Keine Ahnung ob vim das auch kann, aber wäre doch mal interessant zu>> erfahren.>> Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende> Funktionalität (kontextsensitive Autovervollständigung, Anzeige von> Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.)> für einige Sprachen auch schon ohne Language Server mitbringt. Es kann> aber wohl auch mit Language Servern kommunizieren.> https://github.com/ycm-core/YouCompleteMe#semantic-completion-for-other-languages
Gut zu wissen. Und mit welcher Erweiterung debuggst du deinen Code?
Und zeigst Stack, Register, Watch-Variablenansichten usw. auf einmal an
und
zwar so, dass das gleich upgedated wird, wenn du durch den Code stepst?
Und wie sieht's mit automatischem Wiederholen der Eingaben beim Debuggen
aus, also eine Eingabesequenz? (Record and replay debugging)
Sowie reverse debugging oder dem manuellen ändern der Variablenwerte,
während dem Debugging Durchlauf?
Eine gescheite IDE hat in der Regel eine gute Debugger Integration und
bietet all das und noch viel mehr. Und Vim?
Petr T. schrieb:> Openbsd schrieb:>> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die>> ultimativen Vorzuege dieses Editors?>> Selbstverständlich!>> Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du> z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw.
Mit JEDEM mit Mausbedienung!
Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann
5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig!
Insgesamt also 2 Tasten, nicht 3.
> Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn> gesund hält...
Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus.
Owned!
Nano schrieb:> Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus.
Immer noch kein Zehnfingersystem (mit beliebigem Layout) gelernt? Dann
brauchst von Effizienz auch nix zu schreiben.
Jack V. schrieb:> neovim hätte nativen LSP-Support, für den ursprünglichen Vim gibt es> mehrere Möglichkeiten, das bei Bedarf einzurichten.
Aha, dann bietet also nur neovim das out of the box.
Während man bei vim das erst alles nachinstallieren und einrichten muss.
Wozu soll man dann vim nehmen, wenn man gleich neovim nehmen kann?
> Bevor der Gast nun> mit „ja, aber aber aber … aber das ist nicht nativ!!k“ kommt: bei den> meisten IDEs wird’s ebenfalls über Plugins oder Extensions realisiert,
Gescheite IDEs liefern diese Plugins und Extensions aber mit der
Installation der IDE gleich mit.
> und für Nano oder gar Pico gibt’s gar keine Möglichkeit – also STFU!
Nano und pico muss das auch nicht, weil nano für Configfiles da ist und
nicht die Aufgabe hat, eine IDE zu ersetzen.
Du wirbst dagegen bei vim allerdings auch mit vim als IDE Ersatz, das
ist der Unterschied, was ich bei nano nie getan habe.
Oben habe ich es sogar klar abgegrenzt, da habe ich irgendwo
geschrieben, dass ich nano zum Editieren von Configfiles und kleinen
Sachen nutze und eine IDE zum Programmieren. Also STF selber U!
Jörg W. schrieb:> Nano schrieb:>> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das>> Language Server Protocol versteht und nutzt.>> Aha. VSCode ist also deshalb ein "guter Editor", weil er ein selbst> definiertes Protokoll benutzt. Interessant. Mit dieser> Argumentationslinie kannst du wohl jeden Editor als "guten Editor"> deklarieren …
Falsch, das LSP ist standardisiert, es ist ein Standard!
Und jeder fähige IDE und Editor greift diesen Standard auf.
Jack V. schrieb:> Nano schrieb:>> Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus.>> Immer noch kein Zehnfingersystem (mit beliebigem Layout) gelernt? Dann> brauchst von Effizienz auch nix zu schreiben.
Ist das dir jetzt nicht peinlich?
Scroll mal nach oben und lies da nochmal nach.
Nochmal für die ganz Dummen:
DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz
bestimmtes und das hat mit Layouts auch nichts zu tun.
Und hier noch zum Nachlesen und bilden:
https://de.wikipedia.org/wiki/Zehnfingersystem
Vor allem ab hier:
https://de.wikipedia.org/wiki/Zehnfingersystem#Grundlegendes_Prinzip
Schon zu sagen "kein Zehnfingersystem gelernt" zu sagen ist dämlich,
denn es gibt nur EIN Zehnfingersystem, es müsste also heißen "Immer noch
nicht das Zehnfingersystem gelernt". Und nein, wieso auch, es hat beim
Programmieren keinerlei Vorteile!
Owned!
Nano schrieb:> Aha, dann bietet also nur neovim das out of the box.> Während man bei vim das erst alles nachinstallieren und einrichten muss.> Wozu soll man dann vim nehmen, wenn man gleich neovim nehmen kann?
An welcher Stelle ist diese Frage relevant? Nahezu alles, was hier im
Thread zu vim geschrieben wurde, lässt sich genausogut auf nvim
abbilden.
Nano schrieb:> Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann> 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig!
Hörmal: ich akzeptiere vollkommen, dass du Programme, die eine initale
Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist
überhaupt nichts verkehrt. Wäre schön, wenn du im Gegenzug die Physik
akzeptieren würdest: in der Zeit, die du zur Bewegung deiner Hand zur
Maus benötigst, hat jemand, der mit der Tastatur gut umgehen kann, die
drei Buchstaben abgesetzt. Dein „Beispiel“ mit der Maus wirkt genauso
krampfhaft, wie deine Shortcut-Wüste für die Funktion von di" oben.
Aber just for fun: zeig doch mal bitte kurz auf, wie du ddp umsetzen
würdest :)
Ein T. schrieb:> Nano schrieb:>> VSCode ist deswegen ein guter Editor zum Programmieren, weil er das>> Language Server Protocol versteht und nutzt.>> Jaja, tollstes Feature seit geschnittenem Brot. Blöd halt, daß die> Entwicklung von Sourcecode seit etlichen Jahrzehnten ohne dieses tolle> Ding auskommt -- inklusive der Entwicklung von LSP selbst.
Und trotzdem haben KDevelop und viele weitere IDEs und Editoren auf LSP
umgestellt, einfach weil das viel sinnvoller ist, als etwas eigenes zu
Kreiieren, das dann meist, aufgrund fehlender Manpower nur halb so gut
ist.
> Weißt Du, ich hab' jetzt schon eine ganze Menge solcher "Gott-Features"> gesehen, ohne die Entwickler angeblich nicht mehr arbeiten können. Die> meisten davon sind nach kurzer Zeit wieder sang- und klanglos> untergegangen. Syntax-Highlighting, Autocompletion, -Brackets und> -Indentation haben sich allerdings gehalten.
Begreife erst einmal die Bedeutung des LSP.
> Dein toller nano ist da übrigens nicht aufgeführt.
Muss er nicht, denn nano ist keine IDE!
> Emacs und vi dagegen schon.
Was man erwarten kann, wenn man es als IDE Ersatz bewirbt.
Nano schrieb:> Muss er nicht, denn nano ist keine IDE!
Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist
ebenfalls keine IDE, sondern ein Editor.
Ein T. schrieb:>>> Nano schrieb:>>>> ALT + G>>>> STRG + T>>>> " eingeben + Enter drücken>>>> 1 cursor nach rechts>>>> ALT + A = Markerung gesetzt>>>> ALT + G>>>> STRG + T>>>> " eingeben + Enter drücken>>>> STRK + K>>>>>> Bevor man so ein Ungetüm eintippt, löscht man den Text doch viel>>> schneller zeichenweise mit der Delete-Taste.>>>> Tja keine Ahnung wer das braucht, es ging ja nur darum zu>> veranschaulichen das das auch geht und bei nano erschließt sich das>> sogar intuitiv.>> Äh... also wenn das "intuitiv" ist, haben wir beide fundamental> unterschiedliche Vorstellungen von der Bedeutung dieses Wortes.
Ne, es ist ein Fakt, dass das intuitiv ist, da nano die Hotkeys
entsprechend in der unteren Leiste mit Beschriftung anzeigt.
Du musst im Prinzip nur ALT + G wissen. Der Rest erklärt sich selbst.
>>>> Vi (ohne 'm') alles andere als Bloatware:>>>>>>
1
>>> vi: Installed Size : 315.50 KiB
2
>>> nano: Installed Size : 2.48 MiB
3
>>>
>>>> Soll ich jetzt nachmessen, wieviel Platz pico unter meinem DOS braucht?>> Egal, nano ist offensichtlich Bloatware. 2,5 MB für einen Editor, dem> obendrein auch noch Features fehlen, die Du hier anpreist wie> geschnittenes Brot... wow.
Nano hat doch das Feature. Oben ist es belegt, du hast es sogar selber
zitiert.
Und vi hat das Feature übrigens nicht.
Und mit pico funktioniert bereits meine eigene Lösung.
Nano schrieb:> Nochmal für die ganz Dummen:> DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz> bestimmtes und das hat mit Layouts auch nichts zu tun.
Ja, und weiter?
Hände in Grundhaltung, Daumen über Space, Layout ist laut von dir
verlinkten Artikel nicht festgelegt. Was genau ist eigentlich dein Punkt
(was ich mich zunehmend eh frage, wenn du auf solchen
Nebensächlichkeiten rumrödelst, die zum eigentlichen Thema nix
beitragen).
Also, bitte beantworte mir mit klaren Worten: was ist dein Problem mit
dem Zehnfingersystem in diesem Kontext?
ThomasW schrieb:> ...Einfach Mal> über den Tellerrand schauen!>> Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die> Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam!
Zum Glück glaubst du das nur, eine Behauptung wider besserem Wissen wäre
nämlich eine Lüge.
Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger
Integration gescheitert ist.
Das impliziert, dass ich mich mehrere Tage mit vim beschäftigt habe.
Und dann haben wir hier die Hass und Pöbelfraktion, die nicht wahrhaben
will, dass und warum man vim ablehnt. Die Argumente und Begründungen
stehen sogar dabei, aber die Pöbelfraktion verhält sich halt wie ein
kleines Kind.
Getreu dem Motto
"Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen
wird."
Nano schrieb im Beitrag #
> "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen> wird."
Weshalb sollte man auch vim zerreißen?
Er ist nun mal der genialste Editor - und die, die das nicht begreifen
können … für die gibt es halt Nano
Jack V. schrieb:> Nano schrieb:>> Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann>> 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig!>> Hörmal: ich akzeptiere vollkommen, dass du Programme, die eine initale> Lernkurve haben, nicht magst,
Und das ist jetzt eine Lüge wider besserem Wissen, denn oben stehen
meine Gründe bezüglich vim dran und da geht es nicht um die Lernkurve.
Und so etwas auch noch für allgemeingültig zu erklären im Sinne von
jedes Programm, von Blender bis [such die jedes beliebig komplexe
Programm aus] ist noch dreister.
Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören
und keinen anständigen Diskurs mit Anstand und Niveau führen könenn.
> Damit ist> überhaupt nichts verkehrt. Wäre schön, wenn du im Gegenzug die Physik> akzeptieren würdest: in der Zeit, die du zur Bewegung deiner Hand zur> Maus benötigst, hat jemand, der mit der Tastatur gut umgehen kann, die> drei Buchstaben abgesetzt. Dein „Beispiel“ mit der Maus wirkt genauso> krampfhaft, wie deine Shortcut-Wüste für die Funktion von di" oben.
Deine kindische Gegenreaktion ist mal wieder albern. Denn auch weiter
oben habe ich dir bereits erklärt, dass man beim Programmieren die
meiste Zeit nicht mit Tippen verbringt, sondern damit, sich Gedanken zu
machen, wie man ein Problem jetzt löst.
Die Maus ist da eine willkommene Abwechslung und oh Überraschung, sogar
Notpad.exe von Windows kann das mit 2 Tasten und Maus.
> Aber just for fun: zeig doch mal bitte kurz auf, wie du ddp umsetzen> würdest :)
STRG + K
SRRG + U
Nano schrieb:> "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen> wird."
Hast du’s mal mit Selbstreflektion versucht? Ich meine: du musst dir
bloß mal die schiere Masse deiner Beiträge hier anschauen, teils mehrere
am Stück, dazu diese absurden „Beispiele“, das mit der Strg+…-Orgie und
das mit der Maus, um ›di"‹ und ›2dd‹ nachzubilden, um gerade Nano als
überlegen darzustellen. Dazu noch diese Unterstellungen, wie die oben
zitierte, um Vim-User als infantil darzustellen …
Hatte ich am Ende Recht mit der Vermutung, dass da ein Trauma hinter
steht?
Ich warte übrigens noch auf deine Umsetzung von ›ddp‹ in nano oder pico
– wäre ganz lieb, wenn du die noch nachreichen könntest. Ich erzähle dir
dann auch wieder, warum ›ddp‹ zu schreiben erheblich schneller ist, als
deine Strg+Maus-Orgie :)
Nano schrieb:> Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger> Integration gescheitert ist.
Ja nē – is klar: Debugger. Kannst du dir nicht einfach eingestehen, dass
du dich mit Vim im Grunde nicht einmal ausreichend beschäftigt hast, um
überhaupt zu wissen, wovon hier alle schreiben?
Mein Vorschlag: mach mal ’n Wochenende mit Vim rum. Tutorial durchgehen,
viel praktisch anwenden und so. Und dann lies nochmal, was du hier so
abgelassen hast. Ich verspreche dir: du wirst dich sehr schämen :)
Jack V. schrieb:> Nano schrieb:>> Muss er nicht, denn nano ist keine IDE!>> Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist> ebenfalls keine IDE, sondern ein Editor.
Du erzählst mir da nichts schockierendes, ich bin eher über deine
Intelligenz schockiert. Denn hier wird von dir und anderen vim ja als
IDE Ersatz beworben.
In dem ganzen Thread willst du mir erklären, warum ich anstatt einer IDE
vim einsetzen soll und jetzt willst du plötzlich zurückrudern und sagst
nun, dass du das alles nicht so gemeint hast?
Jack V. schrieb:> Nano schrieb:>> Nochmal für die ganz Dummen:>> DAS Zehnfingersystem ist ein Eigenname und definiert etwas ganz>> bestimmtes und das hat mit Layouts auch nichts zu tun.>> Ja, und weiter?
Wer erklärt es ihm noch einmal?
Oben haben es ja einige schon getan, aber bei ihm dauert das wohl
länger.
Also, wer erklärt es noch einmal, so dass er es kapiert?
Jack V. schrieb:> Dazu noch diese Unterstellungen, wie die oben> zitierte, um Vim-User als infantil darzustellen …
Ich habe da ausschließlich nur von dir gesprochen und dieses
Pöbelverhalten hast du schon gestern gezeigt und auch da habe ich dich
darauf hingewiesen und du willst nichts daraus lernen.
> Ich warte übrigens noch auf deine Umsetzung von ›ddp‹ in nano oder pico> – wäre ganz lieb,
Kannst du nicht lesen? Oben steht es bereits.
Jack V. schrieb:> Nano schrieb:>> Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger>> Integration gescheitert ist.>> Ja nē – is klar: Debugger. Kannst du dir nicht einfach eingestehen, dass> du dich mit Vim im Grunde nicht einmal ausreichend beschäftigt hast, um> überhaupt zu wissen, wovon hier alle schreiben?
Wie schon gesagt, lies oben nochmal nach.
Am besten fängst du mit dem Thread von ganz von vorne an und liest die
alten Beiträge. Der Thread wurde ja eh aus dem Grab geholt.
> Mein Vorschlag: mach mal ’n Wochenende mit Vim rum. Tutorial durchgehen,> viel praktisch anwenden und so. Und dann lies nochmal, was du hier so> abgelassen hast. Ich verspreche dir: du wirst dich sehr schämen :)
Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass
ich das schon vor Jahren gemacht habe. Und nö, ich schäm mich nicht, ich
bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt.
Nano schrieb:> Denn hier wird von dir und anderen vim ja als> IDE Ersatz beworben.
Dann zeig mal eine Kostprobe deiner Intelligenz, und zitiere die
Stelle, an der ich dieses mache. Ebenso die Stelle, an der ich dir
erklären möchte, dass du Vim anstelle einer IDE einsetzen solltes!
Wie? Kannst du nicht? Weil ich nämlich das genaue Gegenteil geschrieben
habe? Na sowas aber auch …
Ernstgemeinte Frage: merkst du es wirklich nicht selbst?
Nano schrieb:> Wer erklärt es ihm noch einmal?
Erklär’ du mir doch bitte genau einmal, was das Problem mit dem
Zehnfingersystem und Vim sein soll. In meinem täglichen Erleben
harmoniert das nämlich ganz wunderbar, insbesondere im Zusammenhang mit
Neo2.
Wie? Kannst du nicht? Weil es nämlich gar kein Problem mit dem
Zehnfingersystem und Vim gibt, sondern beide ganz ausgezeichnet
harmonieren? Na sowas aber auch …
Nano schrieb:> Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass> ich das schon vor Jahren gemacht habe.
Sorry, aber ich muss da nun mal direkt fragen: was bringt’s dir, so
dreist zu lügen?
Ergänzung zu:
> ich> bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt.
Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem
in diesem Thread.
Gestern hast du übrigens gesagt, dass du dich aus dem Thread entfernst.
Nano schrieb:> Ergänzung zu:>>> ich>> bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt.>> Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem> in diesem Thread.
Ja, komm – ich kopier’s einmal für dich zusammen. Wenn du’s dann noch
nicht erfasst hast, weiß ich auch nicht weiter. Dann gehe ich davon aus,
dass du ’n …ter Troll bist, und nicht nur von eingeschränkter
Auffassungsgabe:
Jack V. schrieb:> ich akzeptiere vollkommen, dass du Programme, die eine initale> Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist> überhaupt nichts verkehrt.Jack V. schrieb:> Nano schrieb:>> Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein>> vim und für Configfiles reicht mir nano.>> Akzeptiere das endlich.>> Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen,> dass das für mich vollkommen in Ordnung ist, und ich das mehrfach,> direkt und eigentlich unmissverständlich so geschrieben habe.Jack V. schrieb:> Dass Vim nix für dich> ist, hast du ja nun zur Genüge dargelegt, und ich habe auch überhaupt> kein Problem damit – insbesondere käme mir nicht mal die Idee, dir die> überhaupt die weitere Beschäftigung mit dem Programm nahelegen zu> wollen.
Nun mach doch bitte auch das Gleiche für deine Behauptung, ich würde Vim
als IDE-Ersatz propagiert haben, oder dir gar die Verwendung von Vim
als IDE-Ersatz empfohlen haben.
Wie, kannst du nicht? Na sowas aber auch …
Nano schrieb:> Gestern hast du übrigens gesagt, dass du dich aus dem Thread entfernst.
Ja … ärgere mich auch selbst, dass du mit deiner absurden Trollerei
wieder Erfolg hattest. Aber danke für die Erinnerung :)
Jack V. schrieb:> Nano schrieb:>> Denn hier wird von dir und anderen vim ja als>> IDE Ersatz beworben.>> Dann zeig mal eine Kostprobe deiner Intelligenz, und zitiere die> Stelle, an der ich dieses mache.
Da du aus dem dem Threadverlauf und Kontext weißt, warum ich eine IDE
und nicht vim benutze, (ganz vorne schreibe ich übrigens auch was zum
Thema Debuggen) du aber dennoch hier:
Beitrag "Re: Vi Editor ausgestorben?"
dagegen gehalten hast, sagst du auch mit genau diesem Kommentar, was
deiner Meinung beim Programmieren wichtig sei und damit bewirbst du vim
als IDE Ersatz.
Es ergibt sich also aus dem Kontext.
Zumal auch das Beispiel Strings zwischen zwei Quotes programmiertypisch
ist.
Zum Kochbücher schreiben braucht man so eine Funktion nämlich eher
nicht.
> Ebenso die Stelle, an der ich dir> erklären möchte, dass du Vim anstelle einer IDE einsetzen solltes!
Es ist aus dem Kontext ergebend das gleiche Kommentar.
> Wie? Kannst du nicht?
Doch, kann ich, siehe dein Kommentar, siehe vorheriger Absatz.
> Weil ich nämlich das genaue Gegenteil geschrieben> habe? Na sowas aber auch …
Und das ist ein paar Kommentare später genau die Stelle, in der du so
etwas zwar behaupten willst, aber mich dann gleich persönlich angreifst,
weil ich vim nicht nutze. Damit ist deine Behauptung nicht aufrichtig
und somit hinfällig.
> Nano schrieb:>> Wer erklärt es ihm noch einmal?>> Erklär’ du mir doch bitte genau einmal, was das Problem mit dem> Zehnfingersystem und Vim sein soll.
Ah, du siehst jetzt ein, dass es DAS Zehnfingersystem gibt?
Warum nicht gleich so.
Fest steht aber und das sieht man hier wieder gut:
> In meinem täglichen Erleben> harmoniert das nämlich ganz wunderbar, insbesondere im Zusammenhang mit> Neo2.>> Wie? Kannst du nicht? Weil es nämlich gar kein Problem mit dem> Zehnfingersystem und Vim gibt, sondern beide ganz ausgezeichnet> harmonieren? Na sowas aber auch …
Dass du ein Problem damit hast, Niederlagen einzugestehen, denn jetzt,
nachdem du festgestellt hast, dass das Zehnfingersystem etwas ganz
bestimmtes ist, machst du eine ganz neue Baustelle auf um deine
Niederlage zu kaschieren.
Und zu deiner Frage, warum das Zehnfingersystem zum Programmieren nicht
gut geeignet ist, haben andere hier vor mir schon erklärt, lies da
nochmal nach.
> Nano schrieb:>> Wenn du mitdenken und vor allem lesen würdest, dann wüsstest du, dass>> ich das schon vor Jahren gemacht habe.>> Sorry, aber ich muss da nun mal direkt fragen: was bringt’s dir, so> dreist zu lügen?
Hier:
Beitrag "Re: Vi Editor ausgestorben?"
da steht und das Kommentar ist aus dem Jahr 2020 (Anmerkung: Inhaltich
bezieht sich das sogar noch auf einen Zeitpunkt ein paar Jahre vorher,
aber es wurde damals ja nicht nach einem genauen Zeitpunkt gefragt):
"Ein paar Tutorials habe ich auch schon durchgearbeitet, aber über kurz
oder lang vergisst man die weiterführenden Kommandos halt doch und
leistungsfähige GUI Editoren können heutzutage mehr, als mancher Vim
Nutzer denkt."
Und da
Beitrag "Re: Vi Editor ausgestorben?"
steht:
"Das schlimmste an vim ist aber der fehlende Debugmodus, ja man kann den
auch nachträglich nachrüsten, aber gdb, den vim dann integriert, ist
deutlich umständlicher, als die Buttons und Tastaturkombinationen in der
IDE.
Insbesondere wenn man die Variablen gleichzeitig nach jedem Schritt
sehen können möchte. Bei gdb muss man erst den step eingeben und dann
sagen, welche Variablen man anschauen will. Bei der IDE sieht man die
Variablenzustände immer und man drückt einfach seine Taste oder den
Button.
Und da das nicht bei vim voreingestellt ist, hat man noch eine weitere
Hürde bis alles passt."
Fazit:
Hättest halt nur mal den Thread nochmal gelesen, wie ich dir geraten
habe.
Ich denke damit bist du jetzt aus der Diskussion raus. Du wolltest dich
eigentlich bereits gestern schon aus dieser entfernen, schon vergessen.
Nano schrieb:> Es ergibt sich also aus dem Kontext.
Du weißt aber schon, dass du bei so zusammengedichteten Kontexten auch
mal arg danebenliegen kannst?
Nun: in diesem Fall scheint es so zu sein, und du liegst mit deiner
Interpretation meiner Beiträge völlig daneben.
Tut mir leid, dir das mitteilen zu müssen: du hast die ganze Zeit gegen
einen imaginären Feind „argumentiert“. Teils ziemlich … wirr, wenn ich
das so sagen darf. Nimm dein Nano und deine IDE, mach deinen Kram damit,
aber hör endlich auf, die Leute vollzusülzen, die das Konzept vom Vim
kennen und mögen.
Jack V. schrieb:> Nano schrieb:>> Muss er nicht, denn nano ist keine IDE!>> Pass auf, ich muss dir jetzt was ganz Schockierendes erzählen: Vim ist> ebenfalls keine IDE, sondern ein Editor.
Dazu kann man verschiedene Ansichten vertreten, immerhin unterstützen
vi(m) und Emacs so ziemlich alle Funktionen, die eine IDE auch hat. Sie
sind allerdings deutlich flexibler und besser konfigurierbar, nicht auf
Klickibunti angewiesen, meistens wesentlich performanter als die
üblichen GUI-Monster und unterstützen deutlich mehr Sprachen als diese.
Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell:
das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat
man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr
flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese
Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von
Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-)
Ein T. schrieb:> Dazu kann man verschiedene Ansichten vertreten, immerhin unterstützen> vi(m) und Emacs so ziemlich alle Funktionen, die eine IDE auch hat.
Ja, und man kann sie zu einer IDE konfigurieren – incl. Debugger,
Syntaxhighlight, Outlines, Filebrowser, etc., pp.
Aber letztlich sind es Editoren, wenn auch ziemlich ausgefeilte und
umfangreiche Vertreter ihrer Spezies, und wenn man einem User, der stark
auf „discoverability” angewiesen ist und der daher die herkömmlichen im
hohen Maße visuell ausgerichteten IDEs verwendet, und der auch von sich
aus überhaupt nicht den Wunsch verspürt, daran irgendwas zu ändern,
versucht, diese Editoren als IDE anzubieten, dann geht’s schief. Im
schlimmsten Falle passiert dann, was man hier vom Gast zu sehen bekommen
hat. Sollte man also nicht machen.
Anders sieht’s aus, wenn jemand mit dem notwendigen Maß an Neugier und
Offenheit von sich aus anfängt, sich das mal genauer anzugucken, und da
auch mal ein paar Stunden investiert.
Ist wie in der Psychologie: der Patient muss es von sich aus wollen,
sonst wird es nichts.
Jack V. schrieb:> Nano schrieb:>> Ergänzung zu:>>>>> ich>>> bin eher davon überzeugt, dass vim meine Anforderungen nicht erfüllt.>>>> Aber damit kommst du, Jack V. ja nicht klar und darin liegt das Problem>> in diesem Thread.>> Ja, komm – ich kopier’s einmal für dich zusammen. Wenn du’s dann noch> nicht erfasst hast, weiß ich auch nicht weiter. Dann gehe ich davon aus,> dass du ’n …ter Troll bist, und nicht nur von eingeschränkter> Auffassungsgabe:
Und wieder eine Beleidigung…
>> Jack V. schrieb:>> ich akzeptiere vollkommen, dass du Programme, die eine initale>> Lernkurve haben, nicht magst, und dich lieber so durchklickst. Damit ist>> überhaupt nichts verkehrt.
Nein, das du kein Problem damit hättest, dass ich vim nicht nutze, sagst
du zwar immer wieder und du wiederholst dich, du meinst es aber nie so
und das habe ich dir bereits Gestern erklärt warum du hier nicht
aufrichtig bist:
Hier ist dein alter Text:
Beitrag "Re: Vi Editor ausgestorben?"
Da sagst du zwar, dass du zwar kein Problem damit hättest, dass ich vim
nicht nutze, aber dann greifst du mich anschließend direkt wieder an,
womit du deine erste Aussage selbst untergräbst und darauf bin ich dann
gestern hier eingegangen, wo ich deine persönlichen aggressiven Angriffe
dann nochmal detailliert beschrieben habe:
Beitrag "Re: Vi Editor ausgestorben?"
Da habe ich dir geschrieben:
### Anfang des Zitats:
"
Jack V. schrieb:
> Mich stört eher, dass du die Schiene „Wenn ich es nicht mag, soll es> niemand mögen!!k“ zu fahren scheinst, und wirklich krampfhaft versuchst,> es schlechtzumachen;
Das machst du, siehe oben, da habe ich das belegt.
Ich habe lediglich meine Meinung dazu gesagt und jetzt hast du ein
Problem damit, sie zu akzeptieren, auch wenn du in deinem Eingangssatz
gegenteiliges behauptest, so sieht man es hier.
.... [gekürzt]
Jack V. schrieb:
> Trauma vom ersten Start vom Vim, als> du gefangen warst und nicht wieder rausgefunden hattest?
Man wird also, wenn man dir nicht folgt und auch vim nutzt, von dir
persönlich angegriffen und bekommt von dir dann vorgeworfen:
1. ein Trauma zu haben.
2. gefangen zu sein.
Und aus deinen vorherigen Postings:
3. keine Vorstellung zu haben.
4. und mental nicht in der Lage zu sein, es zu erfassen.
"
### ENDE des Zitats.
Du hast also ein Problem damit, dass du zwar Dinge sagst, aber nicht
ernst meinst, denn dein Gesagtes zerstörst du gleich wieder mit
persönlichen Beleidigungen gegen mich, also stimmt es nicht, was du uns
hier weiß machen willst.
Du drehst dich wie ein Wendehals und hast ein grundsätzliches Problem,
wenn du nicht im Recht bist. Man sieht das auch bei deinem Ausweichen
beim Thema das Zehnfingersystem.
>> Jack V. schrieb:>> Nano schrieb:>>> Es bleibt dabei, eine IDE ist für meine Zwecke besser geeignet als dein>>> vim und für Configfiles reicht mir nano.>>> Akzeptiere das endlich.>>>> Wenn du mal lesen würdest, worauf du antwortest, wäre dir aufgefallen,>> dass das für mich vollkommen in Ordnung ist, und ich das mehrfach,>> direkt und eigentlich unmissverständlich so geschrieben habe.
Und dann hast du gleich die Beleidigungen im gleichen Kommentar
hinterhergeschickt, also nein, genau das meinst du nicht, es ist für
dich nicht in Ordnung, dass ich vim nicht nutze.
Wäre es für dich in Ordnung, dann hättest du dir die Beleidigungen
sparen können. Aber da du, wie ich es hier jetzt schon mehrfach
verdeutlicht habe, ein Problem damit hast, wenn man dein geliebtes vim
kritisiert, kommst du auf keinen grünen Zweig. Das Problem liegt hier
also allein an dir.
Selbst in deinem letzten Posting, wo du erneut beteuerst, dass es dir
egal wäre, wenn ich kein Vim nutze, unterstellst du mir, dass ich
generell eine Abneigung gegen Programme mit Lernkurve hätte. AUch das
ist nicht nur eine Lüge wider besserem Wissen, sondern eben schon wieder
ein persönlicher Angriff.
Jack V. du hast also Probleme und du solltest endlich mal lernen damit
umzugehen, das sagte ich dir gestern schon.
Wer sich dauernd selber versichern muss wie elitär er ist, ist es
meistens nicht.
Ein T. schrieb:> Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell:> das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat> man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr> flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese> Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von> Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-)
Walter K. schrieb:> Nano schrieb im Beitrag #>>> "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen>> wird.">> Weshalb sollte man auch vim zerreißen?> Er ist nun mal der genialste Editor - und die, die das nicht begreifen> können … für die gibt es halt Nano
Schreib das mal ins EMACS Forum.
Auf die Reaktionen bin ich gespannt. :)
Nano schrieb:> Jack V. du hast also Probleme und du solltest endlich mal lernen damit> umzugehen, das sagte ich dir gestern schon.
Warte eine Woche. Rufe dann erst den Thread nochmal auf. Guck dir an, wo
überall dein Gastnick drübersteht, was in den Beiträgen steht, und wie
die Diskussion so verlaufen ist. Und dann überlege ganz in Ruhe, auf
wessen Seite die Probleme sein könnten, und wie du sie für dich lösen
kannst.
Wird warm hier, im Tal der verbrannten Zeit – ich fahr’ dann mal wieder
heim. Bis dann o/
Nano schrieb:> Und mit welcher Erweiterung debuggst du deinen Code?
Auch wenn's nicht Vim ist: mit GUD beim Emacs. Mit Fenstern für
Register, Stacktrace, Disassembly und all dem Kram.
Nur, weil du das nicht glauben willst und immer noch so tust, als wären
aktuelle Editoren keine GUIs.
Jack V. schrieb:> Nano schrieb:>> Jack V. du hast also Probleme und du solltest endlich mal lernen damit>> umzugehen, das sagte ich dir gestern schon.>> Warte eine Woche. Rufe dann erst den Thread nochmal auf. Guck dir an, wo> überall dein Gastnick drübersteht, was in den Beiträgen steht, und wie> die Diskussion so verlaufen ist. Und dann überlege ganz in Ruhe, auf> wessen Seite die Probleme sein könnten, und wie du sie für dich lösen> kannst.
Tja, dass du deine Probleme, in Angesicht der genannten und belegten
Beweislage, immer noch nicht erkennen willst, nennt man auch Ignoranz.
> Wird warm hier, im Tal der verbrannten Zeit – ich fahr’ dann mal wieder> heim. Bis dann o/
:dh:
Nano schrieb:> Und das ist jetzt eine Lüge [...]>> [...] ist noch dreister.>> Deine kindische Gegenreaktion ist mal wieder albern. [...]>> Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören> und keinen anständigen Diskurs mit Anstand und Niveau führen könenn.
Ja, die erkennt man wirklich sehr gut.
[Anmerkung des Zitierenden: Die Aussagen wurden etwas umgestellt.]
Ein T. schrieb:> Nano schrieb:>> Und das ist jetzt eine Lüge [...]>>>> [...] ist noch dreister.>>>> Deine kindische Gegenreaktion ist mal wieder albern. [...]>>>> Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören>> und keinen anständigen Diskurs mit Anstand und Niveau führen könenn.>> Ja, die erkennt man wirklich sehr gut.
Fakten darf man nennen.
Er hat nunmal gelogen.
Er war nunmal dreist.
Und seine Gegenreaktion war kindisch.
Alles Fakt und oben steht die Beweislage.
Und ob du auch zur Hass und Pöbelfraktion dazu gehörst, da darf sich
jeder selber ein Bild anhand deiner folgenden Kommentare machen. Ich
habe die Stellen mal fett markiert:
> Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr> (den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt> hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano"> installieren können).
Quelle:
Beitrag "Re: Vi Editor ausgestorben?"> Aber das ist dann eine andere> Nummer als der "vim.tiny" oder der "nano" von dem aggressiven Gast hier.
Quelle:
Beitrag "Re: Vi Editor ausgestorben?"> *Lesen bildet:* [1]. Dein toller nano ist da übrigens nicht aufgeführt.Beitrag "Re: Vi Editor ausgestorben?"> Diese> Stärken wissen Menschen, *deren Fähigkeiten sich im Schubsen von*> *Computermäusen erschöpfen,* natürlich nicht zu schätzen. ;-)Beitrag "Re: Vi Editor ausgestorben?"
Ich schließe mich daher Le X. Kommentar an, denn Recht hat er.
Da schrieb er:
Le X. schrieb:> Wer sich dauernd selber versichern muss wie elitär er ist, ist es> meistens nicht.>> Ein T. schrieb:>> Der Preis dafür ist eine steilere Lernkurve, ähnlich wie bei der Shell:>> das erste Lernen ist mühsamer als für die Klickibuntis, aber danach hat>> man für den Rest seines Lebens ein äußerst leistungsfähiges, sehr>> flexibles, extrem performantes und absolut stabiles Profiwerkzeug. Diese>> Stärken wissen Menschen, deren Fähigkeiten sich im Schubsen von>> Computermäusen erschöpfen, natürlich nicht zu schätzen. ;-)Beitrag "Re: Vi Editor ausgestorben?"
Nano, was ist los mit dir?
Dein Hass gegenüber Vim scheint dich inzwischen ja regelrecht
aufzufressen. Du kochst ja noch mehr als der c-hater, wenn irgendjemand
in seiner Gegenwart den bösen Buchstaben ausspricht =8-o
Und das nur wegen eines Texteditors, den dich kein Mensch der Welt zu
nutzen zwingt?
Ich möchte dir ja nicht zu nahe treten, aber hat dir Bram Moolenaar
vielleicht deine Alte ausgespannt? Entschuldige bitte diesen Gedanken,
aber mir fallen im Moment fast keine anderen Gründe ein, die einen
Menschen so sehr auf 180 bringen können.
Warum bist du überhaupt in diesen Thread eingestiegen. Nach eigener
Aussage benutzt du Eclipse und Nano, weswegen dir Vi(m) doch völlig am
Allerwertesten vorbei gehen kann, oder?
Ich persönlich bin kein Freund von Eclipse, weil dessen Konzept und
Umsetzung nicht meiner Arbeitsweise entsprechen. Trotzdem erkenne ich,
dass viele (auch in meinem Bekanntenkreis) sinnvoll damit arbeiten
können, und käme deswegen nie auf die Idee, einen Kreuzzug gegen diese
Software zu beginnen. Zum einen hätte so eine Aktion für mich keinerlei
persönlichen Nutzen, zum anderen würde ich mich damit wohl ziemlich
lächerlich machen, also lass ich's besser bleiben :)
Geh doch einfach mal nach draußen, iss ein Eis, trink etwas Kühles dazu
und komm nach zwei Stunden wieder zurück. Vielleicht schmunzelst du dann
selber über die komischen Dinge, die du hier in den letzten Tagen von
dir gegeben hast :)
Yalu X. schrieb:> Dein Hass gegenüber Vim scheint dich inzwischen ja regelrecht> aufzufressen
Es ist schon interessant wie unterschiedlich man Diskussionen aufnehmen
kann.
Für mich als Mitleser mit neutraler Haltung zu vim stellt sich der
Sachverhalt ganz anders da.
Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht
so taugt und auch ein paar Sätze als Begründung mitgeliefert.
Ob man seine Ansichten nun teilt oder nicht, aber sein recht harmloser
Kommentar erst hat hier Leute auf den Plan gerufen die man durchaus als
Fanboys betrachten darf und deren Werben um ein dummes Tipp-Tool ich
durchaus als aggresiv bezeichnen würde.
Und ja, deren Argumente waren nicht nur sachlich sondern zielten auch
darauf ab, persönlich einen Stich zu setzen. Und leider hat sich auch
die Moderation nicht erwehren können, mit drauf zu hauen.
Der nano kann halt nicht raus aus seiner Haut. Für ihn ist das wohl
wichtig darzustellen dass nicht er angefangen hat. Ich selber hätt mir
gedacht "dann leckts mich halt am Arsch". Was interessiert schon was ein
paar Leute im Netz denken?
Nichtsdestotrotz, ich hatte meinen Spaß.
Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal
vorstellen ;-)
Rolf M. schrieb:> Aktuell nutze ich das vim-Plugin YouCompleteMe, das eine entsprechende> Funktionalität (kontextsensitive Autovervollständigung, Anzeige von> Funktionsdoku, live-Anzeige von Code-Fehlern während der Eingabe u.s.w.)> für einige Sprachen auch schon ohne Language Server mitbringt.
Ich habe das mal installiert, aber wie aktiviere oder nutze ich das
jetzt?
Le X. schrieb:> Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal> vorstellen
Kannst mal sehen. Ob es in dreißig Jahren sowas mit Eclipse vs. IntelliJ
oder Atom vs. Sublime geben wird? Ich glaube nicht … ;)
Nano schrieb:> Er hat nunmal gelogen.
Eigentlich wollte ich mich nun wieder raushalten, aber bei einer solchen
Unterstellung erwarte ich dann doch schon, dass entsprechende Nachweise
erbracht werden. Und zwar nicht das, was du dir da an wirren
Unterstellungen zusammengedichtet oder was du „interpretiert“ hast,
sondern exakt das Zitat, das objektiv belegt, dass ich gelogen (im
Deutschen steht das für: bewusst die Unwahrheit sagen) hätte.
Bitte keine drei Meter Textwand mit Schwurbeleien auf verschiedenen
Nebenschauplätzen auf drölf Beiträge am Stück verteilt, wie oben – ich
fordere dich hiermit auf, präzise die Unterstellung, ich hätte gelogen,
zu belegen!
Le X. schrieb:> ...> Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht> so taugt und auch ein paar Sätze als Begründung mitgeliefert.>> Ob man seine Ansichten nun teilt oder nicht, aber sein recht harmloser> Kommentar erst hat hier Leute auf den Plan gerufen die man durchaus als> Fanboys betrachten darf und deren Werben um ein dummes Tipp-Tool ich> durchaus als aggresiv bezeichnen würde.> Und ja, deren Argumente waren nicht nur sachlich sondern zielten auch> darauf ab, persönlich einen Stich zu setzen. Und leider hat sich auch> die Moderation nicht erwehren können, mit drauf zu hauen.>> Der nano kann halt nicht raus aus seiner Haut. Für ihn ist das wohl> wichtig darzustellen dass nicht er angefangen hat.
Danke.
So ist es, ich habe eigentlich nur Begründet warum ich vim nicht nutze
und damit konnten die Fanboys nicht umgehen, worauf sie mich dann
persönlich angriffen. Und dann verteidige ich mich und meine Position.
@Yalu X.
Ich bin hier übrigens ganz entspannt.
Nano schrieb:> Ein T. schrieb:> Fakten darf man nennen.
Ja, für alternative Fakten muß man kein Präsident eines Staates sein.
> Und ob du auch zur Hass und Pöbelfraktion dazu gehörst, da darf sich> jeder selber ein Bild anhand deiner folgenden Kommentare machen. Ich> habe die Stellen mal fett markiert:>>> Da benutzt man dann natürlich keinen abgespeckten Krüppel mehr>> (den irgendein Spinner zur Einsparung von 1,5 MB Diskspace abgezwackt>> hat, damit seine Mitspinner einen 2,5 MB großen Editor namens "nano">> installieren können).> Quelle:> Beitrag "Re: Vi Editor ausgestorben?"
Wow, sogar mit Quellenangabe, da hast Du ja fast schon eine
wissenschaftliche Arbeit abgeliefert. Trotzdem bleibe ich bei meiner
Aussage und halte das, was die Debian-Leute da gemacht haben, für
bescheuert: erst "specken" sie einen wohlbekannten und unter allen
UNIXoiden Systemen vorhandenen Editor ab und obwohl er nicht die von den
anderen Versionen bekannten Features besitzt, benennen sie ihn nicht
einmal um: der Name ist derselbe wie beim Original, nur die Features
sind es nicht. Darauf bist ja sogar Du als erklärter Debian-Fanboy
hereingefallen, herzlichen Glückwunsch auch.
Das finde ich schon vollkommen irre, und um die "Einsparung" mal in
$Summe von $Einheit von $Währung zu beziffern, habe ich die überteuerte
NvME SSDPE2KX040T801 von Intel [1] zur Berechnung herangezogen: vier (4)
TB Diskspace für 1009,90 Euro. Wenn man dieses Gerät benutzt und eine
Einsparung von 1,5 MB ansetzt, dann beträgt diese grandiose Einsparung
nicht einmal 0.04 Eurocent. Noch viel bescheuerter wird diese ganze
Nummer aber, wenn dieselben Spinner dann als Alternavive eine Software
installieren, die 2,5 MB groß ist. Ich meine, mal ehrlich: wer macht
sowas, die Kompatibilität willkürlich und völlig sinnlos brechen für
einen Gewinn, der mit "verschwindend" noch sehr wohlwollend benannt ist?
Wie unprofessionell!
Denselben Schwachsinn machen die Debianer ja auch mit der Dash anstelle
der Bash, auch das eine unfaßbar dämliche Entscheidung -- insbesondere
vor dem Hintergrund moderner Versionen mit systemd, wo dieser Austausch
der Shells außer Verwirrung nichts, aber auch rein gar nichts nutzt.
Weißt Du, wir begegnen uns hier ja nicht zum ersten Mal, und tatsächlich
bin ich nach unseren letzten... Gesprächen mehrmals in mich gegangen und
habe sogar Freunde und Kollegen gebeten, die Threads zu lesen und mir zu
sagen, ob es vielleicht an mir läge und ich Dich beleidigt, provoziert,
oder belogen hätte. Aber jetzt stelle ich fest, daß das Problem offenbar
doch nicht bei mir liegt und Du bei anderen, die eine andere Meinung
vertreten als Du, genauso reagierst wie bei mir -- sogar dann, wenn
diese Menschen Dir nicht einmal widersprechen! Sobald eine andere
Ansicht als Deine eigene vertreten wird als Deine, scheinst Du das als
eine persönliche Beleidigung wahrzunehmen, überziehst den oder die
Betreffenden mit endlosen Postings, die aber längst nichts mehr mit dem
Thema zu tun haben und in denen Du Dich auf komplette
Nebensächlichkeiten kaprizierst, dann bezichtigst Du Dein Gegenüber der
Lüge und anderer Böswilligkeiten sogar dann, wenn diese Dir ausdrücklich
gesagt haben, daß niemand Dir Deine Entscheidung madig machen oder Dein
Lieblingsförmchen wegnehmen will. Sei mir bitte nicht wieder böse, aber:
bist Du sicher, daß die Kommunikation in so einem Forum wie diesem Dir
(oder dem Forum) gut tut? Geh' doch mal eine Runde spazieren, hör' ein
bisschen erbauliche Musik, spiel mit dem Hund oder der Katze, hack'
einen Klafter Holz oder tu' etwas anderes, das Dich entspannt.
[1]
https://www.hiq24.de/shop//Intel-SSD-4.0TB-DC-P4510----2.5%22-U.2-PCIe-NVMe-3.1/261264/100/i.html?
Le X. schrieb:> Mir scheint es, nano hat tatsächlich nur mal erwähnt dass ihm vim nicht> so taugt und auch ein paar Sätze als Begründung mitgeliefert.
Naja, sein erstes Posting hier fing an mit:
Nano schrieb:> Gott bewahre!>> Ich benutze lieber eine richtige IDE.
Jack V. schrieb:> Eigentlich wollte ich mich nun wieder raushalten, aber bei einer solchen> Unterstellung erwarte ich dann doch schon, dass entsprechende Nachweise> erbracht werden. Und zwar nicht das, was du dir da an wirren> Unterstellungen zusammengedichtet oder was du „interpretiert“ hast,> sondern exakt das Zitat, das objektiv belegt, dass ich gelogen (im> Deutschen steht das für: bewusst die Unwahrheit sagen) hätte.
Das habe ich alles schon oben belegt.
Die Kurzform ein Beispiel wo du gelogen hast:
Du hast mir unterstellt, dass ich etwas gegen vim und grundsätzlich auch
alle anderen Programme mit steiler Lernkurve hätte, weil es eine steile
Lernkurve hätte und das wissentlich, denn meine Gründe warum ich vim
ablehne war nicht die Lernkurve, sondern die anderen Punkte, die ich
oben bereits angeführt habe und die jeder nachlesen konnte, auch du.
Also hast du wissentlich wider besserem Wissen etwas behauptet, was
nicht stimmt und das nennt man nun einmal eine Lüge.
Raussuchen kannst du die Kommentare im Thread selber, belegt habe ich es
bereits und ich mache mir die Arbeit jetzt nicht noch einmal, nur weil
du nicht willens bist zu lesen.
Nano schrieb:> Also hast du wissentlich wider besserem Wissen etwas behauptet, was> nicht stimmt und das nennt man nun einmal eine Lüge.
Offensichtlich hast du eine andere Definition von Lüge, als ich und die
Leute, die ich kenne, und die Wörterbücher, die ich kenne. Nachdem du
nämlich kenntlich gemacht hast, dass die Lernkurve nicht dein Punkt
wäre, habe ich das kein weiteres Mal angebracht, wie du auch problemlos
selbst feststellen kannst. Es kann daher mitnichten von einer
wissentlichen Falschbehauptung, vulgo „Lüge“, gesprochen werden.
Bitte zeige nun ganz entspannt einen richtigen Beleg für deine
wiederholte Unterstellung auf.
Warum du bei dem Thema derart abgehst, dass du dich derart angegriffen
und verfolgt fühltest, und aus dieser Verteidigungshaltung ein solches
Maß an Textwüste incl. unsachlicher Angriffe produzieren musstest, ist
mir allerdings auch schleierhaft. Ist mir schon klar, dass ich
daraufhin ebenfalls provoziert habe, aber nur davon, dass einem jemand
zeigt, dass bestimmte Aufgaben mit Programm V schneller und bequemer zu
erledigen sind, als mit Programm N, kann man doch eigentlich nicht so
abgehen?
Wie auch immer – wir warten noch auf deinen Weg, wie ›ddp‹ in Nano
umzusetzen wäre.
Yalu X. schrieb:> Und das nur wegen eines Texteditors, ...
Es ist schon irgendwie lustig - eher traurig, wie sich erwachsene
Menschen über 2 Jahre um ein Unix Urgestein wie den vi streiten können.
Der vi, mittlerweile in den Mittvierziger, hatte ganz sicher seine
Daseinsberechtigung, weil er eben wenig Speicher brauchte und auch im
Terminal funktionierte. Für die damalige Zeit ohne Zweifel hervorragend.
Hinzu kam das er halt auf allen *X'en vorhanden war. Dennoch die
Bedienung mit den Tastenkombis, Tasten und die Umschalterei zwischen den
einzelnen Modi ist mehr als gewöhnungsbedürftig, aber gut man kann
(mußte) alles lernen.
Die Zeit ist aber nicht stehen geblieben und ob der Editor nun 200kB
oder 2,5MB belegt ist bei den heutigen Rechnern nun wirklich Rille.
Heutzutage sind grafische Editoren angesagt, die eigentlich keine
Wünsche mehr offen lassen und für die man nicht erst mal Dokumentation
lesen muß, um irgendetwas mach zu können - allein das Beenden des
Editors stellt denjenigen, der das erste Mal den vi benutzt, vor eine
unüberwindbare Hürde.
Klar wer das Teil jahrzehntelang intensiv nutzt und die Funktion jeder
Taste kennt, wird ihn wohl weiter benutzen - es ist für ihn halt die
gewohnte Arbeitsumgebung. Wer neu einsteigt oder umsteigt wird wohl eher
auf einen grafischen Editor setzen und wenn's mal auf der Shell bzw.
remote im ssh-Terminal sein soll dann halt den nano.
Zwischenzeitlich gibt es aber auch grafische Editoren, zumindest unter
Win (z.B. PSPad), mit denen man auch per SFTP sehr komfortabel auf dem
Remotesystem arbeiten kann - man sitzt quasi am Remoterechner. Keine
Ahnung ob es so etwas auch für Linux gibt, könnte mir das aber durchaus
vorstellen.
Ansonsten stimme ich Lex zu, wenn er schreibt:
Le X. schrieb:> Nichtsdestotrotz, ich hatte meinen Spaß.> Ein Editor-War in 2022, vim vs. nano, das muss man sich erst mal> vorstellen ;-)
Man kann eigentlich seinem ganzen Beitrag nur zu stimmen.
Jack V. schrieb:> Nano schrieb:>> Also hast du wissentlich wider besserem Wissen etwas behauptet, was>> nicht stimmt und das nennt man nun einmal eine Lüge.>> Offensichtlich hast du eine andere Definition von Lüge, als ich
Die Definition einer Lüge ist juristisch definiert als eine unwahre
Tatsachenbehauptung wider besserem Wissen.
Beides muss erfüllt sein, sowohl dass die Tatsachenbehauptung unwahr
ist, als auch, dass sie wider besserem Wissen geäußert wird.
Beides war bei dir erfüllt.
Anders wäre es, wenn ich im Thread nicht erwähnt hätte, warum ich vim
ablehne, dann wäre es zwar immer noch eine unwahre Tatsachenbehauptung
seitens dir, aber noch keine wider besserem Wissen.
Da du aber den Grund kanntest, da er ja im Thread stand und lesbar für
alle war, war es eine Tatsachenbehauptung wider besserem Wissen.
> Warum du ... ein solches> Maß an Textwüste incl. unsachlicher Angriffe produzieren musstest,
Siehe oben, du hat mich angegriffen, nicht anders herum.
> Wie auch immer – wir warten noch auf deinen Weg, wie ›ddp‹ in Nano> umzusetzen wäre.
Steht oben, das hatte ich dir schon letztes mal gesagt, als du ein
zweites mal gefragt hast, jetzt fragst du ein drittes mal. Du solltest
halt meine Antworten auch mal lesen.
Jack V. schrieb:> Kannst mal sehen. Ob es in dreißig Jahren sowas mit Eclipse vs. IntelliJ> oder Atom vs. Sublime geben wird? Ich glaube nicht … ;)
Nö, da sind die längst über holt und es gibt was Neues. Ob das dann
besser ist sei mal dahin gestellt.
Dennoch werden sich die Hardcoreunixer immer noch mit dem Rest der Welt
über den vi/vim streiten. Ist halt so - jedem Tierchen sein Pläsierchen.
Darf ja auch jeder gern halten wie er mag.
Jack V. schrieb:> Ist wie in der Psychologie: der Patient muss es von sich aus wollen,> sonst wird es nichts.
Naja, nicht so ganz. Man denke an eine Schlaganfallselbsthilfegruppe.
Die wollen normalerweise auch trainieren, haben aber oft eher unpassende
Trainer, und so keine Motivation. Und ohne Motivation läuft nix. (!)
Mit den reden bringt auch nicht viel, die argumentieren dann in etwa so:
so eine linke (oder rechte) Hand braucht man doch eigentlich gar nicht.
Unabhängig davon und darüber hinaus hier:
Kognitive Dissonanz
Ich finde die Unterscheidung zwischen "Sichtbar" und "Unsichtbar" eher
etwas untreffend.
Tatsächlich geht es um Bedienung, und die kann man sowohl intern
(sichtbar vs sichtbar) wie auch außen (unsichtbar vs unsichtbar)
unterscheiden wie auch (sichtbar vs unsichtbar)
Die muss aber oft jeder selbst entscheiden. Den TX16W Sampler von Yamaha
hatten früher viele schnell wieder veräußert, wegen der komplizierten
Bedienung. Ich fand die nicht so schlimm, ich hatte mich eher über die
Möglichkeiten gefreut.
Die sehr gute Emu Emax2 Bedienung konnte man dem nicht ansehen. Aber man
konnte darüber in Fachzeitschriften lesen. Ohne aber zu wissen, wie das
gemeint war. Die Bedienung musste man "erfahren", um zu erkennen, wie
gut die tatsächlich ist.
Ausdrucksstärke ist für mich eher ein Begriff für Kunst, mit Bezug auf
Können.
Ansonsten: Was ist eigentlich der Unterschied zu "Klickibunti"?
Tastaturhengst, Konsolerator, Autist, oder sowas in der Art?
Notepad hat seinen Charme, aber der ist halt - bewiesenermaßen - für
einige Leute nicht erkennbar.
Früher hatte ich eine andere Haltung, da dachte ich über Notepad, so ein
popelding, und freute mich über so ein tolles Programm wie Editpad.
Man sollte unter Linux nicht davor zurückschrecken, Notepad über Wine
aufzurufen.
Aber extra für Notepad Wine zu installieren, das ist natürlich Quatsch.
Zeno schrieb:> Nö, da sind die längst über holt und es gibt was Neues.> […]> Dennoch werden sich die Hardcoreunixer immer noch mit dem Rest der Welt> über den vi/vim streiten.
Das wären dann siebzig Jahre (von vi in seinen Vierzigern ausgehend, wie
von dir selbst geschrieben wurde). Spricht schon irgendwie für solide
Software, oder? ;)
Nano schrieb:> Beides war bei dir erfüllt.
Davon, dass du’s gebetsmühlenhaft wiederholst, wird es nicht wahrer. Du
kannst keine Lüge belegen, weil keine da war – und damit hat es sich.
Nano schrieb:> Steht oben, das hatte ich dir schon letztes mal gesagt, als du ein> zweites mal gefragt hast, jetzt fragst du ein drittes mal. Du solltest> halt meine Antworten auch mal lesen.
Ja – tut mir leid, ist tatsächlich in den Buchstabenwüsten
untergegangen.
Strg-k und Strg-u also, ja? In einem grad eigens zum Testen
installierten Nano löscht das die aktuelle Zeile und fügt sie an der
gleichen Stelle wieder ein. Das ist nicht, was ›ddp‹ macht; das
entspräche ›ddP‹
Weil ich das Ding grad schon mal installiert habe:
Nano schrieb:> In Nano:> Cursor in Zeile platzieren.> ALT + G> STRG + T> " eingeben + Enter drücken> 1 cursor nach rechts> ALT + A = Markerung gesetzt> ALT + G> STRG + T> " eingeben + Enter drücken> STRK + K
funktioniert bei mir auch nicht. GNU nano, Version 6.3
Jack V. schrieb:> funktioniert bei mir auch nicht. GNU nano, Version 6.3
Bei mir auch nicht. Ich wollte aber nicht kleinlich sein und habe das
Problem erst einmal für mich behalten, um die Diskussion nicht weiter
anzuheizen.
Yalu X. schrieb:> Bei mir auch nicht. Ich wollte aber nicht kleinlich sein und habe das> Problem erst einmal für mich behalten, um die Diskussion nicht weiter> anzuheizen.
Auf meiner Fedora Installation ging das mit di" auch nicht. Auf der
alten FullBlown Kali-Version in der VM aber schon.
Insofern war das Beispiel vielleicht nicht so glücklich gewählt.
Ich fand es mal sehr verfänglich, dass man z.B. gruseligen Java-Code in
einem Rutsch sehr viel netter aussehen lassen kann.
Aber das mit dem Modewechsel, den 7Js, 5dws usw. oder versehentliche
Vertipper vermeiden, das braucht seine Zeit. Man muss ja auch einen
gewissen Blick entwickeln, welche Werte passen, welcher Workflow fließt,
und das geht halt nicht von heute auf morgen, oder mal eben in 30 Min.
Nano schrieb:> ThomasW schrieb:>>> ...Einfach Mal>> über den Tellerrand schauen!>> Ich glaube ja, das nur jene gegen Vim (und Emacs) wettern, denen die>> Disziplin fehlt um ihn zu lernen. Denn das ist tatsächlich mühsam!>> Zum Glück glaubst du das nur, eine Behauptung wider besserem Wissen wäre> nämlich eine Lüge.> Ganz oben habe ich ja bereits erklärt, dass vim an der Debugger> Integration gescheitert ist.> Das impliziert, dass ich mich mehrere Tage mit vim beschäftigt habe.> Und dann haben wir hier die Hass und Pöbelfraktion, die nicht wahrhaben> will, dass und warum man vim ablehnt. Die Argumente und Begründungen> stehen sogar dabei, aber die Pöbelfraktion verhält sich halt wie ein> kleines Kind.> Getreu dem Motto> "Darf ja nicht sein, dass vim, das eigene Lieblingsspielzeug, zerrissen> wird."
Das ist der Teil aus meinem Post der dir am wichtigsten war? Wow!
Wenn du meinen ganzen Beitrag gelesen hättest, dann hättest du
vielleicht auch verstanden warum es überhaupt keine Debugger-Integration
in einen Texteditor braucht. Das ist in meinen Augen ohnehin der falsche
Ansatz. Man kann nämlich einfach den Vim als Plugin in IDEs nutzen. Dann
hast du deinen Debugger ohne grosses Theater!
Jack V. schrieb:> Nano schrieb:>> Beides war bei dir erfüllt.>> Davon, dass du’s gebetsmühlenhaft wiederholst, wird es nicht wahrer. Du> kannst keine Lüge belegen, weil keine da war – und damit hat es sich.
Ich glaube inzwischen, dass du hier nur trollst.
> Strg-k und Strg-u also, ja? In einem grad eigens zum Testen> installierten Nano löscht das die aktuelle Zeile und fügt sie an der> gleichen Stelle wieder ein. Das ist nicht, was ›ddp‹ macht; das> entspräche ›ddP‹
Du willst also zwei Zeile vertauschen?
Das ist zumindest das was ddp macht, ja?
Nichts leichter als das, du gehst an den Anfang der Zeile und drückst
STRG + K
Cursor runter
STRG + U
In Kate geht das übrigens noch einfacher.
Einfach Shift + STRG Taste gedrückt halten und Cursor Taste nach unten,
fertig. Das geht sogar mit ganzen Zeilen, einfach mehrere Zeilen
markieren und dann wie gerade beschrieben.
> Nano schrieb:>> In Nano:>> Cursor in Zeile platzieren.>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> 1 cursor nach rechts>> ALT + A = Markerung gesetzt>> ALT + G>> STRG + T>> " eingeben + Enter drücken>> STRK + K>> funktioniert bei mir auch nicht. GNU nano, Version 6.3
Die 1 steht NICHT für die 1 Taste, sondern bedeutet ein cursor runter.
Und am Ende ist das STRK nur ein Tippfehler, es sollte STRG heißen.
Nano schrieb:> Nichts leichter als das, du gehst an den Anfang der Zeile und drückst>> STRG + K> Cursor runter
Wozu mit dem Cursor an den Zeilenanfang? Es reicht wenn der Cursor in
der gewünschten Zeile steht. Nach dem Ausschneiden hüpft er dann
automatisch auf den Zeilenanfang.
Nano schrieb:> Ich glaube inzwischen, dass du hier nur trollst.
Komisch, geht mir bei dir auch so: Du erinnerst dich – es ging bei
diesen Beispielen überhaupt gar nicht darum, ob man die Aufgabe im
Nano mit Tastatur und Maus ebenso erledigt bekommt, denn das sollte bei
Textbearbeitungsaufgaben in einem Editor immer der Fall sein. Es ging
darum, es mit vergleichbarem Aufwand und in vergleichbarer Zeit zu
erledigen. Und darum, dass deine aufgezeigten Wege da eigentlich nur
eines zeigen: geht nicht. Das sollte dir eigentlich selbst aufgefallen
sein, wenn du die Dreibuchstabenfolgen mit deinen Konstrukten da
vergleichst. Und das waren eher triviale Sachen, wie du ja wohl wissen
wirst, wenn du dich, wie du behauptet hast, tatsächlich soweit mit Vim
beschäftigt hast, um das einschätzen zu können.
Mal ganz objektiv jetzt: di" habe ich in ca. 0,5s geschrieben, und dabei
die Hände kaum bewegt. Wie lange brauchst du für deine Strg-Orgie?
Nano schrieb:> Nichts leichter als das, du gehst an den Anfang der Zeile und drückst
Sind immer noch fünf Tasten und man muss die die Handstellung wechseln,
um die Cursortasten zu erreichen. Aber stimmt, war ein eher schlechtes
Beispiel. Ich mach mal ein Neues: angehängt findest du eine Textdatei,
bei der jede Zeile mit einem . beginnt, der in jeder Zeile entfernt
werden soll. Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei
in einer Kombination und eine Buchstabentaste, und bin entsprechend in
weniger als einer Sekunde durch.
Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen?
Wieviel Zeit?
Jack V. schrieb:> Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen?> Wieviel Zeit?
Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das
macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Jack V. schrieb:> Ich mach mal ein Neues: angehängt findest du eine Textdatei, bei der> jede Zeile mit einem . beginnt, der in jeder Zeile entfernt werden soll.> Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei in einer> Kombination und eine Buchstabentaste, und bin entsprechend in weniger> als einer Sekunde durch.
Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5
Zeichen: :%s/^\.//g
Freue mich auf deine Lösung!
sepp schrieb:> Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das> macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Ungefähr fünf Minuten mit der Suchmaschine meines geringsten
Misstrauens, und es kommt häufiger vor, dass ich in mehreren
zusammenhängenden Zeilen untereinanderstehende Zeichen löschen, oder an
diesen Stellen Zeichen einfügen möchte. Gerade wenn man an Configs
rumschraubt, ist das ziemlich oft überaus praktisch und zeitsparend –
gerade deswegen habe ich es mir ja mal angeeignet, und ich hab die fünf
Minuten seither hundertfach wieder reingeholt – falls du darauf
hinauswolltest.
ThomasW schrieb:> Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5> Zeichen: :%s/^\.//g
Ja, das wäre der zweite Weg, der mir einfiele. Hab aber einen Fehler
gemacht: fünf Tastenbetätigungen waren es beim Einfügen der Punkte beim
Erstellen der Beispieldatei. Zum Löschen reichen vier: Strg+v (für
Visual Block Mode), G (für Cursor in letzte Zeile) und x (für löschen).
Wobei es bei deiner Variante mit der Ersetzung egal wäre, wo sich der
Cursor zum Anfang befindet, bei meiner Variante ging ich vom frischen
Aufruf der Datei mit Cursor am Anfang der ersten Zeile aus – ansonsten
wäre der halt noch dort zu positionieren (je nach Variante bis zu drei
Tastendrücke zusätzlich: ^gg).
Die Benutzung von vi(m) ist eine Philosophie, eine Lebenseinstellung,
ein Lebensinhalt, absolute Hingabe, ein Selbstzweck um Probleme zu lösen
die man sonst nicht hätte, eine Herausforderung.
Vielleicht etwa vergleichbar mit einem Leistungssport.
Nano schrieb:> Als Editor war mir Emacs zu groß
Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch
viel RAM waren, ist schon lange vorbei.
Anscheinend ist zu diesem Thema wirklich schon alles gesagt worden.
Nur halt nicht von jedem.
Hinzu kommt, das in gefühlt 90% der Antworten (wenn man sie denn
überhaupt so nennen mag) gar nicht auf die Frage eingegangen wird,
sondern in Internet-üblicher Art und Weise auf völlig belangloses
anderes Zeug hingewiesen wird.
Korrektur. Nicht nur hingewiesen, sondern geradezu anders denkenden
aufgezwungen wird.
Es geht hier aber nicht um völlig belangloses anderes Zeug, es geht hier
um den vi editor.
Und es geht wohl auch um die Frage warum er selbst nach Jahrzehnten
immer noch von einer riesigen Schar sehr gerne und sehr häufig benutzt
wird.
Aber ich gestehe gerne zu, das diese Erkenntnis zumindest eine
rudimentäre Lese- und Verständnisfähigkeit voraus setzt.
ThomasW schrieb:> Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5> Zeichen: :%s/^\.//g
Wenn ich das richtig sehe sind das ja regular Expressions, was aber nun
kein Alleinstellungsmekrmal des vi/vim ist. Diese (regular Expressions)
nutzen einem aber auch nur dann etwas wenn man die im Kopf hat. Dazu
kommen noch die unzähligen Befehle des Editors die man sich merken muß.
Wenn man das alles nicht Kopf hat und erst nachschlagen muß, dann ist
man mit dem nano oder jedem beliebigen graphischen Editor wahrscheinlich
schneller, selbt dann wenn man zwei Tasten mehr drücken oder die Maus
bemühen muß.
Zudem kommt es bei mir eher selten vor das ich in einem Text hunderte
Zeichen an gleicher Position entfernen/ersetzen muß.
(prx) A. K. schrieb:> Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch> viel RAM waren, ist schon lange vorbei.
Dafür wird hier aber rum gemosert das der nano ja so viel Speicher
braucht, wohingegen der vi ja so sparsam ist.
Dafür braucht der vi halt jede Menge biologischen ROM und da sind wir
dann schon beim Rick:
Rick schrieb:> Die Benutzung von vi(m) ist eine Philosophie, eine Lebenseinstellung,> ein Lebensinhalt, absolute Hingabe, ein Selbstzweck um Probleme zu lösen> die man sonst nicht hätte, eine Herausforderung.> Vielleicht etwa vergleichbar mit einem Leistungssport.
Besser kann man es nicht auf den Punkt bringen.
Zeno schrieb:> Dafür wird hier aber rum gemosert das der nano ja so viel Speicher> braucht, wohingegen der vi ja so sparsam ist.
Du solltest dich aber schon ’n bisschen am tatsächlichen Verlauf
orientieren, um dich nicht völlig unglaubwürdig zu machen: es wurde
zunächst „rumgemosert“, dass vim ja soviel Speicher brauchen würde und
daher Bloatware sei, wohingegen nano ja so sparsam wäre.
(prx) A. K. schrieb:> Nano schrieb:>> Als Editor war mir Emacs zu groß>> Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch> viel RAM waren, ist schon lange vorbei.
Wobei der vim auch schon ordentlich zu gelegt hat. Sieh dir mal die
neuste Version an.
Jack V. schrieb:> Du solltest dich aber schon ’n
Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt.
Jack V. schrieb:> um dich nicht völlig unglaubwürdig zu machen
Wenn Du meinst - Deine Meinung ist mir da so ziemlich Rille.
Viel peinlicher hier ist, wie einige ihr Lieblingsspielzeug verteidigen.
Das hat ja schon religiöse Züge.
Zeno schrieb:> Viel peinlicher hier ist, wie einige ihr Lieblingsspielzeug verteidigen.> Das hat ja schon religiöse Züge.
Ist in der Tat schon erschreckend, wenn jemand den Nano so anbetet, dass
er sich selbst danach benennt, und schon bei der kleinsten Andeutung,
dass ein Job in einem anderen Programm vielleicht einfacher und
effizienter erledigt werden könnte, so durchdreht.
Zeno schrieb:> Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt.
Natürlich nicht – ich nehm’ dich sowieso nicht mehr ernst, selbst, wenn
du jetzt anfangen würdest, dich an der Realität zu orientieren.
Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich
die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung
deiner anderen Beiträge sein kann.
sepp schrieb:> Jack V. schrieb:>> Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen?>> Wieviel Zeit?>> Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das> macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Eigentlich nicht viel, denn es sind selbstverständlich nicht 500
komplett von einander losgelöste Kommandos, sondern diese sind logisch
aufgebaut, so dass man sich, wenn man das Prinzip mal kennt, leicht
komplexere Kommandos aus einfacheren zusammenstellen kann. Ab einem
gewissen Grad erschließen sich sehr viele Kommandos von selbst.
ThomasW schrieb:> Jack V. schrieb:>> Ich mach mal ein Neues: angehängt findest du eine Textdatei, bei der>> jede Zeile mit einem . beginnt, der in jeder Zeile entfernt werden soll.>> Ich drücke im Vim insgesamt fünf Tasten, davon zweimal zwei in einer>> Kombination und eine Buchstabentaste, und bin entsprechend in weniger>> als einer Sekunde durch.>> Bin ja selbst intensiver Vim-Nutzer, aber ich brauche mehr als 5> Zeichen: :%s/^\.//g>> Freue mich auf deine Lösung!
Da es ja eigentlich nur darum geht, das erste Zeichen jeder Zeile zu
entfernen, würde ich das so machen: Ctrl+v, dann Shift+g, dann d. Wenn
man Ctrl und Shift mit einrechnet, sind das 5 Tastendrücke.
Zeno schrieb:> Wenn man das alles nicht Kopf hat und erst nachschlagen muß, dann ist> man mit dem nano oder jedem beliebigen graphischen Editor wahrscheinlich> schneller, selbt dann wenn man zwei Tasten mehr drücken oder die Maus> bemühen muß.
Man kann natürlich auch mit vim arbeiten, ohne sämtliche Kommandos im
Kopf zu haben. Dann braucht man eben an manchen Stellen auch mehr
Tastendrücke.
> Zudem kommt es bei mir eher selten vor das ich in einem Text hunderte> Zeichen an gleicher Position entfernen/ersetzen muß.
Der Punkt ist eben, dass man, wenn man sich mit vim auskennt, auch
schnell ein Kommando findet, mit dem man recht einfach eine Bearbeitung
machen kann, die vielleicht nicht so oft vorkommt, aber bei anderen
Editoren schnell umständlich werden kann.
Das hier ist vielleicht ein recht spezieller Fall, aber mir laufen des
öfteren mal spezielle Fälle unterschiedlichster Art über den Weg.
Rolf M. schrieb:> Da es ja eigentlich nur darum geht, das erste Zeichen jeder Zeile zu> entfernen, würde ich das so machen: Ctrl+v, dann Shift+g, dann d. Wenn> man Ctrl und Shift mit einrechnet, sind das 5 Tastendrücke.
Diese Lösung ist cool! Kam weiter oben schon und ich merke, dass ich den
visualmode zu wenig nutze. Dafür ganz automatisch was ich schon beim sed
so oft genutzt habe ;-)
Ich finde es spannend, dass in den letzten wenigen Jahren immer mehr
deutschsprachige Videos auf Youtube zu vim aufgetaucht sind. Es scheinen
also auch wieder mehr junge Leute Gefallen an vim zu finden. Hat
wahrscheinlich auch etwas mit Nostalgie und Coolnessfaktor zu tun. Wenn
man Interesse an solchen Sachen hat und jeden Tag mehrere Stunden einen
Editor braucht, kann die Einarbeitung in vim sicher lohnend sein und
auch Spaß machen. Für Gelegenheitsnutzer ist es aber eher nichts. Die
haben die kryptischen Befehle dann schneller wieder vergessen als sie
sie gelernt haben.
Zeno schrieb:> Nano schrieb:>> Nichts leichter als das, du gehst an den Anfang der Zeile und drückst>>>> STRG + K>> Cursor runter> Wozu mit dem Cursor an den Zeilenanfang? Es reicht wenn der Cursor in> der gewünschten Zeile steht. Nach dem Ausschneiden hüpft er dann> automatisch auf den Zeilenanfang.
Oh, ja, da hast du natürlich recht.
Bei dem anderen Beispiel kann man bei der zweiten Zeile mit
1
" eingeben + Enter drücken
kann man das " sogar weglassen, da es bereits als Vorschlag in der
Klammer steht.
Somit verkürzt sich das auf:
Jack V. schrieb:> Wieviele Tastendrücke benötigst du in Nano, diese . zu entfernen?> Wieviel Zeit?
So ein weltfremdes Beispiel kommt in der Realität bei mir nicht vor.
Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell
mit awk.
Wenn es nur ein paar Zeilen sind, kann es auch sein, dass ich Kate öffne
und einfach die Blockauswahl dafür nutze. Die erlaubt spaltenweises
auswählen, also anders als das klassische Markieren.
Jack V. schrieb:> Gerade wenn man an Configs> rumschraubt, ist das ziemlich oft überaus praktisch und zeitsparend –> gerade deswegen habe ich es mir ja mal angeeignet, und ich hab die fünf> Minuten seither hundertfach wieder reingeholt – falls du darauf> hinauswolltest.
Also wenn es dir nur um das Entfernen von Kommentarzeichen geht, nano
bietet das Entfernen oder Setzen von Kommentarzeichen mit der Taste ALT
+ 3 an.
Wenn man die Zeilen vorher markiert, gehen auch mehrere Zeilen auf
einmal.
Das gesetzte Kommentarzeichen wird hierbei abhängig vom Dateityp
gesetzt.
Default ist #, bei bspw. C >= C99 und C++ Code werden stattdessen //
gesetzt.
(prx) A. K. schrieb:> Nano schrieb:>> Als Editor war mir Emacs zu groß>> Die Zeit, als jene 8 MB RAM, denen der EMACS seinen Namen verdankt, noch> viel RAM waren, ist schon lange vorbei.
Das mag sein, aber gerade wenn ich nur kleine Configdateien bearbeiten
will oder mal von der Bash aus kurz eine Notiz in eine TXT Datei
schreiben will, dann nehme ich dafür einen Editor der schnell geöffnet
und geladen ist und den man dann auch, weil er so schnell wieder da ist,
ohne Planungsängste, dass er zum Öffnen wieder Zeit kostet, auch gleich
wieder schließen kann.
Diese Aufgaben erfüllt nano, aber auch Notepad, gedit oder kate. Bei den
letzten beiden sollten die dafür notwendigen Bibliotheken, also GTK oder
QT dann allerdings schon im RAM geladen sein. Und das ist dann wiederum
ein Grund, warum ich den auf Desktopebene eingesetzten Editor dann
abhängig davon mache, welches Desktop Environment ich gerade nutze.
Bei KDE (qt basiert) ist es somit, wenn es nicht nano von der shell aus
ist, immer Kate (auch qt) und bei Mate (gtk basiert) ist es pluma
(gedit, gtk basiert).
Unter Windows führt das dann sogar dazu, dass ich dort Notepad++ anstatt
bspw. Geany (wäre GTK basiert) bevorzuge. Denn Notepad++ nutzt direkt
die WinAPI und ist damit auch sehr schnell geladen. Geany müsste erst
einmal die GTK Lib Laden, das dauert mir zu lange. Gut, heute in Zeiten
von SSDs ist das nicht mehr so deutlich zu spüren, aber früher, bei
Festplatten war das ein sehr wichtiger Punkt.
Das nutzen verschiedener Editoren ist hier auch kein Problem, da alle
diese Editoren sich von selbst erschließen, da sie ja intuitiv sind.
Nano habe ich allerdings überall installiert, auch unter Windows. Und
bei den heutigen Linux Distris, die ich nutze, ist nano ohnehin per
default immer dabei.
Und beim Programmieren wofür ich dann eine richtige IDE nehme, ist das
sowieso anders, die IDE starte ich Morgens und schließe sie wieder
Abends. Da sind mir die Ladezeiten relativ egal.
Der "Blitz" Faktor eines Editors ist mir also wichtig.
Nano schrieb:> So ein weltfremdes Beispiel kommt in der Realität bei mir nicht vor.
Ja, das Beispiel ist konstruiert – aber nicht, weil sowas in der Art in
der Realität nicht vorkäme, sondern um es einfach und nachvollziehbar zu
halten.
Schreib doch einfach, dass die Aufgabe mit Nano nicht sinnvoll zu lösen
ist, statt Gründe zu suchen, warum man das ja überhaupt nicht brauchen
würde. Ist halt nicht sein Gebiet, damit ist nichts verkehrt.
Ist nur schade, dass du nicht benennen möchtest, welches Problem du
eigentlich mit Vim hast. Die oben geäußerte Vermutung mit dem Trauma war
natürlich nicht ernst gemeint – aber irgendwas muss diesem irrationalen
Zwang ja zugrunde liegen, aus dem du so krampfhaft zu zeigen versuchst,
dass Nano mindestens genauso leistungsfähig wäre und dabei selbst solche
offensichtlichen Absurditäten bringst, wie die Behauptung, deine
Strg-Orgie in Nano wäre mindestens genauso effizient, wie die drei
Tastendrücke im Vim, oder dass man statt fünf Tastendrücken doch einfach
’nen fully bloated Qt-Editor hochreißen und mit der Maus rumstochern
sollte.
Nano schrieb:> Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell> mit awk.
Und bevor ich für so einen trivialen Job den Editor verlasse, den
Awk-Aufruf zusammenschreibe und auf die Datei loslasse, um sie dann
wieder im Editor zu öffnen und weiterzumachen, drücke ich halt meine
fünf Tasten im Editor. So what?
coolman schrieb:> Ich finde es spannend, dass in den letzten wenigen Jahren immer mehr> deutschsprachige Videos auf Youtube zu vim aufgetaucht sind. Es scheinen> also auch wieder mehr junge Leute Gefallen an vim zu finden.
Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem
Jahre 1990.
Scheint mir aber trotzdem eine akademische Erscheinung zu sein. Ich kann
mir kaum vorstellen, dass vim in der Industrie viel genutzt wird. Das
gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an
Universitäten und Forschungseinrichtungen. Selbst an Fachhochschulen
kennt man das nicht. Ich war vor 20 Jahren der einzige, der damit seine
Diplomarbeit geschrieben hat. Als Editor hatte ich übrigens emacs. Alle
anderen Leute hatten Word genommen.
3.14 schrieb:> Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem> Jahre 1990.> Scheint mir aber trotzdem eine akademische Erscheinung zu sein.
Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen
auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen
oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und
verbinden zu müssen. Es gibt Kollegen die wechseln nun zu Neovim. Aber
ich kann nicht bestätigen, dass es weniger geworden wäre.
3.14 schrieb:> Das> gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an> Universitäten und Forschungseinrichtungen.> [...] Ich war vor 20 Jahren der einzige, der damit seine> Diplomarbeit geschrieben hat.
Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs
Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor
allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei
größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen
Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem.
In nicht-Forschungs Firmen hast du andere Tools bzw. PR-Abteilungen
welche die Dokumente für dich "schön" machen.
Nano schrieb:> Kommentarzeichen
A propos Kommentare: Wenn man einen längeren Kommentaren editiert (etwas
hinzufügt oder löscht), sieht dieser hinterher meist ziemlich zerfranst
aus.
Beispiel:
1
/*
2
* Lorem ipsum
3
* dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
4
* eirmod tempor invidunt
5
* ut labore et dolore magna aliquyam erat, sed diam
6
* voluptua.
7
*
8
* At vero eos et
9
* accusam et justo duo dolores et ea rebum. Stet clita kasd
10
* gubergren, no sea takimata sanctus est
11
* Lorem ipsum dolor sit amet.
12
*/
13
14
intmain(void){
15
return0;
16
}
Statt die Zeilen mühevoll manuell zu verbinden, neu umzubrechen und die
Sternchen dabei wieder an die richtige Stelle zu setzen, kann man in Vim
auch einfach gqap eingeben oder alternativ den neu umzubrechenden
Ausschnitt des Kommentars markieren und gq eingeben. Danach sieht der
Kommentar wieder aufgeräumt aus:
1
/*
2
* Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
3
* eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
4
* voluptua.
5
*
6
* At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd
7
* gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
8
*/
9
10
intmain(void){
11
return0;
12
}
Das funktioniert natürlich auch bei Kommentaren mit // oder #.
Rolf M. schrieb:> Der Punkt ist eben, dass man, wenn man sich mit vim auskennt, auch> schnell ein Kommando findet, mit dem man recht einfach eine Bearbeitung> machen kann, die vielleicht nicht so oft vorkommt, aber bei anderen> Editoren schnell umständlich werden kann.
Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022
haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt
wurden.
Hast du schon einmal in das Menü von bspw. Notepad++ geguckt?
Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer
jemals brauchen wird.
Nano schrieb:> Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022> haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt> wurden.
Süß … du weißt aber schon, dass der Thread mit einer Info zu einem neuen
Major-Release vom Vim wieder ins Leben gerufen worden ist, und dass
Major-Releases üblicherweise ein Zeichen für Weiterentwicklung sind?
Frag ja nur – bei dir liest’s sich so, als wäre die Entwicklung vor
dreißig Jahren eingeschlafen.
Nano schrieb:> Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer> jemals brauchen wird.
Nein.
Johannes O. schrieb:> Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen> auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen> oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und> verbinden zu müssen.
Aber für diesen Zweck braucht man doch nicht so ein kompliziertes
Werkzeug wie vim. Da reicht auch ein nano, der ebenfalls überall
installiert ist.
Jack V. schrieb:> Ist in der Tat schon erschreckend, wenn jemand den Nano so anbetet ...
Ja kann man so sehen. Aber Mein Gott, es gibt Schlimmeres und ob der
Nick wirklich vom gleichnamigen Editor herrührt weis nur der Nano
selbst.
Viel erschreckender finde ich da hingegen Leute, die sich sofort
angepisst fühlen, wenn man bezüglich ihrer Lieblingsspielzeuge, egal OS,
Programme (z.B. vi/vim) oder what ever, eine andere Meinung vertritt als
sie selbst. Das hat schon eher was Religiöses bzw. Sektenhaftes.
Jack V. schrieb:> ich nehm’ dich sowieso nicht mehr ernst
Das beruht dann wohl auf Gegenseitigkeit. Leute die ihre Werkzeuge
verteidigen wie eine Wölfin die Jungen, kann man eh nicht wirklich ernst
nehmen.
Jack V. schrieb:> Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich> die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung> deiner anderen Beiträge sein kann.
Da können die Mitleser aber wirklich froh sein das Du ihnen jetzt ein
Werkzeug in die Hand gibst, mit dem sie meine Beitäge ordentlich
bewerten können. Hoffentlich sind sie von soviel Erleuchtung nicht
geblendet.
Du hast wirklich keine anderen Probleme.
Jack V. schrieb:>
> Ist nur schade, dass du nicht benennen möchtest, welches Problem du> eigentlich mit Vim hast. Die oben geäußerte Vermutung mit dem Trauma war> natürlich nicht ernst gemeint
Wie schon gesagt, du musst einfach auch mal den Thread lesen. Das setzt
natürlich Leseverständnis voraus.
Also nochmal kurz für dich, für Configdateien und kurzen Notizen werde
ich kein Vim üben, weil ich da für das Bisschen keine leistungsfähigen
Editorfeatures brauche und da wo es interessant werden könnte, nämlich
beim Programmieren, da versagt er gegenüber einer IDE bei der
Debuggerintegration.
Warum soll ich mir das dann also antun?
Oben habe ich eine Frage gestellt zu diesem youcompleteme. Anstatt die
Frage mal zu beantworten, suchst du wieder Streit.
Und anstatt ne Vim Config mit Debuggerübersicht zu liefern, was ich ja
als Kritikpunkt erwähnt habe, machst du mit deinen persönlichen
Angriffen nur so weiter, und das nicht nur vorgestern und gestern,
sondern auch heute schon wieder. Wie das Kommentar auf Zeno zeigt, ich
habe deine heutigen persönlichen Angriffe wieder fett markiert:
Jack V. schrieb:> Ist in der Tat schon erschreckend, wenn jemand den *Nano so anbetet,* dass> er sich selbst danach benennt, und schon bei der kleinsten Andeutung,> dass ein Job in einem anderen Programm vielleicht einfacher und> effizienter erledigt werden könnte, *so durchdreht.*>> Zeno schrieb:>> Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt.>> Natürlich nicht – *ich nehm’ dich sowieso nicht mehr ernst,* selbst, wenn> du jetzt anfangen würdest, dich an der Realität zu orientieren.>> Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich> die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung> deiner anderen Beiträge sein kann.
Quelle:
Beitrag "Re: Vi Editor ausgestorben?"
All das zeigt, Jack V., du hast ein Problem mit dir selbst und das haben
hier schon viele erkannt und dir versucht mitzuteilen, aber du willst
nicht daraus lernen. Auch wurde dir bereits gesagt, dass dein Verhalten
fanatisch religiöse Züge annimmt, was man in der Tat so unterschreiben
kann, aber auch das bringt dich nicht zum Umdenken, du machst gerade so
weiter fanatisch radikalisiert alle anzugreifen, die vim nicht nutzen
wollen und bspw. andere Editoren haben, mit denen sie die genannten
Problemstellungen lösen können. Und wenn sie dir dann sagen, wie sie mit
den anderen Editoren diese Probleme lösen, insbesondere deine von dir
gestellten Aufgaben, dann passt es dir nicht dass es mit den anderen
Editoren auch geht und du greifst sie wieder an, was dein obiges
Kommentar eindrucksvoll zeigt.
Und auch hier, man achte mal auf die unsachlichen Wertungen und Wörter
in deiner Antwort. Ich habe sie ebenso nochmal fett hervorgehoben:
Jack V. schrieb:>
> – aber irgendwas muss diesem *irrationalen*> Zwang ja zugrunde liegen, aus dem du so krampfhaft zu zeigen *versuchst,*> dass Nano mindestens genauso leistungsfähig wäre und dabei selbst solche> offensichtlichen Absurditäten bringst, wie die Behauptung, deine> Strg-Orgie in Nano wäre mindestens genauso effizient, wie die drei> Tastendrücke im Vim, oder dass man statt fünf Tastendrücken doch einfach> ’nen fully bloated Qt-Editor hochreißen und mit der Maus *rumstochern*> sollte.
Wir haben hier also als Liste:
- irrationale Zwang
- krampfhaft
- Absurditäten
- Orgie
- fully bloated
- hochreißen
- rumstochern
Und das alles wieder bespickt mit deinen religiös getriebenen Vorwürfen,
wie dass ich krampfhaft versuchen würde dir zu beweisen, dass nano
genauso leistungsfähig wäre wie dein vim.
Dabei muss ich das nicht (Anmerkung: wie du weißt, nutze ich nano für
Configs und einfache Sachen) und war auch gar nicht der Fall, sondern du
hast mich gefragt, wie man dies und jenes Problem in nano lösen kann und
ich habe es dir lediglich beantwortet.
Und die Antwort, dass das mit nano geht, das ist das, was dich in deinem
reliögsen Wahn so stört und auf die Palme bringt, die gefällt dir nicht,
vermutlich weil du davon dein vim angegriffen fühlst, in das du so viel
Zeit und Aufwand reingesteckt hast und dann können andere ähnliche
Probleme ohne nennenswerten Aufwand lösen und deswegen greifst du nun
wieder, wie man es oben sehen kann, persönlich an und unterstellst mir
wieder einen Zwang und sonstiges krampfhaftes Verhalten.
Und das ist nicht nur bei mir so, denn auch Zeno hast du angegriffen.
Womit wir wieder bei der Erkenntnis sind, das du ein Problem mit dir
selbst hast und daran arbeiten solltest.
> Nano schrieb:>> Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell>> mit awk.>> Und bevor ich für so einen trivialen Job den Editor verlasse, den> Awk-Aufruf zusammenschreibe und auf die Datei loslasse, um sie dann> wieder im Editor zu öffnen und weiterzumachen, drücke ich halt meine> fünf Tasten im Editor. So what?
Wen interessiert was du machst? Du hast mich gefragt, wie ich das
löse und ich habe dir die Antwort gegeben. Und daraus machst du jetzt
wieder ein Problem.
Genau das, was ich oben gerade beschrieben habe. Niemand will wissen,
wie du deine Probleme mit vim löst, keiner hat dich gefragt und auch du
wurdest nicht gefragt, denn deine Frage hast du nicht an dich selbst
gestellt, sondern an mich gestellt, aber das was du anderen hier
vorwirfst, dass die krampfhaft versuchen würden, ihren Editor zu
verteidigen, das machst du hier selbst mit deinem vim.
Das sieht man hier deutlich, wenn ich dir sage, dass ich eine solche
Aufgabe mit awk löse und du dann ungefragt und krampfhaft darauf
hinweisen musst, warum vim besser sei als das CLI Tool awk sei und das
obwohl dich keiner danach gefragt hat. Dieses krampfhafte Wettstreit vim
gegen den Rest der Welt, der entsteht ausschließlich in deinem Kopf.
Also guck mal in den Spiegel und schließe nicht immer von dir auf
andere.
Johannes O. schrieb:> Es gibt Kollegen die wechseln nun zu Neovim.
Worin liegt eigentlich der Unterschied zwischen Vim und Neovim?
Was macht Neovim anders?
Wer kann die Frage objektiv und sachlich (Jack V., du bist nicht
gefragt) beantworten?
Ich glaube oben wurde schonmal "unterstützt das Language Server
Protokoll out of the box", erwähnt, aber wie geht es weiter?
Nano schrieb:> Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022> haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt> wurden.
Das erste, was ich auf einem neuen System baue, ist ein File .vimrc mit
"syntax off" darin, damit ich das Zeug noch lesen kann. Irgendein
komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten
in einem dunklem Rot vor schwarzem Hintergrund zu verstecken. Sowie zu
Neuheiten. ;-)
Wie schon jemand oben benutze ich vi/vim seit zig Jahren, aber praktisch
nur im Kontext von Systemtechnik, nicht als Programmierplattform. Da ist
es ziemlich Banane, ob vi, vim oder neovim. Man kann das also trennen.
Ernsthafte Programmierung läuft anders ab. Und vi* ist halt drauf.
Nano schrieb:> Das mag sein, aber gerade wenn ich nur kleine Configdateien bearbeiten> will oder mal von der Bash aus kurz eine Notiz in eine TXT Datei> schreiben will, dann nehme ich dafür einen Editor der schnell geöffnet> und geladen ist
Ja, das geht mir auch so. Deswegen nehme ich für solche (wie auch für
alle anderen) Dinge Vim. Der erste Start dauert im Textmodus 0,2s im
Grafikmodus unter X11 1,2s. Das ist zwar etwas länger als bei Nano oder
Vi, aber diesen Zeitnachteil habe ich beim Editieren ganz schnell wieder
aufgeholt :)
> und den man dann auch, weil er so schnell wieder da ist, ohne> Planungsängste, dass er zum Öffnen wieder Zeit kostet, auch gleich> wieder schließen kann.
Beim wiederholten starten von Vim (egal ob im Text- oder Grafikmodus)
ist praktisch kein Zeitverzug erkennbar (also <0,1s).
3.14 schrieb:> Johannes O. schrieb:>> Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen>> auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen>> oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und>> verbinden zu müssen.>> Aber für diesen Zweck braucht man doch nicht so ein kompliziertes> Werkzeug wie vim.
Natürlich wäre es Unfug, sich nur für das Editieren von Config-Dateien
in Vim einzuarbeiten. Wenn man aber Vim sowieso schon kennt, weil man
ihn auch für andere Dinge einsetzt, wäre es fast genauso unsinnig, sich
in Nano einzuarbeiten, selbst wenn dort die Einarbeitung nur eine
Viertelstunde dauert.
Nano schrieb:> Worin liegt eigentlich der Unterschied zwischen Vim und Neovim?> Was macht Neovim anders?
Neovim wird von einer Community ziemlich offen entwickelt und ist daher
deutlich agiler in der Entwicklung, als Vim, bei dem die Entwicklung in
einer einzelnen Person zusammenläuft. Das hat unter Anderem zu nativem
SLP-Kram geführt, und auch dazu, dass zum Scripten Lua zum Einsatz
kommen kann. Daneben gibt es noch eine Latte an Details, die alle
aufzuführen hier nicht zielführend sein wird.
Nano schrieb:> Jack V., du bist nicht> gefragt
Interessiert mich nicht. Sachliche Fragen bekommen sachliche Antworten –
im Gegensatz zu dem, was du dir einzubilden scheinst, habe ich nichts
gegen dich. Deine komische Textwüste weiter oben, mit den wilden
Vermutungen und Unterstellungen, bei gleichzeitigen
Rechtfertigungsversuchen der eigenen Irrationalität – naja, da sehe ich
mich wirklich nicht mehr gefragt. Das ist mir dann doch zu absurd :)
(prx) A. K. schrieb:> rgendein> komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten> in einem dunklem Rot vor schwarzem Hintergrund zu verstecken.
background=dark als Konfigurationsoption ist bekannt?
Nano schrieb:> nano> bietet das Entfernen oder Setzen von Kommentarzeichen mit der Taste ALT> + 3 an.
Oh, das kannte ich noch nicht. Bei Bashscripten und C-Files funktioniert
es perfekt.
Beim Mac muß man übrigens Shift+Option+3 drücken.
Jack V. schrieb:> background=dark als Konfigurationsoption ist bekannt?
Das Kernproblem sind nicht die Farbspiele diverser Tools, sondern meine
Gene. Ist bei LEDs nicht anders, jenen, die für rund 90% der männlichen
Bevölkerung gebaut sind und vom Rest verflucht werden.
Nano schrieb:> Denn Notepad++ nutzt direkt> die WinAPI und ist damit auch sehr schnell geladen.
Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile
bevorzuge ich da aber PSPad. Bei diesem kann man links eine
Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem
anderen Rechner verbinden und durch dessen Verzeichnisstruktur
navigieren.
Jack V. schrieb:> Schreib doch einfach, dass die Aufgabe mit Nano nicht sinnvoll zu lösen> ist, statt Gründe zu suchen, warum man das ja überhaupt nicht brauchen> würde. Ist halt nicht sein Gebiet, damit ist nichts verkehrt.
Tja bei Dir ist es genau anders herum. Du konstruierst eben einfach
etwas, um nachzuweisen das es ohne Dein Lieblingsspielzeug nicht geht.
Johannes O. schrieb:> Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs> Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor> allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei> größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen> Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem.
Ich habe mich lange Zeit mit LaTeX schwer getan. Wenn ich allerdings
eine richtig ordentliche Dokumentation erstellen will, dann benutze ich
das mittlerweile gern, weil man ein ordentliches in sich konsistentes
Ergebnis erhält.
sepp schrieb:> Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das> macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es
einigermaßen beherrscht?
Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um
statt in der Kreisklasse in der Verbandsliga zu spielen?
Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen,
wenn einem mal langweilig ist:
https://www.youtube.com/watch?v=KuLy5LzHEzU
(Kommentare dazu lesen, ist auch gar nicht so schlecht)
rbx schrieb:> Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es> einigermaßen beherrscht?
Hast du schon versucht, eine derart komplizierte Tätigkeit in einem
Alter zu erlernen, in dem du bereits lesen konntest? Vielleicht geht es
sogar leichter, wenn man es nicht kann. ;-)
rbx schrieb:> Wieviele Stunden muss man ein Tischtennisbuch lesen, um> statt in der Kreisklasse in der Verbandsliga zu spielen?
Gar keines, da muß man nur üben bis der Arzt kommt. Und ja ein bissel
Talent wird wohl auch dabei sein.
Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus
wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch
beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu
verändern.
Etwas vergleichbar mit dem Tastendruck R,
nachdem man den vi mit -b gestartet hat.
Ich konnte da in der Hilfe nichts finden…
rbx schrieb:> Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es> einigermaßen beherrscht?
gar keins
rbx schrieb:> Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um> statt in der Kreisklasse in der Verbandsliga zu spielen?
vermutlich auch keines, man braucht nur viel Übung.
Aber du willst doch die Bedienung eines Editors hoffentlich nicht als
Selbstzweck sehen wie ein Sportler seine Sportart?
rbx schrieb:> Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen,> wenn einem mal langweilig ist:> https://www.youtube.com/watch?v=KuLy5LzHEzU
Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es
mitlerweile einiges.
3.14 schrieb:> Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es> mitlerweile einiges.
Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da
oben?
Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens
einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber
ganz schön ein.
Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv)
auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht
allzugroße Sorgen machen.
Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff
open:MINT) kann man doch noch verstehen oder?
Zeno schrieb:> Nano schrieb:>> Denn Notepad++ nutzt direkt>> die WinAPI und ist damit auch sehr schnell geladen.> Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile> bevorzuge ich da aber PSPad. Bei diesem kann man links eine> Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem> anderen Rechner verbinden und durch dessen Verzeichnisstruktur> navigieren.
Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7
auf 10) von PSPad zu Notepad++ gewechselt.
Der Grund war allerdings nur, weil ich Notepad++ mal ausprobieren wollte
und das geht am besten, in dem man ihn installiert und die anderen
Editoren nicht zur Verfügung hat. Also habe ich PSPad nicht installiert
und Notepad++ ist jetzt halt drauf.
Gefehlt hat bis jetzt nichts, anderseits mache ich meine Arbeitssachen
überwiegend nur noch unter Linux, weswegen ich unter Windows kaum dazu
komme, da einen Editor zu benötigen. Deswegen habe ich den da einfach
drauf gelassen.
Norbert schrieb:> Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus> wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch> beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu> verändern.
Keine Ahnung, aber ich habe das auch nie gebraucht und unter DOS, wo man
das per EINF Taste einstellen konnte, hat mich so etwas immer gestört.
Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.
Das ist grob der 14-15 fache Speicherplatz im RAM.
Und der dreifache CPU Resourcen Verbrauch.
Macht nano da etwas ganz Besonderes?
Wie lautete die Eingangsfrage noch gleich…
(prx) A. K. schrieb:> Norbert schrieb:>> Macht nano da etwas ganz Besonderes?>> Er ist bloss neuer, von 1999 statt 1991, und konnte sich das leisten.
Stimmt. Neuer is' besser. Sieht man doch… ;-)
Norbert schrieb:> Wie lautete die Eingangsfrage noch gleich…
Die lautet:
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vim? [...]> Wenn nein, warum nicht?
Und die hat nano eigentlich gemäß der Fragestellung beantwortet, seitdem
sieht er sich aber starken Missionierungstendenzen ausgesetzt.
Und da er selber auch etwas schwierig ist, die Fanboys nicht ignorieren
kann sondern das letzte Wort haben muss sind wir nun wieder in einer
Diskussion angekommen die zusammen mit dem usenet eigentlich in der
Versenkung hätte verschwinden sollen.
Nano schrieb:> Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7> auf 10) von PSPad zu Notepad++ gewechselt.
Der Notepad++ ist schon klasse. Der bietet alles was man braucht. Gerade
wenn man an großen Projekten arbeitet mit vielen Dateien und
Verzeichnissen arbeitet hat das Teil schon seine Stärken, z.B. Suchen
und Ersetzen in allen göffneten Dateien oder auch im gesamten
Verzeichnis.
Auskommentieren von Zeilen oder ganzen Bereichen passend zum geöffneten
Dateityp funktioniert natürlich auch.
Also ich nehme das Teil immer noch sehr gerne. Da ich derzeit an meinem
Wetterserver und der zugehörigen Homepage arbeite kommt mir aber die
FTP-Funktionalität des PSPad sehr gelegen. Der bietet zwar nicht die
Vielfalt wie Notepad++, ist aber für meine aktuellen Arbeiten völlig
ausreichend.
Le X. schrieb:> Norbert schrieb:>> Wie lautete die Eingangsfrage noch gleich…> Die lautet:> Openbsd schrieb:>> Arbeitet von euch noch jemand mit dem vim? [...]>> Wenn nein, warum nicht?
Le.X: Warum lügst du so dreist?
Und ja, eine Auslassung wesentlicher Teile kommt einer Lüge gleich!
Hier die wahre Fragestellung:
> Arbeitet von euch noch jemand mit dem vi?> Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?> Wenn nein, warum nicht?
Da nano nicht mit vim arbeitet sind die von mir im Zitat mit [...]
ersetzten Fragen nicht relevant, erst die letzte wieder.
Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den
Buckl runterrutschen, da musst dir 'nen andren suchen.
Le X. schrieb:> Da nano nicht mit vim arbeitet sind die vob mir mit [...]> ersetzten> Fragen nicht relevant, erst die letzte wieder.>> Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den> Buckl runterrutschen, da musst dir 'nen andren suchen.
Ich würde die Wahrheit jetzt nicht als Wortklauberei bezeichnen.
Das mag für dich und deine ›gefühlte Wahrheit‹ natürlich durchaus so
sein. So lebt halt ein jeder in seiner Welt.
So grob kann man den Vi und auch Vim mit der guten Bedienung vom Emu
Emax2 vergleichen. Beim Emax2 wird man gewissermaßen mit leichter Gewalt
dazu gezwungen, gleich von Anfang an Multisamples zu erstellen.
Das hört sich furchtbar an, ist es aber nicht, weil man sonst Gefahr
läuft, zu einer Art Samplefragment-Messi zu verkommen, und das behindert
die Kreativität auch ganz schön, trotz der freien Zuordnung, die man
aber später noch ausrichten muss.
Beim Vi wie auch beim Vim wird man in ähnlicher Weise dazu gezwungen,
eine "alte" aber bewährte Tastaturbedienung zu lernen. Das ist dann aber
eher analog zum Minimoog. Und meinen konnte ich damals recht günstig
bekommen, weil viele Leute irrtümlich dachten, das wäre der letzte
Schrott von Gestern.
Wer den Minimoog kennt, der weiß auch, dass das Improvisieren mit dem
Ding einen Riesenspaß machen kann.
rbx schrieb:> Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da> oben?> Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens> einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber> ganz schön ein.> Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv)> auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht> allzugroße Sorgen machen.>> Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff> open:MINT) kann man doch noch verstehen oder?
Sach mal was hast du denn geraucht?
Argwohn gegen Unis? Nur weil ich gesagt habe, dass nur dort vi und LaTeX
benutzt wird und eher nicht in der Industrie? Gehts noch? Und wo habe
ich geschrieben, dass ich kein Englisch kann? Und wenns so wäre, ginge
es dich auch nichts an. Und ja das Hörverstehen ist bei mir
verbesserungswürdig und mit Prosa von Shakespeare tue ich mich auch
etwas schwer. Wenn du unbedingt Streit suchst, bist du bei mir an der
falschen Adresse. Da mache ich nicht mit und antworte dir Streithahn
einfach nicht mehr. Hast wohl selber noch keine höhere Lehranstalt von
innen gesehen, was?
3.14 schrieb:> Sach mal was hast du denn geraucht?
Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich
geschmacksbefreit allerdings, da fragt man sich, ob das früher zur
Zichorienzeit (als Kaffeeersatz) auch schon so fade geschmeckt hatte.
Und wenn wir schon dabei sind. Ich stehe nicht sonderlich auf
Plattitüden, oder sich absichtlich sehr dumm stellen.
Wenn man Pflanzen, Kräuter oder Blumen bestimmen oder besser,
unterscheiden muss, hilft nicht immer ein Buch weiter, dafür aber die
Nase.
Auch dieses wurde uns abgewöhnt, obwohl es (das Erschnuppern) für die
Menschen früher überlebenswichtig war, und oft auch schwierige Dinge
ganz einfach macht.
rbx schrieb:> Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich> geschmacksbefreit allerdings,
Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt
nennt?
(prx) A. K. schrieb:> Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt> nennt?
Und dann auch noch von einem bestimmten Unternehmen..
Tatsächlich hatte ich nicht viel erwartet. Aber Reformhäuser sind bei
uns im Kreis alle weg, auch im größeren Bereich. Ich dachte schon daran,
Hoffnung in eine etwas höhere Qualität zu setzen. Bevor ich mein Glück
bei einer Apotheke versuche, könnte ich noch schauen, ob man bei uns in
einer Supermarktecke mit Allnatura-Produkten noch etwas anständige(er)s
erwischen kann.
Aber die Geruchswelt von damals wird schon noch eine andere gewesen
sein, teilweise wohl auch deswegen, weil die Leute auch oft hungern
mussten, und soviel Fleisch wie heutzutage auch nicht auf den Tisch kam.
Gibt es eigentlich in Wien in diesen Kaffeehäusern guten
Zichorienkaffee? Bzw. gibt es die Kaffeehäuser überhaupt noch? Die
kleine Kneipe gibt es bei uns schon lange nicht mehr.
Und wo früher unser recht großer Dorfsupermarkt war, ist jetzt (in den
alten Supermarkträumlichkeiten) ein großes Beerdigungsinstitut.
Walter K. schrieb:> Nano schrieb:>> …>> Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.>> LOL
Wieso LOL?
Das ist nunmal die Aufgabe eines Hexeditors, der ist für Binärdateien
da.
Ein normaler Editor muss nur Text können, denn er heißt nunmal
Texteditor und nicht Binäreditor.
Falls du das bspw. nicht weißt, aber ein UTF-8 Zeichen kann bis zu 4
Bytes lang sein. In der Textansicht im Editor steht da also nur 1
solches Zeichen, das intern aber 4 Bytes groß ist.
Im Hexeditor sieht man jedes der 4 Byte.
Manche Texteditoren erlauben es auch in den Hexeditormodus umzuschalten,
dann kannst du das auch auf Binärebene ändern, während die Daten dann in
Hexansicht und daneben in normaler Zeichenansicht angezeigt werden. Das
ist aber kein muss für einen Texteditor so etwas zu können.
Norbert schrieb:>
> Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:>
1
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+
2
> Command
3
> 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi
4
> XXX
vi oder vim?
350 MiB sind für vi ziemlich viel, wenn man bedenkt, dass er aus einer
Zeit stammt, als die Rechner weniger RAM hatten als die Disketten
Speicherplatz boten.
Da musste man also noch direkt auf Disketten operieren können, weil man
längere Textdateien gar nicht ins RAM bekam.
Hat sich das jetzt bei vi verschlechtert? Eine Rückentwicklung?
Nano wurde später entwickelt, da hatte man schon üppig RAM zur Verfügung
und dicke Bücher, wie bspw. die Bibel konnte man bereits komplett in das
RAM laden. Da war bereits das direkte Arbeiten auf dem Datenträger keine
Anforderung von Editoren mehr.
Nano schrieb:> vi oder vim?
vi ist bei debian ein symlink (über Umwege) auf vim. Also ja, es ist
natürlich vim dahinter.
Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend
nicht mehr unter den Fingerkuppen. Selbst in Debian Hamm (die Älteren
werden sich erinnern) war schon vim drin.
Also, hmm, vi? Könnte Sinix oder Xenix oder SCO gewesen sein. Ganz
sicher aber auf dem UNIX einer Perkin-Elmer.
> 350 MiB sind für vi ziemlich viel,
Ja, schon. Der Traditionelle hat sich immer nur ein Häppchen genommen.
Aber der Punkt ist ein anderer:
5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp
80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das
lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung
erklären. Oder einer massiv fehlerhaften Implementation. Der
Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300%
der Zeit braucht.
Norbert schrieb:> Aber der Punkt ist ein anderer:> 5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp> 80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das> lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung> erklären. Oder einer massiv fehlerhaften Implementation. Der> Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300%> der Zeit braucht.
Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der
Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch
auf eine 3,5 DD Diskette passen.
Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im
Arbeitsspeicher (Windows Taskmanager).
Das Installationsprogramm von gvim verbraucht auch nicht unbedingt viel
mehr Speicherplatz, so 10 MB. Vieviel Speicher der jetzt nach der
Installation belegt, oder wieviel Arbeitsspeicher im Betrieb, kann ich
nicht sagen, aber allzuviel mehr wird das auch nicht sein.
https://www.vim.org/download.php
Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich
bei der "Recherche" schon ein wenig schmunzeln:
https://superuser.com/questions/938093/nano-alternative-for-windows-powershellhttps://nano-editor.org/dist/win32-support/
Norbert schrieb:> Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend> nicht mehr unter den Fingerkuppen.
Die gibt's auch kaum noch, weil der vi-Sourcecode lange Zeit nicht als
Opensource verfügbar war. So haben die BSDs halt schon vor 30 Jahren auf
nvi gesetzt, der sich zwar vom feature set weitgehend am Original
orientiert (außer dass man im Insert-Mode mit den Cursortasten
navigieren kann ;-) aber eben trotzdem ein Rewrite ist.
rbx schrieb:> Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der> Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch> auf eine 3,5 DD Diskette passen.> Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im> Arbeitsspeicher (Windows Taskmanager).
Die Anzeigen bezüglich der RAM-Belegung:
Da kann ich mit 100% Sicherheit einen Fehler ausschließen.
Sowohl ›top‹ als auch ›htop‹ als auch die graphische Systemüberwachung
sind sich da einig. Da gab's auch noch nie Probleme.
Vielleicht war ich aber auch etwas unklar:
Der nano belegt die zig-zig-zig-fache Menge an Speicher.
Der vi verhält sich hingegen tadellos.
Norbert schrieb:> Ich habe hier eine gerade mal 64MiB große Textdatei.> ...> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command> 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi XXX> ...> 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX
Das sieht schon heftig aus, allerdings kann ich das bei mir nicht ganz
nachvollziehen:
1
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2
8778 yalu 20 0 164M 98M 18648 S 0.0 1.7 0:00.23 vim big1
Die Zahlenwerte sowohl für RES als auch für TIME sind also deutlich
kleiner als bei dir. Der Speicherverbrauch hängt aber auch etwas vom
Inhalt der Datei ab.
Die Datei big1 enthält 1048576-mal die Zeile
Ich verwende vim ganz gerne. Allerdings brauche ich nur ein kleines
Subset der Features, das kann man in 15 Minuten lernen. Im Laufe der
Zeit habe ich immer mehr Kürzel vergessen...
Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features
nicht gut funktionieren, wie finden der Funktionsdefinition oder
debuggen. Auch gibt es keine einfache Projektverwaltung.
Und schlimmer: man kann mit keiner IDE mehr arbeiten, wenn man die vim
Kürzel erst mal gewohnt ist...
Der vim ist aber auch ein Code-Monster mit schlechter Doku und mehr
Sourcecode Zeilen als der Emacs und grauslicher Script Sprache. Dazu
Bloat ohne Ende, aber OK - er funktioniert und stürzt nicht ab, die
Windows Integration ist sehr bescheiden.
Norbert schrieb:> head -c64M /dev/zero | tr "\000" "\n" >XXX
Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :)
Nano scheint also in seiner internen Datenrepräsentation einen riesigen
zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte
bei Vim).
Norbert schrieb:> Der nano belegt die zig-zig-zig-fache Menge an Speicher.> Der vi verhält sich hingegen tadellos.
Nicht nur das: den Vi oder gvim oder neovim usw. gibt es auch für
Windows, reichlich problemlos.
Der Watcom-Compiler hatte bei dem Übersetzungsversuch der Nano-Quellen
trotz mehrerer Versuche und Ansätze mit zigfachen Fehlermeldungen
abgebrochen.
Da ist man wohl tatsächlich besser dran, wenn man erstmal ein minimales
Cygwin (s.o.) für nano nutzt.
(abgesehen davon, dass der VMware Player auch so ein tolles Programm
ist)
(Früher konnte man bei Cygwin eine Art Fullinstall machen, die maximale
Menge war 4 GB.
Aktuell gibt es bis zu 150 GB an Software, da muss man sich vor dem
Installieren dann wohl auf Empfehlungen verlassen. Früher hatte ich nur
den Compiler als Programm, das brauchte auch nicht viel Speicher, also
eher vergleichbar mit dem, was heute typischerweise mit MinGW-Setups
läuft.)
Yalu X. schrieb:> Norbert schrieb:>> head -c64M /dev/zero | tr "\000" "\n" >XXX>> Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :)>> Nano scheint also in seiner internen Datenrepräsentation einen riesigen> zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte> bei Vim).
Und das da oben ist noch eine ›Spielzeugdatei‹
Hatte - blauäugig wie ich bin - mal eine unserer echten Messreihen mit
›nano‹ geöffnet. Die braucht normalerweise gerade mal 20 Sekunden zum
öffnen. (Für 180E6 Zeilen, ~4GB)
Konnte gerade noch schnell genug ein zweites Terminal aufmachen und bei
ca. 20GiB RAM Nutzung ein freundliches kill -9 an den ›nano‹ senden.
Noch bevor die wilde Swap-Orgie starten konnte.
Wäre aber sicherlich gut für eine autoexec.bat oder config.sys zu
gebrauchen… (Nee ich nehme das zurück, das war böse)
Stefan ⛄ F. schrieb:> Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir> im Büro> für Java EE Anwendungen.
Möchte jemand anderes AHA sagen, oder soll ich das machen?
rbx schrieb:> Der vi verhält sich hingegen tadellos.
Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den
Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.
Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM
für eine Bildschirm-Seite braucht...
udok schrieb:> Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den> Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.
müsste man man schauen, was neovim diesbezüglich macht. Beim Watcom-Vi
hatte ich eine ca 30 MB große Pdf Datei geladen - Speicherverbrauch des
ganzen lag bei 32 MB.
Wenn man allerdings eine Pdf im Reader läd, und dann auf den Taskmanager
schaut, dann grabscht sich dieser Reader eine ganze Menge Speicherplatz
selbst nach dem Beenden.
Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus
bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als
dieser grottige Dos-Editor Edlin.
Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf
die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe
übersehen müssen.
rbx schrieb:> Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich> bei der "Recherche" schon ein wenig schmunzeln:>> https://superuser.com/questions/938093/nano-alternative-for-windows-powershell
Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Ich selbst installiere immer Git for Windows, da ist er dann neben der
Bash und weiteren wichtigen Tools automatisch dabei und das wurde auch
in deinem Link vorgeschlagen.
https://gitforwindows.org/
Bei der Lösung über den Chocolatey package manager fehlte bei meiner
letzten Recherche vor ein paar Jahren über Chocolatey noch das Vertrauen
in die Pakete, weil es damals dort keinerlei Signierung gab. Keine
Ahnung ob das inzwischen besser gelöst ist.
>> Nochmal getestet, Werte bleiben etwa gleich.
Was du da produziert hast, ist vieles, aber keine Textdatei, wie du
anfangs behauptet hast.
Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles
modifiziert, was kein Teil einer Textdatei ist.
Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner.
Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine
Arbeit. Für Binärdateien nimm einen Hexeditor, wie ich es anfangs schon
sagte.
udok schrieb:> Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features> nicht gut funktionieren, wie finden der Funktionsdefinition oder> debuggen. Auch gibt es keine einfache Projektverwaltung.
Die Erfahrung habe ich auch gemacht, deswegen habe ich mich mit vim
damals nicht mehr weiter beschäftigt und vim nach ca. 1 Woche Testzeit
zu den Akten gelegt.
Und für Configs brauch ich vim nicht, die sind so klein, da komme ich
mit jedem Editor zurecht. Aber das sagte ich schon.
udok schrieb:> rbx schrieb:>> Der vi verhält sich hingegen tadellos.>> Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den> Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.>> Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM> für eine Bildschirm-Seite braucht...
4 Byte pro Zeichen sprechen für eine interne Unicode UTF-32
Verarbeitung. Etwas anderes würde ich bei neuen Editoren nicht erwarten.
Früher wären es UTF-16, also 2 Byte pro Zeichen gewesen.
Was nano betrifft, hätte ich neben der ebenfalls UTF-32 Verarbeitung
noch folgende Vermutung:
Möglicherweise wird bei nano beim Laden eine Wörterbuchsuche mit
Zeilennummern angelegt, das würde dann die Suche beschleunigen, aber
auch die notwendige Datenmenge im RAM erhöhen. Also nichts
weltbewegendes.
rbx schrieb:> Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus> bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als> dieser grottige Dos-Editor Edlin.
EDLIN.COM wurde ab MS-DOS 5.0 ja durch EDIT.EXE ersetzt und DR DOS hatte
schon von Anfang an mit EDITOR.EXE einen besseren Editor als EDLIN.COM
im Programm.
> Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf> die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe> übersehen müssen.
Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen
intuitiven Editoren auch bereits pico zur Verfügung.
Und pico hat meistens gegen joe gewonnen, so war es auch bei mir.
nano kam dann später und hat pico ersetzt.
Und nano hatte keine lizenzrechtlichen Fragen mehr und war kurze Zeit
später so beliebt, dass er in allen gängigen Distributionen
vorinstalliert wurde.
Yalu X. schrieb:> Nano schrieb:>> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du>> anfangs behauptet hast.> $ file XXX> XXX: ASCII text
Ich habe schon mal mit sort und uniq eine mehrere GB große Wörterliste
sortiert und auf einen Eintrag pro Wort begrenzt, so sollte es sein, mit
kleiner Datenmenge habe ich die Kommandos auch vorher entsprechend
getestet, aber das Ergebnis war etwas ganz anderes.
Entweder sort oder uniq haben sich herhaspelt, d.h. die Wörter kamen
immer noch doppelt vor, und deswegen glaube ich nicht, dass eine pipe
und tr die richtige Vorgehensweise ist um sehr große Binärdatei zu
bearbeiten.
Nano schrieb:> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du> anfangs behauptet hast.
Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht.
Gut, kann man ein bisschen als corner case ansehen.
Statistik nach dem Laden der Datei (Ubuntu):
1
VSZ RSS
2
vi: 350496 343320
3
nano: 5252636 5246748
4
Emacs (GUI): 790164 129796
5
Emacs (TUI): 289072 100728
Emacs ist vorsichtig und fragt lieber erstmal nach, ob er so eine große
Datei denn wirklich laden soll. ;-)
Aber da dir die Daten ja nicht gefallen haben, probieren wir es mit
einer Menge an 5stelligen Zufallszahlen:
1
$ jot -r 11500000 10000 99999 > XXX
2
$ wc XXX
3
11500000 11500000 69000000 XXX
Sind jetzt ein paar MB mehr als vorher, aber nur noch 11,5 Millionen
Zeilen.
1
VSZ RSS
2
vi: 129808 122972
3
nano: 908136 902160
4
Emacs (GUI): 792220 131716
5
Emacs (TUI): 290920 102700
Nano steht jetzt deutlich besser dar als im pathologischen Fall von nur
Newlines, aber es fällt immer noch auf, dass er praktisch fast den
gesamten allozierten VM einmal "anfasst", sodass er komplett auch als
resident set im Speicher benutzt wird. vi(m) macht das auch, aber auf
deutlich niedrigerem Niveau, bei Emacs ist eine große Differenz (viel
mehr VM angefordert als tatsächlich erstmal benutzt). vi(m) gewinnt
ebenfalls gegenüber dem pathologischen Fall, Emacs zeigt keine
nennenswerten Unterschiede.
[Edit: einige Aussagen korrigiert, die offensichtlich inkorrekt waren.]
Nano schrieb:> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du> anfangs behauptet hast.
Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte
bedarf.
> Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles> modifiziert, was kein Teil einer Textdatei ist.
Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten
prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile.
> Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner.
Du meine Güte… ehrlich jetzt?
> Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine> Arbeit.
Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du
verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen
absondern.
Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen
Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich
völlig überfordern.
Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt
mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor
er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt).
Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für
Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro
Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen,
dann ist das kein Grund panisch zu reagieren. Das ist unser
Tagesstandard.
Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen
dauert länger. Einen Glitsch in den Messdaten beseitigen,
Fingerschnippen.
Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch.
Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei.
Vielleicht noch ein kleiner Tipp: Nicht immer den eigenen Horizont als
Maßstab für alles andere nehmen. Nur weil man selbst nur mit Dateien in
Spielzeuggröße zu tun hat, bedeutet das nicht automatisch das alle
anderen das auch tun.
Ich verweise nochmal auf die ursprüngliche Frage und die Antwort lautet:
Man nimmt den vi für Aufgaben denen kaum ein andere Editor gewachsen
ist.
Die bewältigt er mit Bravour.
Und darum wird er auch nicht aussterben!
Aus hoffentlich offensichtlichen Gründen kann ich hier keine Messdaten
zur Verfügung stellen. Ein Upload einer 3.8GB TEXTDATEI würde vermutlich
nicht gerne gesehen.
Aber bau dir ruhig selber eine, genau so ist das Format: VORSICHT 3.8GB
1
#!/usr/bin/python3
2
importsys
3
importrandom
4
N=4*3600*10000# Vier Stunden lang, 100µs pro Messung
Speichernutzung geht von ~7GB auf ~12GB
Ladezeit: knapp 18 Sekunden
die Eingabe von 100000000<Enter> springt zur 100 Millionsten Zeile in
einem Wimpernschlag.
Jörg W. schrieb:> Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht.> Gut, kann man ein bisschen als corner case ansehen.
Könnte man einzeln betrachtet so sehen, aber es dient auch nur dazu zu
zeigen das nano enorme Probleme hat wenn es um richtige Arbeit geht.
Die Probleme sind selbstverständlich auch in anderen großen Textdateien
(mit mehr 0x20…0x7e) vorhanden.
Nano schrieb:> Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Die eigentlich einzig sinnvolle ist: Gar nicht.
Gilt allerdings für vi unter Windows genauso.
Oliver
Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich
viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut):
Für jede Textzeile wird eine solche Struktur angelegt:
1
typedefstructlinestruct{
2
// Größe in Byte
3
char*data;// 8
4
ssize_tlineno;// 8
5
structlinestruct*next;// 8
6
structlinestruct*prev;// 8
7
short*multidata;// 8
8
boolhas_anchor;// 4
9
}linestruct;
Gesamtgröße inkl. Padding: 48 Byte
Dazu kommt der Malloc-Chunk, auf den data zeigt. In 64-Bit-Linux ist die
minimale Chunk-Größe 32 Byte. Auch für Leerzeilen, die außer dem LF
keine weiteren Zeichen enthalten, werden diese 32 Byte benötigt.
Eine Leerzeile belegt also 48 + 32 =qa80 Byte. Entsprechend belegen die
64 Mi Zeilen der Datei XXX 80 · 64 MiB = 5120 MiB.
Norbert schrieb:> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command> 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX
Das passt also sehr gut. Die verbleibende 3 MiB in RES werden vom
Programmcode und weiteren Daten belegt.
Andere Editoren wie bspw. Vim und erst recht Emacs gehen weit weniger
verschwenderisch mit dem Speicher um, wie man an den Testergebnissen von
Norbert und Jörg sehen kann.
Yalu X. schrieb:> Hier ist die Erklärung,
Wow, du gibst dir ja richtig Mühe. Alle Achtung!
Mit Emacs hab ich das nie probiert.
Die beiden Parteien (vi, Emacs) haben sich ja früher immer gegenseitig
angefrozzelt. ;-)
Könnte mir aber gut vorstellen das der auch keine Probleme hätte. Gut
abgehangene Software eben (beide ;-) ).
rbx schrieb:> (Früher konnte man bei Cygwin
Heute kann man unter Windows das WSL2 installieren und damit direkt
originale Ubuntu-Pakete installieren und nutzen. Kein Bedarf mehr für
Cygwin und Co.
Stefan ⛄ F. schrieb:> Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir im Büro> für Java EE Anwendungen.
Hm, merkwürdig... In anderen Sprachen kenne ich eine Menge Profis, die
"einfache" Editoren wie Atom, Sublime, vi(m), Emacs, UltraEdit,
Notepad++, Kate, Programmer's Notepad und Ähnliche benutzen. Nur unter
Java scheinen alle auf irgendeine IDE zu setzen, woran liegt das? Hat
dazu jemand -- im Gegensatz zu mir -- eine Idee?
Norbert schrieb:> Man muss halt Werkzeuge für Erwachsene nehmen
Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer.
Das wirkt nur überheblich.
Norbert schrieb:> Mit Emacs hab ich das nie probiert.
Er lädt das auch einigermaßen schnell (beide brauchen so um die 9
Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen.
Aber zum anderen Ende der Datei zu navigieren, dauert bei Emacs eine
gefühlte Ewigkeit, während es bei vi(m) ratz-batz geht.
Jörg W. schrieb:> Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer.> Das wirkt nur überheblich.
Ja, das war wohl die Reaktion auf das grausame und völlig faktenlose
Geschreibsel das sich zuvor in meine Netzhaut brannte. Normalerweise
versuche ich das zu vermeiden, aber manchmal geht's halt nicht…
Grundsätzlich gebe ich dir aber Recht.
Interessant: sogar die grafische Version des Emacs genehmigt sich in
beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.
Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen
des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal
sagen...
Jörg W. schrieb:> Er lädt das auch einigermaßen schnell (beide brauchen so um die 9> Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen.
Ach, solange es ohne swappen in den Speicher passt, dafür isser ja da.
Ein T. schrieb:> Interessant: sogar die grafische Version des Emacs genehmigt sich in> beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal> sagen...
In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt
wohl auf ewig ein Rätsel.
Glücklicherweise installiert man ein Debian System meistens nur einmal
und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich.
Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere
ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-)
Ein T. schrieb:> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal> sagen...
Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die
meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei
bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal
"leichter verdaulich" als ein vi.
Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz
gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie
einen vi dann doch auf Dauer bevorzugen.
Norbert schrieb:> Nano schrieb:>> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du>> anfangs behauptet hast.>> Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte> bedarf.
Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern
enthält ist KEINE Textdatei und da kannst du so viel auf dem Boden
herumstampfen wie du willst, daran wird sich nichts ändern.
Dein Beispiel mit lauter Newline Zeichen, also Zeichen, die lediglich
dem Editor sagen, dass eine neue Zeile beginnt ist kein Text und somit
ist das auch keine Textdatei.
Labere also jemanden anderen voll mit deinem Blödsinn!
> Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten> prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile.
Und dann noch mehr Zeit mit deinem Blödsinn verschenken? Nein danke!
Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier
verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten und
wenn dein \000 Code nicht durch ein Newline ersetzt wird, dann hast du
am Ende eine ziemlich miese Eingabe in den Editor, insbesondere die
Abwesenheit von Text.
> Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du> verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen> absondern.
Das hat Yalu X. hier schon getan:
Beitrag "Re: Vi Editor ausgestorben?"
Und da macht nano alles im üblichen Rahmen.
Auf UTF-32 und ein Wörterbuchdictionary zwecks schnellerer Suche habe
ich bereits verwiesen und ja, so etwas darf ein Editor machen ohne das
man ihm das negativ ankreiden darf, wie du es hier machst.
> Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen> Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich> völlig überfordern.
Eine Datei aus Newlinezeichen ist keine Textdatei, siehe oben.
Und wenn du solche große Dateien hast und sie mit einem Texteditor
anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine
weitere Datenverarbeitung aufbereitest. Die Bearbeitung von GB Weise
Daten gehört nämlich ganz gewiss nicht in das Aufgabenspekturms eines
Texteditors, der zum Bearbeiten von Configdateien,
Programmiersprachencode, Skriptcode oder HMTL Text da ist.
> Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt> mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor> er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt).
Dann beschwer dich bei den Entwicklern von nano was denen einfällt, den
nano zum Bearbeiten von Configdateien und Programmiersprachencode zu
entwickeln und deinen Anwendungsfall aus lauter Newlinezeichen zu
vergessen.
Hörst du dir eigentlich mal selbst beim Reden zu?
> Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für> Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro> Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen,> dann ist das kein Grund panisch zu reagieren. Das ist unser> Tagesstandard.
Dann schreibt man dafür aber auch ein entsprechendes Programm, dass die
Daten entsprechend aufbereitet und verarbeitet und frickelt darin nicht
händisch mit einem Texteditor herum der nie für solche Datenmengen
entwickelt wurde.
Und dann noch etwas, wenn ich so große Datenmengen zu verarbeiten hätte,
dann würde ich mir an deiner Stelle mal Gedanken über Binärdateien
machen. Die können Computer nämlich weitaus besser verarbeiten und ja,
für die nimmst du dann das entsprechend dafür geschrieben Programm zum
aufbereiten, was du aber ohnehin brauchst, siehe oben.
> Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen> dauert länger. Einen Glitsch in den Messdaten beseitigen,> Fingerschnippen.
Ein Mensch der Endanwender ist und in Messdaten gucken will, möchte in
der Regel einen Messzeitpunkt oder Messzeitbereich angeben, da springt
er ganz gewiss nicht in Zeilen herum, sondern erwartet ein Programm bzw.
eine Oberfläche, in das er einen Zeitpunkt oder Zeitpunktbereich
eingeben kann und dann bereitet ihm eine entsprechend programmiertes
Programm das auf und zeigt es auf einer Oberfläche an und gibt die Daten
da aus. Nix da mit Zeilennummer eingeben. Verlange doch gleich, dass er
mit dem Debugger Addresszeilen im RAM eingeben soll um sein Messdaten zu
finden.
Und auf so viel Gestümper bist du auch noch stolz und schwärmst darüber,
dass vim damit klar kommt? Lachhaft!
> Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch.> Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei.
Dann würdest du das umsetzen, was ich hier dir gerade geschrieben habe
und nicht vom Kunden erwarten, dass er mit VIM in deinen Messdaten
herumwühlen soll.
> und sieh' selbst was nano alles nicht kann und was ein richtiger Editor> problemlos kann.
Nano ist ein richtiger Editor. Er ist zum Bearbeiten von Textdateien,
Skripten, Programmcode und Konfigurationsdateien da und das kann er.
Yalu X. schrieb:> Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich> viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut):>> Für jede Textzeile wird eine solche Struktur angelegt:>>
1
>typedefstructlinestruct{
2
>// Größe in Byte
3
>char*data;// 8
4
>ssize_tlineno;// 8
5
>structlinestruct*next;// 8
6
>structlinestruct*prev;// 8
7
>short*multidata;// 8
8
>boolhas_anchor;// 4
9
>}linestruct;
10
>
>> Gesamtgröße inkl. Padding: 48 Byte
Danke und so etwas darf ein Texteditor, der zum Editieren von
Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,
auch.
Also kein Fehler des Programms.
Wenn Norbert anderes erwartet, dann ist das Problem vor dem Bildschirm.
Übrigens für die nicht Programmierer hier.
So ein struct das als Liste benutzt wird beschleunigt das Tauschen,
Einfügen und Entfernen von Zeilen erheblich, also eine Hauptaufgabe von
Editoren und da es algorithmisch eine Liste mit Zeiger zum vorherigem
und nächstem Listenelement ist, darf diese Liste beliebig lange werden,
solange der Rechner genug RAM an.
Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,
sondern er seinem Rechner zu wenig RAM verpasst hat.
Und ja, wenn man andere Anforderungen hat, dann kann man als Entwickler
einer Anwendung die Daten speichertechnisch auch anders organisieren,
z.B. die Zeilen zu Blöcken zusammenfassen und mit Blöcken arbeiten, das
bedeutet dann beim Entfernen und Einfügen von Zeilen dann aber erheblich
mehr Aufwand und reorganisation der Daten.
Nano schrieb:> Danke und so etwas darf ein Texteditor, der zum Editieren von> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,> auch.
Ist er denn als solcher irgendwo deklariert?
1
DESCRIPTION
2
nano is a small and friendly editor. …
Das ist das einzige Auftreten des Worts "small" in der ganzen man page.
Also es steht zumindest nicht da, dass er nur für "small files" da sei …
> Also kein Fehler des Programms.
Aber zumindest ungeschickt programmiert.
Nano schrieb:> Und wenn du solche große Dateien hast und sie mit einem Texteditor> anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine> weitere Datenverarbeitung aufbereitest.
Wer legt das fest? Du?
In aller Regel muss man in der Praxis einfach mal mit dem leben, was
einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor.
Nano schrieb:> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,> sondern er seinem Rechner zu wenig RAM verpasst hat.
Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so
einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch
dem Nano zur Verfügung steht.
Norbert schrieb:> Glücklicherweise installiert man ein Debian System meistens nur einmal> und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich.
So ist das mit einem vi(m) oder Emacs ja auch: die Konfigurationsdatei
meines Emacs ist zum größten Teil schon über zwanzig Jahre alt, in den
letzten Jahren sind da nur ein paar ELPA-Pakete für Dockerfiles und
Kubernetes-Deployments hinzu gekommen. Das ist auch so eine schöne
Eigenschaft von alter, gut abgehangener Software -- wenn ich sehe, wie
viel Aufwand die Kollegen bisweilen betreiben müssen, um ihre IDEs
wieder lauffähig zu machen, wenn sie die aktualisiert haben oder auf
einen neuen Computer gewechselt sind, finde ich das schon ein bisschen
erschreckend.
> Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere> ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-)
;-)
Nano schrieb leider schon wieder im Beitrag #7117082:
> eine Menge Gequirltes…
Und er erklärt schon wieder was andere machen sei falsch. Ohne auch nur
den geringsten Schimmer einer Ahnung zu haben…
Jörg W. schrieb:> Ohne …
Tja Jörg, schau es dir an und erkläre wie man mit Menschen umgehen soll
die sich ihre eigene Realität schaffen. ;-)
Ignorieren? Ja, das ist ein Plan!
Norbert schrieb:> Ein T. schrieb:>> Interessant: sogar die grafische Version des Emacs genehmigt sich in>> beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.>> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen>> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal>> sagen...>> In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt> wohl auf ewig ein Rätsel.
Für jemand der programmieren kann und Informatikvorlesungen,
insbesondere die Fächer Algorithmen und Datenstrukturen besucht hat ist
das Verwalten von Daten als Liste kein Rätsel, sondern je nach
Aufgabenstellung eine sinnvolle Lösung der Aufgabenstellung.
In deinem Fall tippe ich also mal auf Umschuler, der in das
Programmieren von Python so nebenbei reingerutscht ist.
Kein Wunder, dass du Gigabyteweise Messdaten als Textdaten ablegen
willst, anstatt dir Gedanken über ein effizientes Binärformat zu machen.
Und ja, wenn man das nicht kann, dann ist es natürlich verständlich,
dass man seine Rettung in vim sucht.
Jörg W. schrieb:> Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die> meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei> bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal> "leichter verdaulich" als ein vi.
Keine Frage, der nano ist "zugänglicher" für Einsteiger. Das erklärt
aber nicht, warum man den guten alten vim eines Teils seiner gewohnten
Funktionalität berauben mußte und dies nicht einmal deutlich kenntlich
gemacht hat. Das verwirrt dann die erfahrenen vim-Nutzer, die sich
natürlich darauf verlassen, daß dieser Editor auch unter Debian
funktioniert wie gewohnt. Ähnliches gilt für die Nummer mit der dash. Da
wird der Wechsel auf Debian für Einsteiger erleichtert und für erfahrene
Nutzer erschwert, und das bei einer Distribution, die sich laut Aussagen
von Mitgliedern dieses Projekts vornehmlich an erfahrene Benutzer
richtet. Äh?
> Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz> gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie> einen vi dann doch auf Dauer bevorzugen.
Definitiv, ja.
Leute, bitte tauscht eure Kindergarten-Anschuldigungen ("Umschuler"
(sic), "Werkzeuge für Erwachsene", "Gestümper") künftig per Email aus.
Das Forum braucht sowas nicht.
Ein T. schrieb:> Das erklärt aber nicht, warum man den guten alten vim eines Teils seiner> gewohnten Funktionalität berauben mußte und dies nicht einmal deutlich> kenntlich gemacht hat.
Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn
auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist
es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht
erwarten sollte, dass sie eine Bash ist.)
Nano schrieb:> Danke und so etwas darf ein Texteditor, der zum Editieren von> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,> auch.>> Also kein Fehler des Programms.
Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler.
Nano schrieb:> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,> sondern er seinem Rechner zu wenig RAM verpasst hat.
Das sagt Microsoft bei jeder neuen Windows-Version auch ;-)
Yalu X. schrieb:> Nano schrieb:>> sondern er seinem Rechner zu wenig RAM verpasst hat.>> Das sagt Microsoft bei jeder neuen Windows-Version auch ;-)
Und diverse Dealer voin Placebo und sonstiger Betrugssoftware wie
seineszeiten "SoftRAM"
"Trotzdem ist der SoftRAM-Treiber mit 54 724 Bytes viel größer als das
Original DynaPage.VxD. Beim näheren Anschauen trauten wir unseren Augen
kaum: Er enthält 41 820 Nullen! Nur rund 12,6 KByte werden überhaupt
genutzt, das Original belegt dagegen rund 8 KByte." aus
https://www.heise.de/ct/artikel/Placebo-forte-284374.html
Nano schrieb:> Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern> enthält ist KEINE Textdatei
Also bist Du jetzt hier der Chef und bestimmst über "richtige"
Dateitypen und -Inhalte, und die Aufgaben, die andere mit ihren
Werkzeugen bearbeiten dürfen?
> Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier> verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten
Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei
mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,
zuverlässig, performant, stabil und absolut reproduzierbar
funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei
Dir angeblich Probleme gemacht haben sollen -- obwohl Dein
Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler
gemacht hast.
Jörg W. schrieb:> Nano schrieb:>> Also kein Fehler des Programms.>> Aber zumindest ungeschickt programmiert.
Wenn man normale Datenmengen <= 1 MiB erwartet und die Hauptaufgabe das
Einfügen, Entfernen, Tauschen und Hinzufügen von Zeilen ist, dann ist
eine verkettete Liste mit Listenattributen für ein vorheriges und
nächstes Listenelement als Datenstruktur völlig ausreichend und
ungeschickt programmiert kann man hier auch nicht sagen, weil es für
kleine Datenmengen sogar die bessere, da einfacher zu handhabende,
Datenstruktur ist und große Messdatenreihen ganz gewiss nicht eine der
Anforderungen war, als der Editor von den Programmierern programmiert
wurde.
Würdest du dagegen die Zeilen zu bspw. Zeilenblöcken verarbeiten, die
insgesamt bspw. 64 KiB fassen können, dann müsstest du beim Einfügen in
der Mitte von so einem vollen Block eine neuen Block, der dann gleich 64
LIb belegt anlegen und im Worst Case Fall, falls du das dann nicht noch
komplizierter verwaltest, alle Zeilen, die ab der Hälfte des Blocks
folgen nach unten schieben, so dass die unterste Zeile dann im nächsten
Block landet.
Für lahme Rechner ist das ein erheblicher Aufwand. In nano müssten
stattdessen dazu nur zwei Adresszeiger vertauscht werden, fertig.
Die Struct Liste ist somit sehr effizient, wesentlich effizienter als so
eine Blockdatenstruktur. Und ja, natürlich braucht man für die extra
Zeiger dann mehr Platz. Kein Vorteil ist umsonst.
Wenn Norbert hier dann sagt, dass nano nicht gescheit programmiert wäre
und Spielzeug sei, dann bedeutet das nichts anderes, als das er keine
Ahnung von Datenstrukturen hat.
> Nano schrieb:>> Und wenn du solche große Dateien hast und sie mit einem Texteditor>> anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine>> weitere Datenverarbeitung aufbereitest.>> Wer legt das fest? Du?
Das man sich über eine sinnvolle Datenstruktur bei gegebener
Aufgabenstellung Gedanken machen sollte, lernt man im Info Studium.
> In aller Regel muss man in der Praxis einfach mal mit dem leben, was> einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor.
Das ist leider wahr. All zu oft wird dann von den falschen Leuten ohne
entsprechende Qualifikation eine Simple Quick & Dirty, aber Hauptsache
billig Lösung hingeschludert und das ist dann das Ergebnis, was man hier
bei Norbert sehen kann.
> Nano schrieb:>> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,>> sondern er seinem Rechner zu wenig RAM verpasst hat.>> Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so> einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch> dem Nano zur Verfügung steht.
Die Liste kann prinzipiell beliebig lang anwachsen, es braucht also nur
mehr RAM.
Das Einlesen und Anlegen der Datenstruktur kostet natürlich anfangst
etwas mehr Zeit, aber wenn sie dann im RAM liegt, dann geht das Einfügen
oder Löschen von neuen Zeilen sehr effizient.
Lass mal 10000000 neue Zeilen in so eine 64 MiB Datei automatisiert von
nano und dann einmal von vim auf einem Rechner ohne Cache einfügen. Ich
würde dann mal stark schätzen, dass nano deutlich schneller fertig sein
wird.
Jörg W. schrieb:> Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn> auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist> es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht> erwarten sollte, dass sie eine Bash ist.)
Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens
20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.
Nano schrieb:> Ich würde dann mal stark schätzen, dass nano deutlich schneller fertig> sein wird.
Ich denke, einen Kasten Bier solltest du darauf lieber nicht verwetten.
;-)
Nanolator schrieb:> Nano schrieb:>> Danke und so etwas darf ein Texteditor, der zum Editieren von>> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,>> auch.>>>> Also kein Fehler des Programms.>> Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler.
Listenstrukturen sind beim Einfügen (insbesondere überall da, wo nicht
das Datenende ist) und Löschen besonders effizient und daher sinnvoll.
Daher ist das definitiv keine Verschwendung und schon gar nicht ist sie
unbegründet.
Siehe dazu nochmal mein vorheriges Kommentar.
Jörg W. schrieb:> Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn> auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist> es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht> erwarten sollte, dass sie eine Bash ist.)
Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch
bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt
das Folgende aus:
Ein T. schrieb:> Nano schrieb:>> Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier>> verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten>> Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei> mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,> zuverlässig, performant, stabil und absolut reproduzierbar> funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei> Dir angeblich Probleme gemacht haben sollen -- obwohl Dein> Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler> gemacht hast.
Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es
memtest86+?) überprüft.
Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch
die doppelten Einträge alle entfernen willst und das ganze noch durch
eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und
die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche
Datenmengen nie erwartet wurden.
Um herauszufinden, was da genau das Problem war, müsste man sich
natürlich den Code von sort und uniq, sowie der Shell ansehen. Ich habe
mir dann was eigenes programmiert und mir so anders geholfen um eine
richtige sortierte Liste mit einzigartigen Einträgen zu erhalten.
Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen
und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen
und das ganze dann wieder zu einer großen mehrere GB großen Datei
zusammenfügen und dann anschließend sort und uniq darauf loslassen.
Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein,
wenn sort und uniq alles richtig machen.
Jörg W. schrieb:> Hmm, das ist dann schon bissel irreführend.
Der relevante Hinweis ist auch leicht zu übersehen:
Ein T. schrieb:> ~ Running in Vi compatible mode
Norbert schrieb:> Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens> 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.
Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität
gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche
Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre
gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen,
daß die meisten funktionieren und manche wieder nicht. Ich kann mir nur
wenige bessere Möglichkeiten vorstellen, um Verwirrung zu stiften.
Nano schrieb:> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch> die doppelten Einträge alle entfernen willst und das ganze noch durch> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche> Datenmengen nie erwartet wurden.
Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden
die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas
falsch gemacht hast.
Also was vim.tiny betrifft.
Ja, da stimme ich zu. Da hätte man bei Programmstart schon als Titel
angeben können, dass es sich hier um vim.tiny handelt und nicht um VIM
- Vi IMproved , wie es bei vim.tiny ebenfalls im Titel steht.
Wer will, der kann ja mal einen Bugreport an das Debianprojekt
schreiben.
https://www.debian.org/Bugs/Reporting
Der einzige Unterschied, der am Splashscreen erkennbar ist, ist
lediglich, dass die Vollversion von vim einen deutschen Text hat, sofern
das System auf DE eingestellt ist, während die tiny Version englisch
bleibt.
nano,
ich finde du hast die Eingangsfrage, ob und wieso du nicht vim nutzt gut
und (für dich) richtig beantwortet.
Auf der Konsole, zum Editieren von Config-Files, reicht dir der nano und
für größeres Zeugs hast du deine IDE.
Soweit OK.
Jetzt lockst du natürlich die übliche Meute an die dir zeigen will dass
ihr Spielzeug viel toller ist (mir unverständlich was diesen Reflex
auslöst).
Und dein Problem dabei: die haben recht. Objektiv betrachtet kann der
vim mehr als der nano, und wie man sieht sogar mit geringerem
Ressourceneinsatz.
Dein Fehler ist, dich aufgrund der Schilderung von Usecases, die für
dich ja eh nicht relevant sind, zu einer Diskussion hinreißen zu lassen.
Du musst keine Binärdateien ändern.
Du musst keine 4Gb++ großen Textdateien ändern.
Fancy find&replace-Orgien brauchst du auch nicht bzw. falls doch kriegst
du sie anders abgebildet.
Dann sag das doch einfach. Sag dass dein Anspruch an deinen CLI-Editor
ist, Config-Dateien zu bearbeiten, und fertig.
Das Problem ist, du versuchst diese Beispiele zu kontern, und das kann
nur daneben gehen.
Denn jetzt hast du nicht mehr die Frage "Nutzt du vim? [...] Wieso
nicht?" sondern du hast die Diskussion "nano vs. vim" an der Backe und
da siehst du kein Land.
Ich stelle fest, du blamierst dich hier - ohne Not - bis auf die Knochen
und die streitlustigen Subjekte dürfen heute mit der grimmigen
Befriedigung ins Bett gehen, jemanden im Netz mal so richtig verdroschen
zu haben.
Mombert H. schrieb:> Nano schrieb:>> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch>> die doppelten Einträge alle entfernen willst und das ganze noch durch>> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und>> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche>> Datenmengen nie erwartet wurden.>> Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden> die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas> falsch gemacht hast.
Du darfst natürlich gerne glauben, dass lang bewährte Software keine
Bugs hat.
Beim Finden der Heartbleed Lücke hat das allerdings ein paar Jahre
gedauert, insofern kann das halt doch vorkommen.
Ein T. schrieb:> Norbert schrieb:>> Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens>> 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.>> Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität> gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche> Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre> gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen,> daß die meisten funktionieren und manche wieder nicht.
Ja, in der Tat.
Mir fiel das immer unangenehm auf wenn ich meine .vimrc auf ein anderes
System transferiert und dann den vi (nicht vim) gestartet hatte.
Error detected while processing .vimrc:
E319: Sorry, the command is not available in this version:
> Ich kann mir nur wenige bessere Möglichkeiten vorstellen,> um Verwirrung zu stiften.
Ach, da geht noch was… ;-)
Nano schrieb:> Du darfst natürlich gerne glauben, dass lang bewährte Software keine> Bugs hat.
Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software
sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine
Folge von fehlerhafter Anwendung waren.
Nano schrieb:> Ein T. schrieb:>> Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei>> mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,>> zuverlässig, performant, stabil und absolut reproduzierbar>> funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei>> Dir angeblich Probleme gemacht haben sollen -- obwohl Dein>> Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler>> gemacht hast.>> Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es> memtest86+?) überprüft.
Hm.
> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch> die doppelten Einträge alle entfernen willst und das ganze noch durch> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche> Datenmengen nie erwartet wurden.
Merkwürdig, solche Dinge mache ich seit vielen Jahren sehr regelmäßig
und kann mich nicht daran erinnern, jemals ein Problem dabei gehabt zu
haben. Übrigens benutze ich UNIX-Pipes auch oft mit Binärdaten, ohne daß
es Probleme gäbe -- einer meiner häufig genutzten Befehle ist es, die
Ausgabe von tar(1) auf pigz(1) zu pipen, denn parallel komprimieren geht
natürlich viel schneller.
> Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen> und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen> und das ganze dann wieder zu einer großen mehrere GB großen Datei> zusammenfügen und dann anschließend sort und uniq darauf loslassen.> Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein,> wenn sort und uniq alles richtig machen.
Ich habe keinerlei Zweifel daran, daß das völlig problemlos
funktionieren wird, wenn ich das mache, schließlich hat das ja auch in
den letzten Jahren auch immer absolut problemlos funktioniert -- auch
mit Dateien von mehreren Terabyte Größe, aber dann natürlich auf unseren
fetten Eisen. Mittlerweile benutze ich für sowas nur deshalb unseren
Spark-Cluster, weil das parallelisiert natürlich viel schneller geht.
Aber mit kleinen Dateien von ein paar Gigabyte geht das natürlich auch
lokal. Ich frage morgen aber mal meine Kollegen, ob denen etwas
aufgefallen ist.
Ist schon ziemlich verwirrend, zumindest bei Linux Mint (und
wahrscheinlich auch noch bei vielen anderen, die von Debian abstammen)
Ruft man vim auf, so wird nichts gefunden.
Ruft man vi auf, so meldet sich vim, obwohl es sich in Wirklichkeit um
vim.tiny handelt.
Will man vim benutzen, muss man es extra installieren.
Das muss man auch erst mal verstehen.
Norbert schrieb:> Ein T. schrieb:>> Ich kann mir nur wenige bessere Möglichkeiten vorstellen,>> um Verwirrung zu stiften.>> Ach, da geht noch was… ;-)
Bitte weck' jetzt keine schlafenden Geister den Debian-Leuten, ja? ;-)
Nano schrieb:> Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Eigentlich nur sinnvoll als Teil eines anderen Softwarepaketes.
Nano schrieb:> Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen> intuitiven Editoren auch bereits pico zur Verfügung.> Und pico hat meistens gegen joe gewonnen, so war es auch bei mir.
Es hat sich in der Zwischenzeit einiges getan..aber als eigenständiges
Konsoleprogramm habe ich joe und seine Zwillingsbrüder noch nicht zum
laufen bekommen. Entweder funktioniert der Download nicht, oder aber
muss sich nochmal die Konfigurierhinweise genauer ansehen. Also Nix Plug
and Play.
Etwas Nano-Soziologie..:
https://news.ycombinator.com/item?id=11953229
( die Frage lautet: don't want to sound nasty , but is anyone there
using nano really ? i know it come by default in some distros but that's
about it really. )
Die Antworten sind recht lesenswert.
Ein T. schrieb:> Heute kann man unter Windows das WSL2 installieren
Noch einer, der noch Bedarf nach einem Aha hat?
Ein T. schrieb:> Kein Bedarf mehr für> Cygwin und Co.
So sehe ich das nicht. WSL ist eine Alternative neben anderen, teilweise
auch viel besser zugeschnittenen Angeboten. Grundsätzlich aber keine
schlechte.
Mein Problem ist z.B. ich habe gar kein Windows 10 oder Windows 11. Und
ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht
vernüftig auf Linux spielen kann.
(Und Dualboot brauche ich auch nicht)
Hier noch ein Link auf die Suche in etwa "große Dateien editieren"
https://askubuntu.com/questions/28847/text-editor-to-edit-large-4-3-gb-plain-text-file
rbx schrieb:> Und> ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht> vernüftig auf Linux spielen kann.
Zumindest dafür gibts Abhilfe ;-)
https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition
Läuft bei mir unter Arch Linux nativ und problemlos.
(Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat
minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag
für Puristen evtl. nicht duldsam sein)
Mombert H. schrieb:> Nano schrieb:>> Du darfst natürlich gerne glauben, dass lang bewährte Software keine>> Bugs hat.>> Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software> sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine> Folge von fehlerhafter Anwendung waren.
Du liest einfach nicht, was ich oben geschrieben habe.
Ich erwähnte, dass ich damals den CLI Befehl mit sort und uniq mit
kleiner Datenmenge auf Funktionsrichtigkeit überprüft habe.
D.h. der CLI Befehl und die angegebenen Parameter waren korrekt und das
Ergebnis richtig.
Eine fehlerhafte Anwendung der CLI Tools würde bedeuten, dass das hier
hätte spätestens auffallen müssen. Zumal du dich auch fragen solltest,
wie viel man überhaupt bei sort und uniq bei der Parameterangabe falsch
machen kann und ob dann überhaupt noch die Wahrscheinlichkeit einer
fehlerhaften Anwendung durch den Nutzer ausreichend groß ist.
Aber wie dem auch sei, glaub halt was du willst. Ich weiß, was ich
beobachten konnte und die Wörter waren am Ende nach sort und uniq eben
nicht einzigartig, sondern kamen mehrmals in der Datei vor, wie grep
zeigte..
Du kannst jetzt gerne, wenn du möchtest, prüfen, ob sort oder uniq
vielleicht mit irgendwelchen Puffergrößen arbeitet und dann bei
Überschreitung von diesem nur noch auf die kleinere Puffergröße
entsprechend sortiert bzw. auf einzigartige Elemente reduziert, das
würde dann nämlich das Ergebnis erklären.
Bedenke nämlich bitte, wenn du eine bspw. 20 GiB große Datei hast, dann
muss die Zeile, die bspw. mit A beginnt und sich gerade ganz am Ende der
Datei befindet, nach ganz vorne sortiert werden. Wenn du die 20 GiB
nicht auf einmal in das RAM bekommst, dann reicht ein einfaches Array
auf das man einen Sortieralgo anwendet nicht, sondern dann musst du dir
einen entsprechenden Algorithmus ausdenken der das berücksichtigt.
Gleiches gilt für das finden der uniq Elemente.
Und es ist durchaus möglich, dass ein Programm, abhängig von der
Datenmenge und dem verfügbaren RAM unterschiedliche Algorithmen
anwendet, weil der Algo, der mit kleinen Daten, die komplett ins RAM
passen vielleicht schneller ist, als der andere, der auch das
Zwischenauslagern auf Festplatte berücksichtigt und den Umgang mit
großen Datenmengen erlaubt.
Das Resultat davon ist, dass du im gleichen Programm unterschiedlich gut
getestete Algorithmen haben kannst
Das ganze dürfte jetzt schon über 10 Jahre her sein.
Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war
zu groß und ich musste die Festplatte mitverwenden.
Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück
überzeugt und springe gleich ans Ende:
Nano schrieb:> Das ganze dürfte jetzt schon über 10 Jahre her sein.> Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war> zu groß und ich musste die Festplatte mitverwenden.
Mit "über 10 Jahren" meinst du 30 Jahre oder so? Oder meinst du 8 GB?
Nur so zur Erinnerung:
-Anfang 2013 kam der Raspberry Pi mit 256 MB
-Ende 2007 kam das iPhone mit 128 MB
auf den Markt.
Mombert H. schrieb:> Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück> überzeugt und springe gleich ans Ende:>> Nano schrieb:>> Das ganze dürfte jetzt schon über 10 Jahre her sein.>> Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war>> zu groß und ich musste die Festplatte mitverwenden.
Oh, kleiner Tippfehler. Es waren natürlich 8 GiB RAM.
Ich habe das damals auf meinem Core2Duo durchgeführt und die Distri war
irgendeine LTS Ubuntuversion aus der damaligen Zeit.
Jack V. schrieb:> Nano schrieb:>> Und es stellt sich hier dann auch gleich noch die Frage, warum man unter>> Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt.>> Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der> Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama> – dauert keine Minute, bis man das behoben hat.
Eine Diskussion dazu im Debian-Devel-Forum findet man hier
switching to vim-tiny for standard vi?
https://lists.debian.org/debian-devel/2005/12/msg00796.html
Der richtige vim wurde für base als zu groß angesehen und es wird lange
diskutiert, welche optionale kleinere Version genommen werden soll.
Wahrscheinlich haben sie auch irgendwo diskutiert wie man die Nutzer
darüber informieren soll. Dazu habe ich aber auf die Schnelle keine
Stelle gefunden.
In der Paketbeschreibung von vim-tiny werden die Einschränkungen zwar
erwähnt, aber das sieht der Nutzer eines frisch installierten base
systems natürlich nicht, wenn er vim oder vi aufruft.
https://packages.debian.org/bullseye/vim-tiny
"This package contains a minimal version of Vim compiled with no GUI and
a small subset of features. This package's sole purpose is to provide
the vi binary for base installations. If a vim binary is wanted, try one
of the following more featureful packages: vim, vim-nox, vim-athena, or
vim-gtk3."
Siehe auch
Ein T. schrieb:> Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch> bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt> das Folgende aus:
Nano schrieb:> BTW, der popularity Contest bei Debian ist auch immer wieder> interessant:
… solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild
ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig
abgewählt.
Le X. schrieb:> Zumindest dafür gibts Abhilfe ;-)> https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition> Läuft bei mir unter Arch Linux nativ und problemlos.
Danke für den Hinweis. :)
Allerdings hatte ich das normale BG2 schon auf meinem Rechner
installiert, und grundsätzlich läuft es ja, nur die Maussteuerung kommt
nicht in die Gänge. In Windows gibt es solche Probleme auch, aber aber
meist nur für ein paar Minuten oder Sekunden. Das war z.B. bei Kolibri
OS so. Aber nach ein paar Minuten hatte sich die Maussteuerung gefangen.
> (Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat> minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag> für Puristen evtl. nicht duldsam sein)
Finde ich nicht schlimm. Aber eigentlich mochte ich das Zusammenzählen
der Punkteverteilung beim Auswürfeln. Das hatte so einen netten
Überraschungseffekt.
Überhaupt scheinen mir die Arch-Entwickler der Abteilung Spiel und Spaß
viel aufgeschlossener zu sein. Das aber nur eine Vermutung am Rande. Bei
Fedora haben die schon angefangen, Benchmarks mit Far Cry 5 zu
veröffentlichen - aber natürlich ohne sich ein paar Gedanken zu machen,
was tatsächlich Gamemäßig abläuft, wo die Ansätze sind, oder wie man sie
ordentlich dokumentiert.
https://fedoramagazine.org/fedora-workstation-state-of-gaming-far-cry-5/Nano schrieb:> Joe 1146 votes, Rang 4218
Naja, für Nano gab es auch kleine Einführungen vom Rechenzentrum an
Unis. Teilweise waren (Einstiegs-)Kurse auch auf Nano ausgerichtet. Also
von daher kein unbekannter Editor.
Hinsichtlich der eigenständigen, unabhängigen Version auf Windows hat
Joe aber deutlich die Nase vor Nano.
Auch den MC gibt es schmerzfrei für Windows.
So ein wenig kann man sich in der Situation hier auch an Basic erinnert
fühlen. Letztlich war Basic für viele DIE Einstiegssprache schlechthin
in das Programmieren. Und die Verbreitung von Basic war auch extrem.
Irgendwie finde ich die Fortran 77 Werkzeuge der Watcom-Installation
auch noch etwas ansprechender als GNU-Fortran.
Jack V. schrieb:> Nano schrieb:>> BTW, der popularity Contest bei Debian ist auch immer wieder>> interessant:>> … solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild> ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig> abgewählt.
Wie bereits zuvor erwähnt:
"Leute, die bei der Installation von Debian dieser Survey Funktion
Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern
zu."
Beim Wählen ist das auch so. Wer nicht wählen geht, legitimiert die
Gewählten.
Nano schrieb:> "Leute, die bei der Installation von Debian dieser Survey Funktion> Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern> zu."
Was halt dazu führt, dass es nicht dazu geeignet ist, die Verbreitung
oder gar Beliebtheit von irgendwas aufzuzeigen. Es war dazu gedacht, zu
bestimmen, was auf den ersten Installationsimages landet, und ist heute
weitgehend Deko.
Wie auch immer – ist halt wieder so’n irrelevanter Nebenschauplatz, der
eigentlich zum Thema nicht mal was beiträgt.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2
44684 root 20 0 69420 68264 1744 S 0.0 0.1 0:00.32 fe XXX
Dass hier der Speicherverbrauch nur geringfügig über der Größe der 64M
Datei, welche nur aus Newlines besteht, hatte ich in diesem Thread hier
mal kurz angedeutet:
Beitrag "Re: Vi Editor ausgestorben?"
Die Crux an den gängigen Editoren ist nämlich immer noch, dass sie
zeilenorientiert arbeiten. Deshalb bauen sie da pro Zeile
Verwaltungsstrukturen auf, die man gar nicht braucht.
Den Text-Speicher kann man auch viel einfacher aufbauen, nämlich aus je
zwei zusammenhängenden Blöcken, welche durch eine Lücke (gap)
voneinander getrennt sind:
1
buf1 | gap | buf2
2
size1 gapsize size2
Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per
memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in
die Lücke. Die gapsize wird dann um 1 verkleinert, size1 um 1
vergrößert. Bei weiteren Zeicheneinfügungen wird nichts mehr verschoben,
es wird nur noch size1 inkrementiert und gapsize dekrementiert.
Löschen per Backspace ist ebenso einfach:
1
size1--;
2
gapsize++;
Das wars. Und es funktioniert sogar zeilenübergreifend: Beim Löschen
eines Newlines passiert nicht mehr!
Ist die Lücke auf die Länge 0 geschrumpft, geschieht ein realloc(), um
eine neue Lücke zu erzeugen. Auf heutigen Betriebssystemen, wo der
Speicher sowieso nur virtuell gehandhabt wird, ist auch ein realloc()
auf 1 GB oder mehr überhaupt kein Problem.
Alle anderen Editierfunktionen werden analog implementiert, auf eine
zeilenorientierte Speicherstruktur kann komplett verzichtet werden. Die
Operationen auf den Speicher sind blitzschnell, da hier
zusammenhängender Speicher verwendet wird. Man muss sich also nicht mehr
von Zeile zu Zeile hangeln. Deshalb sind auch die Geschwindigkeiten bei
einer Textsuche im zusammenhängenden Speicher kaum zu toppen. Verkettete
Pointer auf die Zeilen oder ähnlich aufgebaute Verwaltungsstrukturen
sind damit obsolet.
Einziger Nachteil: Der Editor weiß nicht, in welcher Zeile sich der
Cursor befindet. Diese Position muss er entweder auf Anfrage selbst
ermitteln oder permanent bei jeder Textoperation nachhalten. Ich
persönlich brauche solch eine Permanentanzeige nicht, die mir sagt, dass
ich gerade in Zeile 9999 von 200000 stehe. Das kann der Editor auf
Tastendruck auch ad hoc ermitteln, wenn ich es mal brauche.
Frank M. schrieb:> Alle anderen Editierfunktionen werden analog implementiert, auf eine> zeilenorientierte Speicherstruktur kann verzichtet werden.
Das ist zu kurz gedacht. Die Anzeige von Text in einem Texteditor ist
ziemlich stark zeilenbasiert. Alle "comfort-Funtkionen" sind
zeilenbasiert. diff, git-blame, Fehlermeldungen und Warnungen vom
Compiler und so weiter. Es ist also naheliegend eine zeilenbasierte
Datenstruktur zu nutzen.
Frank M. schrieb:> Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per> memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in> die Lücke. Die Größe der Lücke wird dann um 1 verkleinert. Ist die Lücke> auf 0 geschrumpft, geschieht ein realloc, um eine neue Lücke zu> erzeugen.
Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es
plötzlich zwei Lücken und 3 Speicherblöcke. Führt man eine automatische
Umbenennung von Variablennamen durch, gibt es N_umbennenung + 1
Speicherblöcke. Und entfernt man die überflüssigen Leerzeichen am Ende
jeder Zeile gibt es N_zeilen+1 Speicherblöcke. Oder soll bei jeder
dieser Aktionen durch kopieren wieder auf 2 Speicherblöcke reduziert
werden? Für kleine Config-Files ist das egal, für eine 10k Zeilen
Quelltextdatei oder größe CSV-Datein kann das schnell in einer
Katastrophe enden.
mh schrieb:> Die Anzeige von Text in einem Texteditor ist ziemlich stark> zeilenbasiert.
Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei
der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt
wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein
Bildschirmfenster hat.
mh schrieb:> Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es> plötzlich zwei Lücken und 3 Speicherblöcke.
Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die
Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben.
Es gibt immer nur eine Lücke.
Der Editor existiert und ist real. Was er unter anderem kann, hatte ich
in obigem Link mal angerissen:
Beitrag "Re: Vi Editor ausgestorben?"
Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache,
kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles
mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen
Blatt. Es gibt ihn nämlich nicht öffentlich.
Frank M. schrieb:> mh schrieb:>> Die Anzeige von Text in einem Texteditor ist ziemlich stark>> zeilenbasiert.>> Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei> der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt> wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein> Bildschirmfenster hat.
Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer
gestartet werden muss. Auch wenn man in Zeile 424242 und der
Start-Pointer 2GB entfernt ist.
Frank M. schrieb:> Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die> Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben.> Es gibt immer nur eine Lücke.
Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die
Lücke fällt.
Frank M. schrieb:> Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache,> kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles> mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen> Blatt. Es gibt ihn nämlich nicht öffentlich.
Wieviele Personen haben denn diesen "fe" schon getestet?
mh schrieb:> Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer> gestartet werden muss. Auch wenn man in Zeile 424242 und der> Start-Pointer 2GB entfernt ist.
Der Start-Pointer liegt immer mindestens 3 Zeilen vor der
Text-Cursor-Position. Das ist überhaupt nicht weit weg. Wenn ich mit dem
Cursor eine Zeile tiefer gehe, wandert der Start-Pointer zum nächsten
Newline (aus seiner Sicht) vor.
Warum 3 Zeilen? Ich hasse Editoren, bei denen man die darüberliegende
Zeile erst sieht, wenn man mit dem Cursor oben am Bildschirmrand
anschlägt. Dasselbe gilt für den unteren Rand. Nähere ich mich ihm, dann
fängt er frühzeitig an zu scrollen.
> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die> Lücke fällt.
Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle
steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb
eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000
und dann 8000.
> Wieviele Personen haben denn diesen "fe" schon getestet?
Gestetet? Ungefähr ein Dutzend. Aktiv genutzt? Ein paar tausend. Er
wurde u.a. an staatliche Stellen verkauft, z.B. an die Bundeswehr und
diverse Staatsministerien - aber mit anderem Namen und Kontext. "fe" ist
nur eine private Variante davon.
P.S.
Wenn Du dem Link in obigem Beitrag von mir gefolgt wärst, dann wüsstest
Du, dass die Idee mit dem Gap nicht auf meinem Mist gewachsen ist,
sondern von James Gosling stammt.
Hier ein kleiner Literaturhinweis dazu:
https://en.wikipedia.org/wiki/Gosling_Emacs oder auch zu seiner Person:
https://en.wikipedia.org/wiki/James_Gosling . Er war unter anderem der
Chefdesigner bei der Entwicklung von Java.
Von daher behaupte ich mal, dass Editoren, die mit einer Lücke arbeiten,
von mehreren hunderttausenden Anwendern genutzt wurden bzw. wird.
P.P.S.
Diese Stelle in seinem Code finde ich einfach genial:
https://gist.github.com/jart/0a6a402b480e7dbcf8e61895759f2058
Unter einem ASCII-Art-Totenkopf steht folgendes:
1
If you think you understand it,
2
You Don't,
3
So Look Again.
Ergänzung: Ich habe lediglich seine Idee übernommen, nicht seinen Code.
Den finde ich nämlich ziemlich gewöhnungsbedürftig. Zudem wurde
"Gosmacs" von Gosling in den 80ern entwickelt. Da war der
C-Sprachstandard längst nicht so weit wie heute. Von daher sieht der
Code einfach "alt" aus.
Richard Stallman (GNU Foundation) hatte ursprünglich für seinen "GNU
Emacs" Teile von Gosmacs übernommen, hat diese dann auf Bitten von
Unipress, welche mittlerweile Gosmacs kommerziell erworben hatte, wieder
entfernt und neu implementiert. Ob "GNU Emacs" heute noch genauso mit
einer Lücke arbeitet, weiß ich nicht.
Offenbar ja: Nch kurzem Googlen finde ich folgendes:
http://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html
GNU Emacs scheint ebenso mit der Lücke (gap) zu arbeiten... da haben wir
ja noch ein paar hunderttausend bis Millionen Anwender mehr ;-)
Frank M. schrieb:>> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die>> Lücke fällt.>> Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle> steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb> eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000> und dann 8000.
Selbst wenn: Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs
aktuellen PC kein Ding.
Yalu X. schrieb:> Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs> aktuellen PC kein Ding.
So ist es. Und man springt ja nicht dauernd vom Anfang zum Ende und
wieder zurück. Und selbst wenn, wird noch lange nicht die Lücke
verschoben. Verschoben wird sie erst, wenn ich auch tatsächlich an
entfernter Stelle eine Textmanipulation vornehme.
Frank M. schrieb:> Alle anderen Editierfunktionen werden analog implementiert, auf eine> zeilenorientierte Speicherstruktur kann komplett verzichtet werden.
Solch einen Editor (in der Art) hab ich damals (tm) in Z80-Assembler
geschrieben. Hat wirklich sehr effizient funktioniert.
Nachtrag: Heute würde ich es nicht wieder in Assembler machen. ;)
Wie schnarchlangsam zeilenorientierte Editoren arbeiten, kann man
einfach nachprüfen, wenn man XXX mal auf 640 MB vergößert.
1
head -c640M /dev/zero | tr "\000" "\n" >XXX
Dann startet man seinen Wunscheditor und drückt sofort die erforderliche
Tastenkombination, um den Editor wieder zu verlassen:
1
$ time fe XXX
2
real 0m3.046s
3
user 0m2.930s
4
sys 0m0.116s
5
6
$ time vi XXX
7
real 0m12.316s
8
user 0m11.648s
9
sys 0m0.668s
10
11
$ time nano XXX
12
real 0m56.437s
13
user 0m46.112s
14
sys 0m10.324s
Einen Kommentar kann ich mir dazu mal sparen, nano säuft jedenfalls
gnadenlos ab. Auch die sys-Zeit, welche angibt, wie lange die Anwendung
den Kernel beansprucht, ist unterirdisch.
P.S.
Getestet unter Linux mit
- AMD Ryzen 9 3900 (12 Kerne)
- 128 GB RAM
- 2x Samsung SSD PM983 1.92TB im Soft-Raid 1
Frank M. schrieb:> Dann startet man seinen Wunscheditor und drückt sofort die erforderliche> Tastenkombination, um den Editor wieder zu verlassen:
Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg? (Wäre auf
jeden Fall standardisierter).
Da es neovim auch für Windows gibt, dachte ich, den schau ich mir mal
genauer an, weil das beim Watcom Vi mit den Plugins nicht so toll ist.
Nicht grundsätzlich aber für Neovim gibt es so nette Sachen und Lua
Programming.
Außerdem wird schon ein Plugin Manager empfohlen, da fühlt man sich fast
wie bei Skyrim wo manche nicht vor > 300 Mods loslegen können.
Auf die schnelle Gucken war aber auch erstmal nix, weil offenbar eine
dll vergessen wurde, dem Packet beizulegen - oder wenigstens ein Readme
diesbezüglich.
Bei gvim geht das alles schon lange viel problemloser.
(bei cygwin auch)
Bei den Plugins für neovim sieht man oft Begleitbefehle für die
Powershell. Da fragt man sich auch, was soll das. Können die Leute keine
normale Windowskonsole mehr benutzen?
rbx schrieb:> Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg?
Ich habe bei vi einfach ":q[CR]" gedrückt, ohne die Gänse. Da die
Ladezeit immer die Tastendruck-Zeit übertraf, hat das auch keine Rolle
gespielt.
Das kann man auch ganz gut daran erkennen, dass in allen 3 Fällen
ziemlich genau
Frank M. schrieb:> Dann startet man seinen Wunscheditor und drückt sofort die erforderliche> Tastenkombination, um den Editor wieder zu verlassen:>
1
> $ time fe XXX
2
> real 0m3.046s
3
> user 0m2.930s
4
> sys 0m0.116s
5
>
6
>
Und wie soll die Zukunft deines fe Editors aussehen?
Proprietärer Code neigt dazu, sofern er nicht in einem Unternehmen über
mehrere Generationen hinweg weitergepflegt wird, zu sterben.
rbx schrieb:> Bei den Plugins für neovim sieht man oft Begleitbefehle für die> Powershell. Da fragt man sich auch, was soll das. Können die Leute keine> normale Windowskonsole mehr benutzen?
Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,
aber nicht wollen. Die Powershell kann laut deren Aussage an vielen
Stellen deutlich mehr.
Ein T. schrieb:> Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,> aber nicht wollen. Die Powershell kann laut deren Aussage an vielen> Stellen deutlich mehr.
Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super
mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht.
Windows funktioniert anders als Linux, man sucht sich erstmal zusammen,
was man so gebrauchen kann, wie z.B. die Sysinternals Programme.
(oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu
compilieren)
rbx schrieb:> Ein T. schrieb:>> Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,>> aber nicht wollen. Die Powershell kann laut deren Aussage an vielen>> Stellen deutlich mehr.>> Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super> mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht.> Windows funktioniert anders als Linux, man sucht sich erstmal zusammen,> was man so gebrauchen kann, wie z.B. die Sysinternals Programme.>> (oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu> compilieren)
Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser"
fundamental von der meinen unterscheidet. Ich rede da von (und mit)
Profis, weißt Du, und die sagen mir alle, daß die Powershell nicht nur
so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe.
Ein lieber Segelfreund von mir ist etwa spezialisiert auf MS Exchange,
früher bei IBM und heute bei Microsoft. Der sagt, daß er früher meistens
die GUI des Exchange-Servers und manchmal außerdem RegEdit benutzt hat,
und mittlerweile nur noch die Powershell benutzt -- weil er damit viel
schneller, sicherer und vor allem auch reproduzierbarer zum Ziel kommt.
Ein anderer Mitsegler ist bei MS Deutschland im Azure-Bereich tätig und
erzählt mir ganz Ähnliches.
Klar, wenn die wesentlichsten und wichtigsten Tätigkeiten am Computer
sich auf Spiele und etwas... exotischere Hobbies wie die von Dir
genannten C-Compiler beschränken, dann wird man die Leistungsfähigkeit
einer modernen Kommandozeile natürlich weder benötigen noch zu schätzen
wissen. Das ist auch nicht schlimm.
Aber darüber zu lästern und zu unterstellen, die Leute würden die
Powershell nur benutzen, weil sie zu blöd für die klassische cmd.exe
wären, das geht mir dann doch ein bisschen zu weit. Wie gesagt, Du hast
halt keinen Bedarf nach einer modernen, leistungsfähigen Kommandozeile,
und deswegen offensichtlich auch weder Erfahrung damit noch eine Ahnung
davon, was die Powershell kann.
Aber gräm' Dich nicht, in diesem Forum bist Du da in guter Gesellschaft:
es gibt hier viele Leute, die alles ablehnen, das sie nicht verstehen
(wollen), von der Objektorientierung über Skriptsprachen bis hin zu
modernen Kommandozeilen, von Machine Learning über Fuzzy Logic bis hin
zu bewährten Editoren... q.e.d. ;-)
Ein T. schrieb:> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.
Sie kann mehr, macht aber alles anders, und vor allem kann sie
Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich
schmerzlich feststellen.
Jörg W. schrieb:> Ein T. schrieb:>> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.>> Sie kann mehr, macht aber alles anders, und vor allem kann sie> Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich> schmerzlich feststellen.
Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!
Das ist eine ganz andere Philoshopie.
Nano schrieb:> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!
Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein
generischer Ersatz für ein cmd.exe sein kann und/oder will.
Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset
von cmd.exe sei. Ist sie halt nicht.
Ein T. schrieb:> und die sagen mir alle, daß die Powershell nicht nur> so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe.
Das ist allerdings auch keine große Kunst.
Ein T. schrieb:> Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser"> fundamental von der meinen unterscheidet.
Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun?
Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden
wird.
Sicher kann die einiges, aber vergleichen würde ich das, was die
Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit
konnte man auch viel machen.
Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm.
Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm
zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim??
Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen
auf Spatzen schießen.
Die Powershell könnte man auch mit einem interaktiven Interpreter (z.B.
Python-Shell) vergleichen. Eine Posix-Shell möchte sie ja offenkundig
nicht sein.
Ich höre über die Powershell auch nur gutes, auch von wenig MS-affinen
Personen.
Da ich damit aber kaum gearbeitet habe kann ich das weder bejajen noch
verneinen.
Um wirklich krasses Zeugs damit machen zu können braucht man wohl auch
etwas .NET-Background.
Nano schrieb:> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!> Das ist eine ganz andere Philoshopie.
Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan
(sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind.
Jörg W. schrieb:> Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein> generischer Ersatz für ein cmd.exe sein kann und/oder will.
Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf
ausgelegt, .NET-Objekte zu verknüpfen. Wenn dies das Designziel war,
dann sollte und wird sie gar kein generischer Ersatz für cmd.exe sein.
> Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset> von cmd.exe sei. Ist sie halt nicht.
Diese Implikation war von mir keineswegs intendiert, und vermutlich auch
nicht von jenen Leuten, die mir von der Powershell erzählt haben.
rbx schrieb:> Ein T. schrieb:>> Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser">> fundamental von der meinen unterscheidet.>> Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun?> Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden> wird.
Du hattest den Begriff "Poweruser" eingebracht, nicht ich.
> Sicher kann die einiges, aber vergleichen würde ich das, was die> Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit> konnte man auch viel machen.
Wen ich mich recht entsinne, waren VB, VBA und VBS aber niemals
interaktiv. Aber die Powershell ist genau das: eine interaktive Shell.
> Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm.> Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm> zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim??> Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen> auf Spatzen schießen.
Unter den meisten Linux-Systemen gibt es bereits sehr moderne,
leistungsfähige Shells, und das .NET-Framework, auf das die Powershell
zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären
Ansätzen. Insofern stellt sich mir gerade die Frage, wie Du darauf
kommst, daß jemand die Powershell unter Linux benutzen wollen würde --
erst Recht zur Konfiguration von neovim?!
Ein T. schrieb:> Nano schrieb:>> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!>> Das ist eine ganz andere Philoshopie.>> Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan> (sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind.
Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf
anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und
Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Auch der Austausch von komplexen Datenstrukturen ist textbasiert
natürlich etwas schwieriger.
Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein
Einwand inhaltlich richtig, wenn auch nicht unbedingt berechtigt.
Ein T. schrieb:> und das .NET-Framework, auf das die Powershell> zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären> Ansätzen
Veto.
Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht
schlechter) läuft (als unter Windows) ;-)
Ein T. schrieb:> Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf> ausgelegt, .NET-Objekte zu verknüpfen.
Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der
ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass
sie unbrauchbar werden (irgendwelches Padding eingefügt).
Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle
ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur
.NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind.
Le X. schrieb:> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und
"Daten" gibt es dort sowieso nicht, entsprechend ist es auch völlig
egal, ob ich lesbare Texte oder irgendwelche Binärklumpen dort durch die
Kante schiebe. Das funktioniert einfach™-
Jörg W. schrieb:> Le X. schrieb:>> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf>> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und>> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.>> Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und> "Daten" gibt es dort sowieso nicht
Wieso schneidest du beim Zitieren denn meinen essentiellen Satz ab?
Sorry, aber das ist ganz mies, sowas brauchts echt nicht.
Ich hab extra für die ganz-päpstliche Fraktion klargestellt:
Le X. schrieb:> Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein> Einwand inhaltlich richtig,
Aber ein Textinterface funktioniert halt in der Praxis ganz anders als
ein Interface mit definierten Objekten aus einem systemweiten Framework,
und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon
sehr schwierig (weswegen Dinge wie xml und json erfunden wurden).
Bei Text muss halt Tool A den Output von Tool B genau parsen können,
notfalls muss man mit Tools C, D und E den Zwischenoutput umformen.
Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar:
> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Ich sehe schon dass der Powershell-Ansatz hier interessante Ansätze hat.
Darauf wollte nano wohl hinaus, auch wenn er's mal wieder geschafft hat
das sehr unglücklich zu formulieren.
Die Diskussion ob Texte auch Daten sind müssen wir aber wirklich nicht
führen.
Le X. schrieb:> Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar:>> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Das hat den Hintergrund, dass ›apt‹ für die direkte Verwendung gedacht
ist, während es zum Scripten dafür geeignete Komponenten gibt, die man
anstelle von ›apt‹ nutzen sollte.
Le X. schrieb:> Le X. schrieb:>> Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein>> Einwand inhaltlich richtig,>> Aber ein Textinterface funktioniert halt in der Praxis ganz anders als> ein Interface mit definierten Objekten aus einem systemweiten Framework,> und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon> sehr schwierig (weswegen Dinge wie xml und json erfunden wurden).> Bei Text muss halt Tool A den Output von Tool B genau parsen können,> notfalls muss man mit Tools C, D und E den Zwischenoutput umformen.
Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann
(zumindest unter unixoiden Systemen), nicht nur Text. Das kann man z.B.
bei einem tar.gz-Archiv sehen. Das lässt sich z.B. so erzeugen:
1
tar c mydir | gzip > mydir.tar.gz
Früher, bevor tar selbst gzip aufrufen konnte, musste man es sogar in
der Art schreiben. Der Output von tar besteht nicht aus Text, und der
von gzip erst recht nicht.
Rolf M. schrieb:> Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann> (zumindest unter unixoiden Systemen), nicht nur Text.
So ist es (und so funktioniert es ja auch in cmd.exe), niemand hat
jemals festgelegt, dass eine Pipe nur für Strings da wäre. Daher hatte
ich das Zitat auch eingekürzt (weil ich die Unterscheidung nicht einmal
verstanden habe).
Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das
eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn
beide aus der .NET-Welt sind, dann sind das halt wie auch immer
serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die
nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen
sollte.
Aber gut, wir hatten die Diskussion schon, ich weiß, dass die Powershell
offenbar nur für .NET-Freunde richtig Sinn hat und weiß sie zu meiden.
Mit .NET habe ich eh nichts weiter am Hut.
Ein T. schrieb:> Insofern stellt sich mir gerade die Frage, wie Du darauf> kommst, daß jemand die Powershell unter Linux benutzen wollen würde --> erst Recht zur Konfiguration von neovim?!
Eher so: Warum benutzen Linuxer nicht die normale Shell (CMD) oder
wenigstens einer der normalen Alternativen dazu?
Da gibt es ja einige. Ich fand es z.B. recht interessant, debug auch in
der Cygwin Konsole aufrufen zu können.
Mit Cygwin geht so einiges, sicher nicht alles, aber man kann seinen
Spaß haben.
Mit dem ghci oder dem Watcom Vi in der Powershell zu arbeiten, ist
dagegen eher nervtötend.
Möglicherweise hatte ich mich bei dem Plugs auch etwas verguckt..
https://github.com/junegunn/vim-plug#installation
Le X. schrieb:> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Das scheint für die Powershell auch zu gelten, wenn ich die Ausführungen
von Jörg Wunsch zu diesem Thema lese. Er berichtete diesbezüglich von
Schwierigkeiten mit Wireshark, wenn ich mich recht entsinne.
> Auch der Austausch von komplexen Datenstrukturen ist textbasiert> natürlich etwas schwieriger.
Kommt halt darauf an. Die textbasierte Weitergabe hat den großen
Vorteil, daß sie ausgesprochen flexibel ist und man mit Werkzeugen wie
grep(1), sed(1), awk(1) etc manipulieren kann (und manchmal muß), was
auf der Empfängerseite ankommt. Wie die erfahreneren Nutzer von
unixoiden Pipes wissen, kann das bisweilen in ziemlich... aufwändigen
Reformatierungen münden, die bei größeren Datenmengen durchaus auch
manchmal zeit- und ressourcenaufwändig sein können.
Wenn man wie Microsoft hingegen ein Framework wie .NET hat, mit dem man
die meisten Funktionen des Systems und der eigenen Applikationen nutzen
kann, dann macht das mit der Weitergabe von Objekten dieses Frameworks
natürlich Sinn. Das heißt aber auf der anderen Seite allerdings auch,
daß die verwendeten Komponenten mit den Objekten des Frameworks
umzugehen wissen.
Die Grundfunktion -- nämlich die Aus- oder Rückgabe einer Komponente als
Eingabe einer anderen Komponente zu verwenden und die einzelnen
Komponenten so flexibel zu einer komplexeren Funktionalität zu verbinden
-- ist insofern im Kern dieselbe. Nur die Umsetzung ist bei den beiden
Lösungen ganz unterschiedlich realisiert.
> Ein T. schrieb:>> und das .NET-Framework, auf das die Powershell>> zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären>> Ansätzen>> Veto.> Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht> schlechter) läuft (als unter Windows) ;-)
Das mag sein, davon habe ich keine Ahnung und verlasse mich daher gerne
auf Deine Aussage. Tatsache ist allerdings, daß ich um Software, bei der
Miguel De Icaza die Finger im Spiel hatte, lieber einen großen Bogen
mache. ;-)
Jörg W. schrieb:> Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der> ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass> sie unbrauchbar werden (irgendwelches Padding eingefügt).
Wenn einem so etwas begegnet, ist das sicherlich ärgerlich. Womöglich
gibt es für solche Fälle sogar einen Workaround?
> Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle> ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur> .NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind.
Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine
Software läuft, welche nicht .NET-fähig ist?
Ein T. schrieb:> Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine> Software läuft, welche nicht .NET-fähig ist?
Keine Ahnung, was sie sich überhaupt dabei gedacht haben. Ich vermute ja
mal, dass das gar nicht so sehr mit .NET zusammenhängt, sondern dass sie
nur versuchen, da irgendwelche Zeichensatz-Konvertierungs-Geschichten
drauf anzuwenden. Mir genügte es dann, den Schuldigen gefunden zu haben
und zu meiden. (Absender war bei mir ein Python-Script, der .pcap
erzeugt, Empfänger Wireshark. Abspeichern der .pcap-Datei per
Ausgabeumlenkung hat sie genauso verhunzt.)
Jörg W. schrieb:> Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das> eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn> beide aus der .NET-Welt sind, dann sind das halt wie auch immer> serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die> nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen> sollte.
Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder
nur Zeiger auf Objekte, die in einer Art Shared Memory liegen. Damit
könnte man sich den ganzen Aufwand mit Serialisierung und
Deserialisierung sparen. Keine Ahnung, ob Microsoft das in der
Powershell so implementiert hat, aber clever wär's.
Ein T. schrieb:> Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder> nur Zeiger auf Objekte, die in einer Art Shared Memory liegen.
Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand
an so einem Agreement nicht teilnimmt und in dem Falle entweder die
Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen.
Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle
Option.
(Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in
einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch
ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das
ganz normale VM-System das bereits kann.)
Noch einmal 2 Fragen zu vim:
1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl
ausgeben?
Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es
nett, wenn man nicht selber zählen muss.
2. Nochmal meine Frage von weiter oben.
Wie damals bereits gesagt, habe ich youcompleteme installiert:
1
apt search ^vim-youcompleteme
2
Sortierung… Fertig
3
Volltextsuche… Fertig
4
vim-youcompleteme/stable,now 0+20200825+git2afee9d+ds-2 all [installiert]
5
fast, as-you-type, fuzzy-search code completion engine for Vim
Ein T. schrieb:> Tipp für größere Archive:> tar c mydir | pigz > mydir.tar.gz>> HF! ;-)
Kenn ich. Und wenn man stärker komprimieren will per bzip2, kann man zum
Beschleunigen pbzip2 verwenden. Bevor ich clonezilla entdeckt habe, hat
mir das deutlich geholfen beim Komprimieren von 500GB-Festplatten-Images
:)
Ein T. schrieb:> Keine Ahnung, ob Microsoft das in der> Powershell so implementiert hat, aber clever wär's.
Naja, dann muss das ganze ja auch irgendwie über Prozessgrenzen hinweg
verwaltet werden, und Zugriffe müssen synchronisiert werden. Durch das
Kopieren umgeht die Pipe solche Probleme komplett.
Nano schrieb:> Noch einmal 2 Fragen zu vim:>> 1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl> ausgeben?
Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro
stecken, um es direkt nutzen zu können.
Navigiere zum ersten " des Strings, dann:
yt"
:echo strlen(<C-r>")
(<C-r> steht für Ctrl und r)
> Aber vim-addons zeigt an:> vim-addons> # Name User Status System Status> apparmor removed removed> editexisting removed removed> espeak removed removed> justify removed removed> matchit removed removed> youcompleteme removed removed>> Und wie nutze ich das jetzt?
Jörg W. schrieb:> Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand> an so einem Agreement nicht teilnimmt und in dem Falle entweder die> Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen.>> Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle> Option.
Naja... hätte, wäre, wenn. Anscheinend war das wohl nicht gewollt oder
jedenfalls nicht vorgesehen. Da müßte man die Entwickler fragen, warum
sie das nicht gemacht haben und ob es eventuell Workarounds gibt.
> (Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in> einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch> ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das> ganz normale VM-System das bereits kann.)
Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über
physikalische Dateien, mithin über den Dateisystempuffer arbeiten
würden. Keine Ahnung, ob das stimmt, oder ob meine Erinnerung mich
womöglich trügt.
Nano schrieb:> Wie damals bereits gesagt, habe ich youcompleteme installiert:> [...]> Und wie nutze ich das jetzt?
Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast,
ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits
gefunden. Na, dann benutz' die doch einfach.
Ein T. schrieb:> Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über> physikalische Dateien, mithin über den Dateisystempuffer arbeiten> würden.
Nö, intern (zumindest im BSD, in Linux kenne ich mich nicht aus)
arbeiten sie genauso wie local domain sockets. Sind also eigentlich
bidirektional, allerdings ist dieses Feature nicht portabel.
Könnte sein, dass sowas wie command.com das mal mit Dateien emuliert
hat, oder war's die microshell auf CP/M?
Rolf M. schrieb:> Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro> stecken, um es direkt nutzen zu können.> Navigiere zum ersten " des Strings, dann:> yt"> :echo strlen(<C-r>")>> (<C-r> steht für Ctrl und r)
Ja du hast recht, das ist umständlich, aber:
>
1
> vim-addons install youcompleteme
2
>
youcompleteme, wenn es per vim-addons install dann eingerichtet ist,
danke für den Hinweis, zeigt automatisch an, wenn ein String, der einem
char Array zugewiesen wird zu klein ist. Das ist also sogar noch besser.
Ändern müsste man nur die Farbe, rosa Schrift auf rotem Hintergrund ist
schlecht lesbar.
> Ich musste noch zusätzlich folgendes tun:>
1
> sudo apt install python3-distutils
2
>
Das wurde bei mir automatisch mitinstalliert und war schon drauf.
Ein T. schrieb:> Nano schrieb:>> Wie damals bereits gesagt, habe ich youcompleteme installiert:>> [...]>> Und wie nutze ich das jetzt?>> Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast,> ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits> gefunden. Na, dann benutz' die doch einfach.
Nur weil ich etwas ausprobieren will, heißt das nicht, dass ich das dann
dauerhaft benutzen will.
Und youcompleteme ist nicht vim, sondern ein Addon zu vim. Das ist ein
großer Unterschied!
Nano schrieb:> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es> nett, wenn man nicht selber zählen muss.
Könnte man aber auch einer Suchmaschine fragen:
https://vim.fandom.com/wiki/Word_count
rbx schrieb:> Nano schrieb:>> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es>> nett, wenn man nicht selber zählen muss.>> Könnte man aber auch einer Suchmaschine fragen:>> https://vim.fandom.com/wiki/Word_count
Da steht nirgends etwas von "word count between """ und das war ja meine
Frage.
Um eine generelle Zeichenzählung geht es ja gerade nicht.
Und ja, sicher kann man das wie oben mit etwas mehr Eingabeparametern
dann auch irgendwie hinbiegen, aber diese aufwendigere Methode zeigt
dann auch, dass das Zeichenzählen zwischen zwei "" nicht explizit
vorgesehen war.
Und das wollte ich wissen ob es da entsprechendes gibt.
Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert
hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim), wäre
dir sicher aufgefallen, dass beim Markieren mit v, shift-V oder ctrl-V
die Größe des markierten Bereichs in der Statuszeile angezeigt wird.
Also markierst du einfach den String mit vi" (s. mein Beitrag weiter
oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der
String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als
auch in Bytes angezeigt.
Nano schrieb:> zeigt dann auch, dass das Zeichenzählen zwischen zwei "" nicht> explizit vorgesehen war.
Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die
nicht explizit vorgesehen sind, nämlich durch das Kombinieren von
Operatoren, Motions usw.
Yalu X. schrieb:> Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert> hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim),
Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich
schon längst vim installiert habe.
> Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die> nicht explizit vorgesehen sind, nämlich durch das Kombinieren von> Operatoren, Motions usw.
Lies oben nochmal und verstehe was ich geschrieben habe.
Nano schrieb:> Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich> schon längst vim installiert habe.
Und die Länge des markierten Bereichs hat er nicht angezeigt?
Yalu X. schrieb:> Also markierst du einfach den String mit vi" (s. mein Beitrag weiter> oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der> String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als> auch in Bytes angezeigt.
Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16
Bytes raus, was falsch ist. Richtig wären 15 Bytes (da \n in dem String
ein Zeichen ist, aber im Quellcode aus zweien besteht und daher in
diesem Fall auch so gezählt wird). Die von mir gezeigten Methode bekommt
das korrekte Ergebnis raus.
Rolf M. schrieb:> Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16> Bytes raus, was falsch ist.
Ok, die angezeigte Länge berücksichtigt keine Escape-Backslashes. Diese
muss man selber von der angezeigten Länge subtrahieren, falls es sich um
ein C-Stringliteral handelt.
Suchmaschine spukt u.a. aus:
wc -m
g Strg G
vimscript
Bei letzten Punkt denkt man dann: neovim? Lua!
(war das mit der fehlenden dll für Windows nur ein Fettnäpfchen? Leider
nicht, das wurde wohl gezielt so anvisiert, im Sinne von
Nutzplattformfokussierung bzw. -beschränkung)
(xkcd bzw. Randall Munroe erinnert recht stark an die Tagebücher und
Briefe oder andere Schriften von Georg Christoph Lichtenberg
https://de.wikipedia.org/wiki/Sudelb%C3%BCcher )
vim vs emacs?
Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher
als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder
ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass
mehr Erklärung notwendig ist?
willi schrieb:> vim vs emacs?>> Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher> als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder> ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass> mehr Erklärung notwendig ist?
Ohne diesbezüglich Daten erhoben und analysiert zu haben, würde ich das
als Indiz werten, daß der vi(m) schon deswegen häufiger genutzt wird,
weil er auf unixoiden Systemen so ziemlich immer vorhanden ist. Außerdem
gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von
einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.
Stallman himself.
Ein T. schrieb:> Außerdem> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.> Stallman himself.
wann hat er diese Dokumentation geschrieben? ;-)
Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.
VimScript. (war wohl doch nicht gut durchdacht)
spricht eher dafür schrieb:> Ein T. schrieb:>> Außerdem>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.>> Stallman himself.>> wann hat er diese Dokumentation geschrieben? ;-)
Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber
die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The
Extensible, Customizable, Self-Documenting Display Editor", stammt von
1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen
Jahren heißt es "GNU Emacs Reference Manual" [3].
Auch wenn mir nicht ganz klar ist, was Du mit Deiner Frage bezweckst, so
hoffe ich doch, sie hinreichend informativ beantwortet zu haben.
[1] https://dl.acm.org/doi/book/10.5555/888850
[2]
https://books.google.de/books/about/GNU_Emacs_Manual.html?id=v3QZAQAAIAAJ&redir_esc=y
[3] https://www.amazon.de/GNU-Emacs-24-5-Reference-Manual/dp/9888381954> Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.> VimScript. (war wohl doch nicht gut durchdacht)
Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal
wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die
Software eben auch mal umbauen, um die Anforderungen abdecken und die
neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und
Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine
Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die
Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht
gewesen, erscheint mir daher vollkommen verfehlt.
Jörg W. schrieb:> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich> ging's ja die ganze Zeit um vim vs. nano.
Nein, darum ging es nie. Es gab hier lediglich vim Fanboys, wie man dies
und das in nano löst. Es war am Ende also ein nano only Thread.
Nano schrieb:> Jörg W. schrieb:>> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich>> ging's ja die ganze Zeit um vim vs. nano.>> Nein, darum ging es nie. Es gab hier lediglich vim Fanboys *, wie man dies> und das in nano löst. Es war am Ende also ein nano only Thread.
Satz vergessen:
*die wissen wollten.
Ein T. schrieb:> und dann muß man die> Software eben auch mal umbauen
aber nicht die Programmiersprache. Lisp ist die beste Programmiersprache
der Welt und darum wird emacs da nie was ändern (müssen).
Und VimScript ist ein Ding, dass außer Vim keine Bedeutung hat und eine
komische Syntax verwenden. Und auch darum ist NeoVim besser: Dort wird
VimScript durch Lua ersetzt.
Emacs ist da wirklich konsequent und besser. Aber diese
Tastenkombinationen....
Ein T. schrieb:>> Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.>> VimScript. (war wohl doch nicht gut durchdacht)>> Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal> wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die> Software eben auch mal umbauen, um die Anforderungen abdecken und die> neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und> Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine> Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die> Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht> gewesen, erscheint mir daher vollkommen verfehlt.
Das Referenzbeispiel hier ist aber eher Elvis.
( http://elvis.the-little-red-haired-girl.org/ )
Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober
der viel besser auf Windows läuft, als neovim.
rbx schrieb:> Das Referenzbeispiel hier ist aber eher Elvis.>> ( http://elvis.the-little-red-haired-girl.org/ )>> Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober> der viel besser auf Windows läuft, als neovim.
Unter Windows läuft der Elvis in der Version 2.2. Der ist von den
Features
auch heute noch top!
Mir gefällt auch der WinVi: http://www.winvi.de/de/scrnshts.html
Der hat auch einen Hex Editor eingebaut.
Beide werden leider seit über 10 Jahren nicht mehr weiterentwickelt.
Beide (genauso wie der Original vi) verstehen die hier
als Beispiele gezeigten Befehle nicht.
1
gg - geht nicht
2
da" - geht nicht
3
va" - geht nicht
vi ist also auch nicht vi.
Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen"
nicht dabei. Auch fehlen etliche externe Libs.
Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr
als 100k Zeilen aber irgendwas falsch.
Ein T. schrieb:> spricht eher dafür schrieb:>> Ein T. schrieb:>>> Außerdem>>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von>>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.>>> Stallman himself.>>>> wann hat er diese Dokumentation geschrieben? ;-)>> Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber> die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The> Extensible, Customizable, Self-Documenting Display Editor", stammt von> 1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen> Jahren heißt es "GNU Emacs Reference Manual" [3].
Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL
erfunden hat.
rbx schrieb:> Das Referenzbeispiel hier ist aber eher Elvis.>> ( http://elvis.the-little-red-haired-girl.org/ )
Sehr schön. Elvis war schon Anfang der 90er für mich ein abschreckendes
Beispiel für einen Editor unter Linux. Habe ihn dann trotzdem
gelegentlich genutzt weil immer vorhanden. Später habe ich ihn dann nie
mehr gefunden. Auch nicht die Website. Deshalb danke für die Verlinkung.
udok schrieb:> Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen"> nicht dabei. Auch fehlen etliche externe Libs.> Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr> als 100k Zeilen aber irgendwas falsch.
Die neuste Version von vim ist auch schon ganz schön fett geworden.
udok schrieb:> Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr> als 100k Zeilen aber irgendwas falsch.
Ich muss gestehen das ich mir noch nie die Anzahl der Zeilen Sourcecode
angesehen habe um eine Pro/Contra Entscheidung zu treffen.
Ich fand's immer recht angenehm wenn der Editor mich einfach meine
Arbeit machen ließ.
Ein T. schrieb:> Außerdem> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.> Stallman himself.
Original-Dokus sind oft schwer verständlich und didaktisch eine halb-
bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.
Heinz schrieb:> Original-Dokus sind oft schwer verständlich und didaktisch eine halb-> bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.
und der Quellcode erst..
Stallmann meinte mal er hatte den Algoteil (der mit dem Totenkopf in der
Originalquelle) noch viel eleganter bzw. smarter hinbekommen.
Man stelle sich den Emacs Assembler-Optimiert vor, mit allem was man da
heute so hat, mit Profiler einsteigen, Algoschinken, Rip-Mode, SSE, AVX
(por Reg (String drin) 20h)(Alternative, OR AH, 20h) viele 64 Bit
Register, Cuda als Rechenhilfe (also sowas wie Excel - Ersatz bzw. der
neue Emacs- "Excel-Mode") und dann auch noch "Cloud-Optimierung" mit
richtig guten Leuten..
Ansonsten scheinen ja keine Dokumentation (etwa wie bei Grafikkarten
oder bei ARM hier und da), nur teilweise Dokumentation oder erbärmliche
Dokumentation recht beliebt zu sein.
Naja, wenn man das Know How hat und den Grips und eine gute
Uniausbildung/UniBib auch noch, hat man zumindest einen
Wettbewerbsvorteil.
Vimscript ohne populäre Schnittstelle hat zumindest den Vorteil, nicht
gleich wie mit Java an die Wand fahren zu müssen, oder mit neovim
gewissermaßen Skyrim heavily-modded zu spielen.
Der Cloud-Gedanke, bzw. das was Stallmann meint, ist ja so schlecht
nicht, wenn man z.B. an die Automagie beim Start von Knoppix denkt, oder
an den Emacs (der "Ersatzdesktop") bei Cygwin.
Bei Cygwin ist (oder war, keine Ahnung) auf jeden Fall der Emacs der
beste Editor ;)
(da kann glaube ich auch kein WSL mithalten)
Bei Fedora Workstation beschäftigt mich auch die Frage, Vim oder Neovim?
Viel fesselnder finde ich aber die Frage, wie Neovim in Windows
compilieren?
Mit Watcom 32 Bit sollte das schon mal (weitgehend) reibungslos gehen.
Spannender wird es bei 64 Bit.
Wie weit kommt man mit Open Watcom V2?
Aber neovim als 16-Bit Variante wäre meiner Meinung nach auch nicht so
verkehrt. Back to the roots - würde ich mal so sagen.
(das wäre dann z.B. Neovim für DOSBox)
(könnte man statt Lua den C-Script Support vom Tiny C Compiler benutzen.
Aber ach, der ist ja auch so 32 Bit..)
Na, alles nicht so einfach..
https://stackoverflow.com/questions/3827370/hEin T. schrieb:> rbx schrieb:>> Suchmaschine spukt u.a. aus:>> In Deiner Suchmaschine spukt es? 8-O
Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,
hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so
körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das
hat natürlich auch gewisse Vorteile, z.B. wenn man als Anrufer (wie ein
echter Engel) bevorzugt wird in der ansonsten körperlich anwesenden
Wartesschlange.
Hier noch Infos zum Speicherverbrauch und zur Suche unter Windows 10.
Gemessen mit ProcessHacker.
Der gvim ist auch unter Windows ein guter Allrounder - wenn man ihn
bedienen kann...
Interessanterweise ist auch der Notepad - über denn ja jeder lästert -
vorne dabei.
Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze
100MByte File in den Speicher holt. Bei der Suche kackt er aber ab.
Alle anderen sind abgeschlagen.
Wordpad und Word sind abgeschlagen, aber die konvertieren das Format
intern um, und haben daher einen ordentlichen Nachteil.
1
Peak Speicherverbrauch beim Öffnen von 100 Megabyte File mit 10 Millionen
2
Zeilen (Zahlen von 000000000 - 009999999)
3
=> File Öffnen und Suchen des Strings 009999999, OS = Win 10
udok schrieb:> Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze> 100MByte File in den Speicher holt. Bei der Suche kackt er aber ab.>> Alle anderen sind abgeschlagen.
Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am
Speicherbedarf zu messen.
Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei
WinVi, Speicher nicht nutzt obwohl er vorhanden ist.
Wichtig ist nur, dass er selbst für sich nicht viel braucht, also
schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal
etwas editieren" ist.
Ich hatte, wie bereits gesagt, noch nie die Notwendigkeit solche großen
Dateien mit Texteditoren zu öffnen.
Was ich schonmal öffnen musste, war eine große Datendatei, für so etwas
nutze ich aber einen Hexeditor und da sind drei Kriterien wichtig:
1. Kann der Hexeditor größere Dateien öffnen und bearbeiten als RAM
vorhanden ist?
2. Nutzt er für die Bearbeitungsfunktionen das RAM oder lässt er es
brach liegen.
3. Kann er auf solche in 1 beschriebenen Dateien auch Search and Replace
anwenden ohne auszusteigen? Leider scheiterten da viele HexEditoren, die
damit warben, unlimitiert große Dateien öffnen und bearbeiten zu können.
Die S&R Funktion ist wohl leider oft so implementiert, dass hier dann
nicht an den Speicherbedarf gedacht wird. Vermutlich rührt das daher,
dass im RAM zuerst eine Datentstruktur aller gefunden Matches aufgebaut
wird und dann der Nutzer gefragt wird, was er mit diesen jeweils einzeln
oder auf alle angewendet machen möchte. Und hier steigen viele
Hexeditoren dann aus, weil kein RAM mehr vorhanden ist und die aber mehr
brauchen um die Sucheinträge unterzubringen.
> Visual Studio 2008 | 445 | 10.8> Visual Studio 2022 | 616 | 149.8
Wer eine 100 MiB große Quellcodedatei in eine IDE lädt, der macht etwas
falsch.
Nano schrieb:> Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am> Speicherbedarf zu messen.> Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei> WinVi, Speicher nicht nutzt obwohl er vorhanden ist.>> Wichtig ist nur, dass er selbst für sich nicht viel braucht, also> schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal> etwas editieren" ist.
Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.
Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.
Startupzeit ist sicher ein weiteres wichtiges Kriterium.
Einfache intuitive Bedienung und Integration ins OS ist auch wichtig,
An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie
gewöhnen. Schon interessant und frustrierend, das es nach >50 Jahren
Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.
udok schrieb:> An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie> gewöhnen.
Du kannst Dir die Tastaturbelegung doch beliebig umbasteln :)
Ich finde es eher nervig, dass die GVIM packager für Windows immer ein
"Windowsuseraugliches" Keymapping aktivieren. Aber das kann man ja zum
Glück auch wieder rausschmeissen ;)
/regards
Ich benutze den vim in der Geschmacksrichtung "cream", das läuft auch
unter wine. Für AVR-Assembler habe ich allerdings eine
Syntax-highlighting-Datei im Web suchen müssen, die war nicht dabei.
Schon von 2005, ist hier angehängt.
Aber Geany kann es auch, in letzter Zeit habe ich den Cream nicht mehr
benutzt.
Ich habe geany mit gedit verwechselt. Dort heißen die syntax-Dateien
(xml) ".lang" und liegen unter
/usr/share/gtksourceview->Version>/language-specs
Speziell AVR habe ich nicht, aber mit "asm.lang" sieht es schon
einigermaßen korrekt aus.
Mit cream ist die Druckereinstellung etwas umständlich. Ich habe es für
den PDF-Druck in mir angenehme Form eingerichtet.
Karl Otto II. schrieb:> Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL> erfunden hat.
Das stimmt, die Dokumentationen [1] unterliegen der GNU Free
Documentation License [2]. Die GFDL ist die Lizenz des GNU-Projekts für
Dokumentationen.
Irgendwie beschleicht mich das Gefühl, daß Du mir etwas sagen möchtest.
Aber leider komme ich nicht darauf, was das sein könnte.
[1] https://www.gnu.org/software/emacs/manual/
[2] https://www.gnu.org/licenses/fdl-1.3.de.html
Heinz schrieb:> Ein T. schrieb:>> Außerdem>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.>> Stallman himself.>> Original-Dokus sind oft schwer verständlich und didaktisch eine halb-> bis vollkatastrophe ;)
Das sehe ich nicht so.
> Dazu kommt noch die Sprachbarriere.
Englisch kann man lernen, das ist gar nicht so schwierig -- und wer
Software oder Elektronik entwickeln will, kommt darum ohnehin nicht
herum. Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für
die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus,
da ist bestimmt auch etwas für Dich dabei.
rbx schrieb:> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.
Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit
mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche
Gesellschaft. ;-)
Ein T. schrieb:> Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für> die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus,> da ist bestimmt auch etwas für Dich dabei.
Da habe ich schon vor über 20 Jahren gesucht und nur von der Fernuni
Hagen etwas brauchbares zu Emacs gefunden. Aber etwas, das Inhaltlich im
Umfang darüber hinausgeht, dann leider nicht. Habe dann mit Emacs sogar
meine Diplomarbeit geschrieben. Heute benutze ich vi und emacs nur mal
um einen Wert in einer Konfigurationsdatei zu ändern, dazu reichen dann
meine Kenntnisse auch. Ansonsten benutze ich heute Notepad++ und VS
Code. Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir
meine Zeit zu schade. Deren Zeit ist einfach abgelaufen. Ein Editor ist
für mich Werkzeug und nicht Selbstzweck.
timol schrieb:> Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine> Zeit zu schade.
Um mit VScode effizient zu arbeiten, musst du dich genauso einarbeiten.
Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten
("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal
(mindestens die unterschiedliche Modi muss man kennen).
Ich staune da immer wieder über meine Kollegen, weil ich mir viele der
nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs
effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in
Ordnung so.
Jörg W. schrieb:> Ich staune da immer wieder über meine Kollegen, weil ich mir viele der> nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs> effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in> Ordnung so.
Klar ist es völlig in Ordnung. Mir kann es doch egal sein, womit sich
hier wer quälen will. Ich kenne nur keinen Entwickler, der mit vim
programmiert, aber ich weiß natürlich dass es welche gibt. In den
meisten Firmen gibt es auch sehr strenge Vorgaben womit entwickelt wird,
wie dokumentiert wird und wie der Code auszusehen hat. Oft hat da sogar
auch der Kunde noch mitzureden. Gut, in irgendwelchen 3-Mann-Klitschen
ist das sicher etwas anders.
Jörg W. schrieb:> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal> (mindestens die unterschiedliche Modi muss man kennen).
Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man
direkt im Insert-Mode, und es können die von Windows bekannten
Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S
(save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur
Verfügung.
Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann
sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.
timol schrieb:> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.
Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was
du hier gerade heraus hängen lässt.
udok schrieb:
. Schon interessant und frustrierend, das es nach >50 Jahren
> Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.
Das könnte vielleicht auch daran liegen, dass diese Wünsche ein sehr
bewegliches Ziel sind. Der Eine will mal schnell eine Zeile in einer
Konfigdatei ändern, ein anderer hingegen grosse Datendateien editieren,
wieder einer möchte das Gesamtkunstwerk grafisch, aberauch über eine
SSH-Verbindung nutzen, und jeder davon hätte es gerne möglichst
komfortabel. Also im eigenen Sinne und für alle möglichen Definitionen
des Wortes komfortabel, versteht sich.
Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),
für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die
Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig
und/oder unwichtig erklärt.
udok schrieb:> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.hüstel Äh, bitte entschuldige... mit einem Editor? 8-O
Ein T. schrieb:> udok schrieb:>> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.>> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.>> hüstel Äh, bitte entschuldige... mit einem Editor? 8-Oräusper Er meint bestimmt einen Hexeditor ;-)
alex schrieb:> Da bist du aber bei vi und Derivaten davon absolut falsch ;)
Nö die Fanboys finden das Teil super und geilen sich seit hunderten von
Beiträgen daran auf. Da müssen dann schon auch mal (Text-) Dateien mit
100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig
derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch
Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Aber
gut das Lieblingsspielzeug ist ja so geil, da ist das völlig wurscht ob
man am Ende der Datei noch weis was in der 3. Zeile stand.
Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen
auch vi, vim oder wie sie alle heißen mögen. Damit wird die Arbeit
erledigt und gut ist es. Mir würde es im Traum nicht einfallen so ein
Gewese um dieses Thema zu machen. Ein Editor ist ein Werkzeug, das für
meine Zwecke funktionieren muß - mehr nicht.
Zeno schrieb:> Da müssen dann schon auch mal (Text-) Dateien mit> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.
Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere
100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format
enthält?
Was sind die Alternativen? Die Software, die die Daten erzeugt neu
entwickeln? Einen anderen Job suchen, der nicht mit solchen Dateien zu
tun hat?
Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen
Dateien oder dem Editor meiner Wahl. Meine Kollgen haben keine Probleme
mit diesen Dateien oder dem Editor meiner Wahl. Mein Chef hat keine
Probleme mit diesen Dateien und dem Editor meiner Wahl. Unsere Kunden
haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Nur
du und nano haben Probleme damit. Und ihr wisst nichteinmal was das für
Dateien sind und was damit gemacht werden muss.
Kiffer schrieb:> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig> und/oder unwichtig erklärt.
Nein, so war das nicht.
Nano hat eingangs klargestellt für was er welchen Editor verwendet und
warum.
Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der
vim zwar unbestreitbar besser performt, die für ihn aber nicht
relevant seien.
Das ändert freilich nichts daran dass er sich in den darauf folgenden
technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war,
überhaupt auf die Beispiele einzugehen.
Le X. schrieb:> Sein Fehler war, überhaupt auf die Beispiele einzugehen.
Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler
bezeichnen. ;-) Wofür sollte er überhaupt gut gewesen sein? Irgendein
ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen,
scheint er nicht zu haben, was man schon an seinem Abqualifzieren
derjenigen als "Fanboys" gut erkennen kann.
udok schrieb:> Schon interessant und frustrierend, das es nach >50 Jahren> Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.
Auch nach über 100 Jahren Automobilbau gibt es noch kein Automobil, das
alle Wünsche nach Fahrleistung, Transportkapazität, Wirtschaftlichkeit,
Umweltfreundlichkeit und Protzigkeit erfüllt.
Immerhin scheint bei den Editoren jeder Diskussionsteilnehmer hier einen
gefunden zu haben, der zumindest seine persönlichen Erwartungen erfüllt.
Somit besteht womöglich gar kein Bedarf an der eierlegenden Wollmilchsau
(falls diese überhaupt realisierbar ist).
Nano schrieb:> Petr T. schrieb:>> Openbsd schrieb:>>> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die>>> ultimativen Vorzuege dieses Editors?>>>> Selbstverständlich!>>>> Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du>> z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw.>> Mit JEDEM mit Mausbedienung!>> Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann> 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig!>> Insgesamt also 2 Tasten, nicht 3.
Ja, und das ganze dauert 10x so lange und die Chance, dass man mit der
Maus nicht ganz genau ist und evtl. mehr oder weniger löscht, ist
ziemlich hoch.
Das ist weder effizient noch ergonomisch.
Alleine die Zeit, die ich dazu brauche meine Hand von der Maus auf die
Tastatur zu wechseln ist mindest doppelt so viel wie "5dd" zu drücken.
>> Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn>> gesund hält...>> Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus.
Meine Güte, so ein Schwachsinn!
Le X. schrieb:> Kiffer schrieb:>> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),>> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die>> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig>> und/oder unwichtig erklärt.>> Nein, so war das nicht.
Aber ja doch, genau so war das. Zu Anfang ist er gleich mal mit einer
überheblichen Provokation in diesen Thread eingestiegen
(Beitrag "Re: Vi Editor ausgestorben?") und dann
hat er das passende Echo nicht vertragen und die Vollmimi gegeben. Und
im Laufe dieser Entwicklung, die er mit seiner viel zu großen Klappe
selbst bewußt und gezielt provoziert hat, hat er mehrfach die Contenance
verloren, die Aufgaben und Wünsche anderer entweder einfach ignoriert
oder für unwichtig erklärt, wieder andere wurden von ihm herablassend
behandelt, als Straftäter diffamiert und als drogensüchtig bezeichnet.
Auf dem Höhepunkt seines Auftritts, der vom ersten Beitrag an nichts als
eine gezielte, bewußte und gewollte, maximal herablassende, arrogente
und besserwisserische Peovokation war, hat Mr. Mimimi sich soger
entblödet, nach den Moderatoren zu rufen, als ob die nicht schon genug
mit den anderen ungezogenen Kleinkindern zu tun hätten. Chill mal Deine
Base, LeX.
Jörg W. schrieb:> Irgendein> ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen,> scheint er nicht zu haben, was man schon an seinem Abqualifzieren> derjenigen als "Fanboys" gut erkennen kann.
Das Wort "Fanboy" hat Nanos (wieder einmal, honi soit qui mal y pense)
Beschützer LeX in diese Diskussion eingebracht. Sein Schützling hat das
dann nur übernommen.
Jörg W. schrieb:> timol schrieb:>> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.>> Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was> du hier gerade heraus hängen lässt.
Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten
mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. So sind
die Threads hier im Forum gleich unterhaltsamer. Aber ein Mod kann sich
hier ja aufführen wie ein A...
mh schrieb:> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format> enthält?
Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei
entsteht.
Eine Datei mit Sourcecode, egal welche Programmiersprache wird wohl kaum
so groß werden. Wenn man wirklich soviel Sourcecode unterbringen muß,
dann teilt man das Projekt in halbwegs verdauliche Häppchen auf. bei
meinem größten Projekt hatte eine Sourcecodedatei, die Hauptdatei des
Projektes (insgesamt ca. 800 Sourcecodefiles), knapp 18000 Textzeilen
(760kB) und das war eigentlich schon zu viel. Das Teil ist über 20 Jahre
gewachsen, weil immer wieder neue Anforderungen dazu gekommen sind.
Heute würde ich das anders machen.
Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß.
Bei dem erwähnten Programm handelt es sich um eine SW zum Auswerten von
Messreihen. Die Daten liegen als ASCII Dateien vor sind aber selten
größer als 10kB. Ausnahme sind Unixdatenfiles die meist als
Wiederholungsprotokolle vorlagen, also noch zusätzlichen Fülltext
enthielten. Die von mir entwicklte SW hat die Daten auch wieder im
ASCII-Format gespeichert - Dateigröße ca. 10kB, davon aber meist so 10
Stück pro Messreihe, also isgesamt 100kB. Selbst bei sehr umfänglichen
Messreihen war das Gesamtdatenvolumen nicht größer als 1MB, also 1% von
Deinen 100MB - aufgeteilt auf mehrere Dateien. Mit anderen Worten wer so
große Datendateien enstehen läßt macht was falsch. Solche Riesendateien
kann kein Mensch mehr überblicken, geschweige denn vernünftig auswerten.
Wenn derartige Datenmengen anfallen dann heißt das Stichwort Datenbank,
die bringt dann auch die passenden Tools mit um die Daten auszuwerten.
Für Logfiles gilt im Prinzip das Gleiche wie für die Daten. Da sollte
man als Programmierer dafür sorgen, das die nicht zu groß werden. Ich
habe deshalb bei meiner Software die Logfiles auf eine Maximalgröße von
2MB begrenzt. Wenn ein File diese Größe erreicht hat wurde der Name um
das aktuelle Datum + Uhrzeit egänzt, dann weg gesichert und ein neues
Logfile begonnen. Selbst dieses 2MB File ließ sich schon schlecht
auswerten - einfach zu groß und unübersichtlich. Abgesehen davon würde
ich ein Logfile auch nicht mit einem Editor öffnen, da gibt es in der
GUI Viewer bzw. im Shellfenster cat, more und bei Bedarf grep.
Und ja ich hatte auch schon größere Textdateien, aber 100MB sind mir in
30 Berufsjahren nie vor gekommen. Das Beispiel ist einfach nur an den
Haaren herbei gezogen, um zu zeigen das der vi, vim etc. das Geilste
ever ist. Um das eigentliche Thema geht es doch schon lang nicht mehr.
timol schrieb:> Aber ein Mod kann sich> hier ja aufführen wie ein A...
Das tut der Jörg eigentlich nicht - auch wenn ich nicht generell seine
Statements teile.
Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare
halt ab und an entsprechend aus. Man muß ja auch nicht alle Statements
von Jörg kommentieren.
timol schrieb:> Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten> mit nachvollziehbaren Argumenten die Welt erklärt, hier haben.
Argumente bringst du ja auch keine, nur Behauptungen. Warum erwartest du
dann von anderen Argumente? Du behauptest, dass andere "sich quälen", du
definierst, wer wo wem was vorschreibt und dass das dann halt so sei.
Möglicherweise habe ich schon ein paar "Klitschen" (das scheint dein
Begriff für alles das zu sein, was du nicht kennst) mehr gesehen –
zwischen 5 und 50000+ Mitarbeitern war da vieles dabei.
Zeno schrieb:> Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei> entsteht.
Tja, und wenn andere die Datei für ihn in der Form erzeugen? Gehst du zu
denen hin und erzählst ihnen, dass sie da was falsch machen?
Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien
herum editieren würde – aber wenn solche Dateien halt irgendwo entstehen
und man auch mal drin editieren muss (oder sie zumindest ansehen, was
drin suchen etc.), dann sollte es ein Tool geben, mit dem man das machen
kann. Das muss ja auch nicht notwendigerweise das gleiche sein wie das,
mit dem man seine täglichen Programmieraufgaben erledigt – es soll Leute
geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das
Gegenteil von "Fanboys".
Zeno schrieb:> Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß.
Veto.
Zum Beispiel traces eines beliebigen Bus-Systems sind wesentlich größer.
Die werden zwar meist mit dedizierter SW geöffnet, trotzdem kam es schon
vor dass ich mit Traces mit einem Editor ansehen musste.
Aber es stimmt schon, von der Fähigkeit, beliebig große Dateien öffnen
zu können würde ich jetzt nicht die Wahl meines Standard-Editors
abhängig machen. Dafür kommt dieser usecase (bei mir) zu selten vor.
Zeno schrieb:> mh schrieb:>> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere>> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format>> enthält?> Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei> entsteht.
Natürlich hast du den Rest meines Beitrags nicht zitiert ;-)
Du bist also der Meinung, dass ich die XXk€ Software, die mein
Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du,
wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der
Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".
Mombert H. schrieb:> Du bist also der Meinung, dass ich die XXk€ Software, die mein> Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du,> wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der> Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".
Also wenn ich Dein Arbeitgeber wäre, würde ich sagen "na klar, wenn
diese ausgewiesenen Experten das sagen, müssen wir das sofort machen!
Lass uns nochmal XXk€ ausgeben damit die beiden uns eine neue Software
bauen, die kann nur besser sein!"
Ein T. schrieb:> rbx schrieb:>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.>> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche> Gesellschaft. ;-)
Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln
könnten?
Yalu X. schrieb:> Jörg W. schrieb:>> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten>> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal>> (mindestens die unterschiedliche Modi muss man kennen).>> Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man> direkt im Insert-Mode, und es können die von Windows bekannten> Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S> (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur> Verfügung.>> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.
Das würde ich nicht sagen.
Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über
das Menü einstellbar.
Mit Vim im Easy-Mode und den von Windows bekannten Tastenkürzel wie ^C
(copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) hat man noch lange
keinen Zeilenumbruch das Kodierungsschema eingestellt.
Sollte man hier den Vim im Eays-Mode mit leistungsfähigeren Editoren
vergleichen, die ihre Einstellungen über Menüs erlauben, dann geht hier
noch weniger.
Der Easy-Mode ahmt also zwar bekannte Tastaturkürzel nach, aber er macht
Vim dadurch noch lange nicht zu einem intuitiv benutzbaren Editor.
Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren
feststellen konnte, kein ESC :q! um vim zu verlassen.
Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt.
Das einzige was ging war ALT+F4, aber das nur, weil das die
Tastenbelegung für KDE zum Schließen von Anwendungen ist und die Konsole
daher nachfragte, ob sie mitsamt allem, was darin läuft, geschlossen
werden soll.
Nano schrieb:> Auch ein STRG+Q oder ALT+Q oder STRG-
Meinte STRG+C
> brachte hier keinen Erfolgt.Kiffer schrieb:>
> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig> und/oder unwichtig erklärt.
Ich habe oben geschrieben, dass ich keine großen in der Regel
Binärdateien mit einem Texteditor bearbeite und dafür einen Hexeditor
verwende.
Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100
MiB große Quellcode Datei in einer IDE öffnen will.
Tipp:
Es macht Sinn, solche großen Quellcodedateien in mehrere kleine
aufzuteilen.
Bei so einer großen Datenmenge kann man sogar überlegen, ob man nicht
vielleicht auch gleich noch eine Bibliothek baut und die dann einbindet.
Nano schrieb:> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über> das Menü einstellbar.
Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben
(die berühmte Konfig-Datei).
Selbst im Emacs benutze ich die entsprechende Funktion sehr selten,
obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als
auch Menüs).
Nano schrieb:> Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100> MiB große Quellcode Datei in einer IDE öffnen will.
Es ging allerdings nicht um Quellcode, sondern um irgendwelchen Krempel,
der in Textform vorliegt (daher keinen Hex-Editor braucht) und den
irgendein Programm außerhalb des Einflussbereichs desjenigen produziert,
der dann die Daten trotzdem gelegentlich ansehen und anfassen muss.
Warum, weshalb und wieso die Daten genau so entstehen, muss man nicht
diskutieren, wenn man darauf eh keinen Einfluss hat. Sie sind dann
einfach da.
Dass hier keiner 100 MB großen Quellcode in eine einzige Datei stopft,
bedarf wohl keiner großen Diskussion.
Nano schrieb:> Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100> MiB große Quellcode Datei in einer IDE öffnen will.> Tipp:> Es macht Sinn, solche großen Quellcodedateien in mehrere kleine> aufzuteilen.
Ich schreibe alle relevanten Infos mit printf ins Log,
da sind bei 1000 Messages / Sekunde * 50 Bytes 30 MB in 10 Minuten
erreicht...
Das ist dank SSD kein Performanceproblem.
Glaub mir, das willst du dir mit keinem Hex Editor anschauen.
Zeno schrieb:> alex schrieb:>> Da bist du aber bei vi und Derivaten davon absolut falsch ;)>> Nö die Fanboys finden das Teil super und geilen sich seit hunderten von> Beiträgen daran auf.
Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann
aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige
mich sogar persönlich angreifen, wie man oben sehen konnte.
Der Grund ist einfach:
Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann
ist das natürlich besonders übel für die Fanboys, wenn ich deren vim
nicht nutze.
Bei einem IT Laien wäre das nämlich nicht so wichtig oder irrelevant,
denn ein Laie kennt sich nicht aus, daher haben dessen Aussagen kein
Gewicht, da ich keiner bin, ist das in meinem Fall anders. Dafür werde
ich angegriffen, das ist der Grund.
@vim fanboys
:p
> Da müssen dann schon auch mal (Text-) Dateien mit> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.
++
So sehe ich das auch.
> Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen> auch vi, vim oder wie sie alle heißen mögen.
Ganz deiner Meinung.
Nano schrieb:> warum die Fanboys
Die wissen, dass du dich allein durch die bloße wiederholte Verwendung
dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen
abzustempeln ist ein Ausdruck fehlender Argumente.
mh schrieb:> Zeno schrieb:>> Da müssen dann schon auch mal (Text-) Dateien mit>> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig>> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch>> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.>> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format> enthält?
Ich versuche es mal:
Ihr habt oben etwas von Messdaten geschrieben.
Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen,
dann sollte man über ein Binärformat und ein Programm, über das man auf
diese zugreift und das diese aufbereitet, nachdenken.
Grund:
Ein Binärformat spart viel mehr Platz und ist für einen Computer viel
besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm
schreibt, gleich noch daran denken, die Daten noch zu komprimieren.
Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf,
dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier
zu großen Verlusten führen.
Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei
schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust
mehr Sicherheit und das erlaubt dann auch die alten Dateien zu
komprimieren und so Speicherplatz zu sparen.
Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei
anzulegen.
> Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen> Dateien oder dem Editor meiner Wahl.
Bis mal der Rechner eine Störung hat.
> Mein Chef hat keine> Probleme mit diesen Dateien und dem Editor meiner Wahl.
Dann weise ihn mal auf die Punkte hin, die ich gerade genannt habe und
dann beobachte ob sich an seiner Einstellung etwas ändert.
> Unsere Kunden> haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl.
Gleicher Fall wie beim Chef.
> Nur> du und nano haben Probleme damit.
Wir haben ja auch Ahnung und würde das so deswegen auch nicht machen.
Die Begründung warum wir das anders machen würde, habe ich hier gerade
geschrieben. Es liegt jetzt an dir, daraus zu lernen und die
Verbesserungen zu übernehmen und umzusetzen und dann brauchst du auch
diese großen Dateien nicht mehr.
> Und ihr wisst nichteinmal was das für> Dateien sind und was damit gemacht werden muss.
Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im
einfachsten Fall ASCII Text.
Nano schrieb:> Der Grund ist einfach:> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim> nicht nutze.
Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du
dich
aufregst, über was auch immer... dazu gehören aber mindestens 2.
Nano schrieb:> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.
Ist alles richtig, aber dann muss ich erst ein Programm schreiben,
das mir die Daten in ASCII umwandelt. Bringt also nix ausser Arbeit.
Wir leben auch nicht mehr in den 90'ern. Jedes Handy Spiel installiert
heute 100 MB...
Le X. schrieb:> Kiffer schrieb:>> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),>> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die>> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig>> und/oder unwichtig erklärt.>> Nein, so war das nicht.> Nano hat eingangs klargestellt für was er welchen Editor verwendet und> warum.> Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der> vim zwar unbestreitbar besser performt, die für ihn aber nicht> relevant seien.
So weit okay.
> Das ändert freilich nichts daran dass er sich in den darauf folgenden> technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war,> überhaupt auf die Beispiele einzugehen.
Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich
8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht
aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in
MB gedacht habe.
Nano schrieb:> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in> MB gedacht habe.
Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen.
Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber
auch nix, im Fernsehen spielts ja nix gescheites.
Jörg W. schrieb:> Le X. schrieb:>> Sein Fehler war, überhaupt auf die Beispiele einzugehen.>> Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler> bezeichnen. ;-)
Ich habe diesen Thread nicht eröffnet. Der ist nicht von mir. Er wurde
von dem Nutzer OpenBSD am 06.01.2020 16:38 erstellt.
Ich habe auf die Frage des TS erstmals am 8.1.2020 geantwortet.
Nano schrieb:> Der Grund ist einfach:> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also> weitaus mehr Gewicht zu
Du solltest an Deiner Selbstwahrnehmung arbeiten.
Niemand hier dürfte Dich für einen Profi halten. Eher für einen
Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen
zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne
Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.
Nachweise Deiner angeblichen Kompetenz willst Du ja leider nicht
liefern:
Beitrag "Vielzahl an IDE, Framworks, usw."
udok schrieb:> Nano schrieb:>> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich>> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht>> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in>> MB gedacht habe.>> Doch :-) Du machst den Fehler, auf die Argumente überhaupt einzugehen.
Okay, die Zeit hätte ich mir natürlich sparen können, so hast du
natürlich recht.
Aber einen technischen Fehler habe ich nicht gemacht, außer dem mit den
8 MB anstatt 8 GB.
> Und solage du (oder ich) das machen, geht der Thread weiter. Macht aber> auch nix, im Fernsehen spielts ja nix gescheites.
Das ist wahr.
Kiffer schrieb:> ...viel Unsinn...
Erstens:
Du hast dich im Thread verirrt.
Zweitens:
Deine Behauptungen und Anschuldigungen hier bezüglich dem anderen Thread
sind nicht korrekt.
Bist du vielleicht der Straftäter aus dem anderen Thread?
Ein Mod könnte und sollte das mal überprüfen, das würde mich
interessieren.
vim schrieb:> Nano schrieb:>> Der Grund ist einfach:>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also>> weitaus mehr Gewicht zu>> Du solltest an Deiner Selbstwahrnehmung arbeiten.>> Niemand hier dürfte Dich für einen Profi halten. Eher für einen> Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen> zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.
Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten.
Und was alle anderen außer ihm falsch machen.
Und was er viel besser könnte wenn man ihn nur ließe.
Er erklärt uns wie groß Dateien werden dürfen.
Und das er noch nie Größere gebraucht oder gesehen hat.
Er erklärt uns das Binärformate bei größeren Dateien besser sind.
Wir alle sollten besser auf ihn hören! ;-)
Jörg W. schrieb:> Nano schrieb:>> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über>> das Menü einstellbar.>> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben> (die berühmte Konfig-Datei).
Nicht zwingend. Früher musste man unter Windows die
Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien,
die unter Unix mit einem LF Codierung für den Zeilenumbruch
abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte.
Und README Dateien lesen, das gehört meiner Meinung nach noch zu den
administrativen Aufgaben.
Heute in Windows 10 kann Notepad glücklicherweise mit diesen
Zeilenendencodierungen umgehen, aber früher war das nicht so.
Und beim Kodierungsschema ist es nicht viel anderes.
Vieles kam aus DOS Zeiten mit z.B. Codetabelle 430, dann musste man das
entsprechend umstellen können.
> Selbst im Emacs benutze ich die entsprechende Funktion sehr selten,> obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als> auch Menüs).
Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3
ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte,
welcher Editor sich für mein DOS Projekt am besten eignet.
Emacs hat beim ersten Start irgendwelche Daten aufbereitet und eine
Ewigkeit dafür gebraucht. Danach haben die Starts auch sehr lange
gedauert.
Ich habe ihn daher gelöscht. Aber wenn du willst, dann kannst du dir das
gerne mal unter FreeDOS ansehen.
Die Emacs Version darauf ist schon ein paar Jahre alt.
Jörg W. schrieb:> Nano schrieb:>> warum die Fanboys>> Die wissen, dass du dich allein durch die bloße wiederholte Verwendung> dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen> abzustempeln ist ein Ausdruck fehlender Argumente.
Oh, mir ging es da jetzt nicht um die normalen Vim Nutzern, sondern
tatsächlich um die aggressive Gruppe unter den Vim Nutzern die hier
ausrastet, wenn man vim nicht nutzt. Der Einfachheit halber übernehme
ich hier lediglich die Begriffsbezeichnung, die Le X. anfangs
einbrachte und nutzte, in dem Fall also "Fanboys".
Siehe dazu:
Beitrag "Re: Vi Editor ausgestorben?"
udok schrieb:> Nano schrieb:>> Der Grund ist einfach:>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also>> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann>> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim>> nicht nutze.>> Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du> dich> aufregst, über was auch immer... dazu gehören aber mindestens 2.
Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin
da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den
anderen dann zu korrigieren.
Du kennst ja sicher folgendes Comic:
https://xkcd.com/386/
Ich kann stundenlang diskutieren.
vim schrieb:> Nano schrieb:>> Der Grund ist einfach:>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also>> weitaus mehr Gewicht zu>> Du solltest an Deiner Selbstwahrnehmung arbeiten.>> Niemand hier dürfte Dich für einen Profi halten. Eher für einen> Informatik-Erstsemester, ...
Als vim Fanboy hast du jetzt natürlich keine andere Möglichkeit mich
wieder persönlich anzugreifen, anstatt in der Sache, nachdem ich
Personen wie dich durchschaut habe.
> Deine Beitragsbewertungen sprechen für sich, -13 ohne> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.
Beitragsbewertungen kann man als Gast nicht einsehen, also existieren
sie nicht.
Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen
sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an
dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI
zu verstehen.
Norbert schrieb:> Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten.> Und was alle anderen außer ihm falsch machen.> Und was er viel besser könnte wenn man ihn nur ließe.> Er erklärt uns wie groß Dateien werden dürfen.> Und das er noch nie Größere gebraucht oder gesehen hat.> Er erklärt uns das Binärformate bei größeren Dateien besser sind.>> Wir alle sollten besser auf ihn hören! ;-)
Oben habe ich in meinem Beitrag
Beitrag "Re: Vi Editor ausgestorben?"
ja ausführlich und argumentativ begründet, warum man für Messdaten keine
einzige große Datei nutzen sollte.
Es steht dir jetzt frei, diese ganzen von mir genannten Argumente
hiermit zu widerlegen, aber warum nutzt du diese Chance nicht und
greifst mich stattdessen wieder persönlich an,
O Ton:
> Aber dafür erklärt er uns doch so schön die Welt...
anstatt einfach mal in der Sache mich argumentativ zu widerlegen?
Überlege mal!
Letzten Endes könntest du jetzt auch einfach zugeben, dass du die
genannten Argumente nicht widerlegen kannst.
Nano schrieb:> vim schrieb:>> Deine Beitragsbewertungen sprechen für sich, -13 ohne>> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.>> Beitragsbewertungen kann man als Gast nicht einsehen, also existieren> sie nicht.> Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen> sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an> dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI> zu verstehen.
Ups, da fehlte ein Wort. Ich meinte natürlich "nicht zu verstehen".
Nano schrieb:> Oben habe ich in meinem Beitrag> Beitrag "Re: Vi Editor ausgestorben?">> ja ausführlich und argumentativ begründet, warum man für Messdaten keine> einzige große Datei nutzen sollte.>> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente> hiermit zu widerlegen
Diese Hybris ist unbeschreiblich!
Du meinst tatsächlich anderen erklären zu müssen, was richtig und was
falsch ist? Wer glaubst du eigentlich wer du bist?
Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes
vorzustellen:
Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB.
Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht
beugen wollen.
Diese Anlagen bestehen darauf Daten im Textformat auszuspucken.
Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert
tadellos.
Also nimm dich mal ein wenig zurück und rede (und vor allem urteile)
nicht über Dinge die in deiner Welt nicht vorkommen.
Nano schrieb:>> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann>> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.>> Das würde ich nicht sagen.
Du nicht, ich schon.
> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über> das Menü einstellbar.
Ich habe nicht behauptet, dass EasyVim ein 1:1-Notepad-Klon ist, aber
die wesentlichen Funktionen, insbesondere die, die man zum Editieren der
berühmten Config-Files braucht, sind gleich oder zumindest leicht in den
Menüs auffindbar. Wer deutlich mehr braucht, nutzt nicht den Easy-Mode
und erst recht nicht Notepad.
Was meinst du mit dem einstellbaren Zeilenumbruch? Die Aktivierung und
Deaktivierung des automatischen Zeilenumbruchs? Oder die maximale
Zeilenlänge als Parameter für den automatischen Zeilenlänge? Beides
lässt sich über das Menü einstellen.
Was meinst du mit Kodierungsschema? Die Zeichenkodierung? Defaultmäßig
wird diese von der zu editierenden Datei oder – wie beim Nano – vom der
Einstellung des aufrufenden Prozesses bzw. des Betriebssystems
übernommen. Kein Anfänger möchte diese Einstellung ändern. Falls er
fortgeschritten genug ist, um dennoch solche exotischen Funktionen zu
brauchen, wird es ihm nicht schwer fallen (auf jeden Fall leichter als
beim Nano ;-)), den entsprechenden Befehl nachzuschlagen.
> Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren> feststellen konnte, kein ESC :q! um vim zu verlassen.
Das soll es auch nicht, denn das wäre ja für den Anfänger nicht easy :)
> Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt.
Strg+Q sollte gehen und geht bei mir auch. Wenn es bei dir nicht geht,
hast du wieder so eine verkrüppelte Vim-Version installiert, oder dein
Window-Manager nutzt diese Tastenkombination für eigene Zwecke. Dann
bleibt aber immer noch das Menü (File/Exit bzw. Alt+FX) oder eben
> ALT+F4
Nano, mittlerweile weiß doch jeder, der diesen Thread liest, dass du
kein Freund von Vim bist, und jeder (einschließlich mir) akzeptiert
dies, auch ohne dass du ständig neue und immer fadenscheinigere Gründe
gegen Vim an den Haaren herbeiziehst.
Norbert schrieb:> Nano schrieb:>> Oben habe ich in meinem Beitrag>> Beitrag "Re: Vi Editor ausgestorben?">>>> ja ausführlich und argumentativ begründet, warum man für Messdaten keine>> einzige große Datei nutzen sollte.>>>> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente>> hiermit zu widerlegen>> Diese Hybris ist unbeschreiblich!> Du meinst tatsächlich anderen erklären zu müssen, was richtig und was> falsch ist? Wer glaubst du eigentlich wer du bist?
Und wieder wiederholst du deinen Angriff auf die Person, anstatt in der
Sache meine Argumente zu widerlegen.
Lies und lerne:
https://de.wikipedia.org/wiki/Argumentum_ad_hominem> Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes> vorzustellen:> Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB.> Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht> beugen wollen.> Diese Anlagen bestehen darauf Daten im Textformat auszuspucken.> Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert> tadellos.
Das widerlegt meine Argumente nicht, es zeigt nur, dass diese Geräte von
den gleichen Typen programmiert wurde, die alle Messdaten in eine
einzige große Datei zu schreiben.
Übrigens gibt es das split Kommando, das solltest du dir mal ansehen.
Nano schrieb:> Ihr habt oben etwas von Messdaten geschrieben.>> Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen,> dann sollte man über ein Binärformat und ein Programm, über das man auf> diese zugreift und das diese aufbereitet, nachdenken.
Du meinst z.B. so wie es systemd tut? Der schreibt seine Logdaten als
Binärklumpen raus, so dass man sie nicht mehr einfach mit einem normalen
Texteditor öffnen kann.
Ansonsten: Was bringt es mir, über ein Binärformat nachzudenken? Wenn
ich ein Programm habe, das die Daten als Text ausgibt, dann ist das eben
so. Nicht jeder hat die komplette Software, die er benutzt, selbst
geschrieben oder die Möglichkeit, diese mal kurz umzuprogrammieren, um
ein völlig anderes Format auszugeben.
> Grund:> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.
Allerdings muss man dann eben auch das Anzeigeprogramm schreiben. Bei
Text nehme ich einfach den bereits vorhandenen Texteditor.
> Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei> anzulegen.
Sag das mal dem AUTOSAR-Konsortium. Da können auch mal XML-Dateien
entstehen, die 2GB groß sind. Das kann ich als Anwender nicht ändern,
sondern nur hinnehmen und muss halt irgendwie damit klar kommen.
Nano schrieb:> Ein T. schrieb:>> rbx schrieb:>>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,>>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so>>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.>>>> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit>> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche>> Gesellschaft. ;-)>> Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln> könnten?
Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und
ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich
andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und
Berührungen geht. ;-)
Nano schrieb:> Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann> aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige> mich sogar persönlich angreifen, wie man oben sehen konnte.>> Der Grund ist einfach:> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim> nicht nutze.
Bwahahahaha! TY, YMMD... again! ;-)
Nano schrieb:> Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin> da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den> anderen dann zu korrigieren.
Davon merke zumindest ich leider wenig.
> Ich kann stundenlang diskutieren.
Das hingegen ist mir schon aufgefallen. Erstaunlich, nicht wahr?
Nano schrieb:>> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben>> (die berühmte Konfig-Datei).>> Nicht zwingend. Früher musste man unter Windows die> Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien,> die unter Unix mit einem LF Codierung für den Zeilenumbruch> abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte.
Dafür habe ich nie Notepad genommen, sondern Wordpad. Das konnte das
sofort.
Da man darin aber nichts editieren muss, interessiert mich nicht, wie
man da was umstellen würde.
> Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3> ausprobiert
Das ist ja auch Quatsch, das überhaupt zu versuchen. Du kannst
vielleicht einen alten GNU Emacs auf einer PDP-11 benutzen, aber einen
aktuellen Emacs auf so einem kastrierten System zu nehmen, das kann
nicht gut gehen.
Ein aktueller Emacs startet (im GUI-Modus) auf vergleichbarer Hardware
unter Unixen zumindest schneller als ein Notepad++ unter Windows.
Jörg W. schrieb:> Ein T. schrieb:>> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.>> Sie kann mehr, macht aber alles anders, und vor allem kann sie> Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich> schmerzlich feststellen.
Von einem User im Python-Forum.de werden das "Windows Terminal" [1] und
der "Cmder" [2] empfohlen, vielleicht könnte eines dieser Programme
etwas für Dich sein. HF!
[1]
https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701?hl=de-de&gl=DE
[2] https://cmder.net/
Nano schrieb:> Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören> und keinen anständigen Diskurs mit Anstand und Niveau führen könenn.
hihi... ja die erkennt man echt gut ;)
Le X. schrieb:> Es ist schon interessant wie fanatisch man sein Tool lieben kann.> Überkochende Emotionen sind ein Garant für gute Unterhaltung.
Oh ja... bin schon an der zweiten Portion Popcorn...
Nano schrieb:> Meinte STRG+C
Das ist das klassische Argument. Das ist dann eher so, wie wenn der
Rechner beim Skyrimspiel hängt bzw. das Bild "einfriert". Konsole geht
nicht. Alt-F4 auch nicht usw. Aber irgendwas geht. Oft muss man den
Rechner nicht neustarten.
Bei Windows geht bei solchen Sachen erfahrungsgemäß Strg+Alt+Entf gut.
Das kann man auch ab und zu in Linux benutzen.
Aber prinzipiell nicht mehr sinnvoll, wenn der Bildschirm einfriert.
Im Unterschied zu den Spielstörungen gibt es bei Vi und Vim die ein oder
andere Einführungshilfe. Die sollte man mitnehmen/Dabeihaben. Aber auch
dann ist das nicht mehr rauskommen blöd und kann vorkommen - vermutlich
deswegen, weil es meist nicht in Großbuchstaben im Hilfetest steht.
Nano schrieb:> enn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über> das Menü einstellbar.
Notepad++ kann das. Open Office, also Libre Office aber auch. Auf
jedenfall muss man das öfter machen, wenn man Texte vom Normalen Desktop
nach Cygwin überträgt.
Nano schrieb:> Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3> ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte,> welcher Editor sich für mein DOS Projekt am besten eignet.
Da kannst du den Watcom Vi benutzen :)
Und außerdem die 32Bit Debug-Version von Paul Vojta.
Ein T. schrieb:> Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und> ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich> andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und> Berührungen geht. ;-)
Mir ging es nur darum, den Unterschied zwischen der "Geistform" und der
normalen körperlichen Anwesenheit verständlich zu machen. Das scheint
mir ja gut gelungen zu sein, und das reicht mir auch.
https://www.youtube.com/watch?v=ppmEc56nSFk
Zeno schrieb:> timol schrieb:>> Aber ein Mod kann sich>> hier ja aufführen wie ein A...> Das tut der Jörg eigentlich nicht
Aber sicher tut er das - und zwar nicht nur in diesem Thread.
> Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare> halt ab und an entsprechend aus.
Die Benutzung von Unix rechtfertigt noch lange nicht ein solches
Verhalten. Und es betrifft ja auch viele andere Themen.
> Man muß ja auch nicht alle Statements> von Jörg kommentieren.
Klar, man muss gar nichts. Gilt für andere aber auch.
timol schrieb:> Zeno schrieb:>> timol schrieb:>>> Aber ein Mod kann sich>>> hier ja aufführen wie ein A...>> Das tut der Jörg eigentlich nicht>> Aber sicher tut er das - und zwar nicht nur in diesem Thread.
Hm, die Vi Benutzung mit gewissen Formen des Unternehmertums in einen
Topf, bzw. eine Schublade zu werfen, ist aber schon spannend.
https://de.wikipedia.org/wiki/Generalisierungsgradient
Jörg W. schrieb:> Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien> herum editieren würde
Das liest sich aber in seinem Beitrag anders.
mh schrieb:> Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen> Dateien ...
Ich lese das so, das er öfter mit solchen Dateien zu tun hat.
Am Ende ist es mir arber auch Rille.
Ich habe mich die letzten 25 Jahren mit Auswertung von Messdaten
beschäftigt, sowohl von der SW-Seite (Entwickler) her und auch als
Anwender, also selbst Messdaten erzeugt. Derartig große Textdateien, die
ich dann noch mit einem Editort bearbeiten müßte, sind mir da nicht
untergekommen. Lediglich beim CT gab es eine Datendatei mit ca. 2GB. Da
waren aber nur die ersten 2kB reiner Text der Rest war binär.
Jörg W. schrieb:> es soll Leute> geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das> Gegenteil von "Fanboys".
Schrieb ich ja z.B cat, more, grep und Konsorten.
Mombert H. schrieb:> Natürlich hast du den Rest meines Beitrags nicht zitiert ;-)
Warum sollte ich das das tun, wenn ich nur Deine Frage beantworte?
Nano schrieb:> Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im> einfachsten Fall ASCII Text.
Naja heute ist ja XML die Wunderwaffe. Das hat zwar durchaus seine
Berechtigung und die Daten sind sehr gut lesbar, aber es bläht die Datei
eben auch deutlich auf.
Die Datendateien meines Programmes waren für eine Messung zwischen 7 und
10kB groß, macht für eine vollständige Messreihe mit 7 Messungen
70-100kB. Der Typ der meine Software neu programmieren sollte hat da auf
XML gesetzt, woraufhin sich das Datenaufkommen verzehnfacht hat. Gut
spielt nunmehr keine Rolle mehr da man die Neuentwicklung nach 6 Jahren
eingestellt hat und mit meinem Programm weiter arbeitet.
Noch sparsamer im Platzverbrauch war mein Vorgängerprogramm, das hat für
einen kompletten Datensatz weniger als 10kB gebraucht. Nachteil war
natürlich, das man sich die Daten nur mit dem Programm selbst anschauen
konnte, da sie im Binärformat gespeichert waren.
Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit
einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht.
Zum Beispiel bei meiner Wetterstation werden alle 300s die Daten
gespeichert (pro Datensatz 52 Werte) und die werden selbstverständlich
nicht als Text sondern in einer Datenbank gespeichert. Derzeit sind sind
ca. 7100 Datensätze gespeichert bei einer Datenbankgröße von 1,5MB. Und
ja man kann sich das mit den passenden Tools, tabellarisch aufbereitet
ansehen, allerdings ist das eher ein mühsames Geschäft. Ich stelle mir
gerade vor das als ne Textdatei gespeichert und dann mit dem vi
angeschaut, dannach wäre man dann reif für die Klappse.
udok schrieb:> Wir leben auch nicht mehr in den 90'ern.
Stimmt, Du lebst sogar noch in den 1970'zigern, da wurde der vi
erfunden, also zu einer Zeit wo Speicherplatz noch knapp war und das
Datenaufkommen in Byte oder kB gemessen wurde.
Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt, dass es eine ältere Version war.
Aber sicher keine von 1990. :)
Alles danach wurde doch nur noch auf VM-Systemen benutzt.
MS-DOS mit gerade mal 64 KiB linear adressierbarem Adressbereich ist nun
so ziemlich das letzte, was man irgendwie als Referenz benutzen würde.
Zeno schrieb:> Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit> einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht.
Das könnte auch gzipped CSV, JSON oder YAML sein. Dafür gäbe es schon
fertige Frontends, Libraries und Tools. Gerade bei großen Datenmengen
ist es aufwändig und daher meistens ziemlich dumm, das Rad neu erfinden
zu wollen. Meine Güte!
Kiffer schrieb:> Das könnte auch gzipped CSV, JSON oder YAML sein.
Klar groß, größer, am größten - für sehr große Datenmengen sind
Textdateien ungeeignet.
JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man
sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt.
Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung,
und da sind die Datenmengen eher überschaubar.
Zeno schrieb:> Klar groß, größer, am größten - für sehr große Datenmengen sind> Textdateien ungeeignet.> JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man> sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt.> Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung,> und da sind die Datenmengen eher überschaubar.
Sieh an, Pippi Langstrumpf erklärt uns die Welt.
Selbstverständlich ist JSON für die Speicherung von grossen Datenmengen
geeignet und wird dafür benutzt.
Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header
mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel
mit den Werten kostet kaum Overhead und kann prima als Stream
verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und
getestete, stabile und performante Tools und Libraries dafür, die man
nutzen oder drauf aufbauen kann.
Solche Eigenschaften müsstest Du mit Deinem unprofessionellen Gebastel
erstmal hinbekommen, kleiner Held.
Jörg W. schrieb:> Kiffer schrieb:>> Meine Güte!>> Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie> sie sich ihre Arbeit organisieren.
Hab' ich das? Nö. Die einzigen, die hier anderen etwas vorschreiben
wollen, sind Na-no und Ze-no. Hast Du da vielleicht etwas verwechselt?
Kiffer schrieb:> Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header> mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel> mit den Werten kostet kaum Overhead und kann prima als Stream> verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und> getestete, stabile und performante Tools und Libraries dafür, die man> nutzen oder drauf aufbauen kann.
Das ist ja alles nicht durchaus richtig, aber kannst Du nicht bitte
einfach mal auf die Provokationen verzichten? In diesem Thread ist schon
genug provoziert worden, simple Besserwisserei sollte fürderhin reichen.
Nano schrieb im Beitrag #7125414:
> Lass mich raten, du gehörst zu denen, die sich aus ganz vielen Ecken> dutzende Bibliotheken für die kleinste Funktion ins Projekt einbinden,> weil du das alles nicht selber programmieren kannst und dann prahlst du> hier auch noch damit herum es besonders ineffektiv zu machen. Peinlich!
Erwartbar falsch geraten. Mit ein bisschen Erfahrung lernt man,
sinnvolle Entscheidungen zu treffen, wann man etwas selbst entwickeln,
testen und pflegen sollte, und wann das zu etwas führt, das erfahrene
Entwickler als NIH-Problem kennen. Nur Anfänger glauben, alles besser zu
können als der Rest der Welt.
Weißt Du, Hybris gehört zwar nach Larry Wall, dem Erfinder der Sprache
Perl, zu den Kardinaltugenden guter Entwickler. Faulheit aber auch!
> Und JSON IST ineffizient für große Datenmenge, da ist sogar CSV um> Welten besser!> JSON ist für kleine Datenmengen gedacht, in erster Linie dafür, wo man> normalerweise XML einsetzen würde.
Wo steht das? Wer sagt das? Du?
> JSON ist effizienter als XML, aber> bei mehren hundert MB ist es immer noch höchst ineffizient.
[ ] Du hast den Teil mit der Komprimierung verstanden.
[ ] Du hast den Teil mit dem Datenformat verstanden.
> Also arbeite mal an deinem Umgangston,
Na das sagt der Richtige.
Endlich!
vim 9 ist in Debian sid angekommen. Jetzt steht der weiteren Verwendung
nichts mehr im Wege, die Nutzerbasis wird sich erhöhen. Andere
Distributionen werden nachziehen. Die Bugbereinigung wird anlaufen. Der
tolle Editor lebt weiter. Aber der Resourcenverbrauch hat ja vom
einstigen Editor für Minimalisten ordentlich zugelegt. Wer eine
schlankere Version bevorzugt, kann es mit vim-tiny versuchen.
Max Mustermann schrieb:> Endlich!> vim 9 ist in Debian sid angekommen.
Am Mittwoch letzter Woche bereits – du bist zu langsam. Und am Samstag
wurde die Version in Testing aufgenommen – dessen Userbasis ist ja doch
ungleich größer, als die von Unstable.
Max Mustermann schrieb:> Endlich!> vim 9 ist in Debian sid angekommen.> ...> Andere Distributionen werden nachziehen.
Der Nachzügler ist – nach über 5 Wochen – wohl eher Debian selber. Zum
Vergleich: Arch hat dafür 5,7 Stunden gebraucht :)
Siggi schrieb:> Wann wird wohl Ubuntu und Linux-Mint nachziehen?
Die neuste Version von vim ist für Mainstream-Distries einfach
unwichtig. Standardmäßig haben die ohnehin nur vim-tiny. So als
Backup-Lösung wenn die GUI nicht funktioniert und man deshalb keinen
richtigen Editor verwenden kann.
Nano schrieb:> Oben habe ich in meinem Beitrag> Beitrag "Re: Vi Editor ausgestorben?">> ja ausführlich und argumentativ begründet, warum man für Messdaten keine> einzige große Datei nutzen sollte.
Du schreibst in dem verlinkten Beitrag:
Nano schrieb:> Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen,> dann sollte man über ein Binärformat und ein Programm, über das man auf> diese zugreift und das diese aufbereitet, nachdenken.> Grund:> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.
In dieser Argumentation fehlen mir einige praktische und ökonomische
Perspektiven.
Ja, Textdat(ei)en sind vielleicht um einen Faktor zwei bis fünf größer,
dafür aber sofort und ohne weiten Investitionsaufwand für die
Softwareentwicklung von jedem Menschen lesbar. Es gibt eine riesige
Vielfalt fertiger, leisungsfähiger und sehr feingranular konfigurier-
und steuerbarer Programme, um Textdat(ei)en anzeigen und verarbeiten zu
können, denk nur mal an grep(1), sed(1), awk(1), oder an perl(1), oder
auch gnuplot(1) oder die Programme aus dem graphviz-Paket. Oder an
Pandas in Verbindung mit Matplotlib, Seaborn, Plotly oder Bokeh, um nur
ein paar Beispiele aufzuführen.
Obendrein sind Textdat(ei)en flexibler als Binärdat(ei)en, das heißt: in
einer Textdatei kann ich ohne Weiteres verschiedene Logformate speichern
und anschauen (denk nur mal an die Systemlogs unter Linux und UNIX),
während das bei binären Dateien zwar machbar, aber mit wesentlich mehr
Aufwand verbunden ist -- welcher obendrein bei jeder Änderung erneut
anfällt. Wenn der, der die Daten verarbeiten soll, dann vielleicht nicht
identisch mit dem Softwareentwickler ist, werden Deine Binärdat(ei)en
sehr schnell zu einem bösartigen ökonomischen Problem.
Meinen Rechner riesige Textdat(ei)en durchsuchen, verarbeiten, anzeigen
zu lassen, kostet mich wenig. Einen Softwareentwickler an die
Entwicklung eines Binärformates und dann bei jeder Änderung wieder daran
zu setzen, kostet mich hingegen erstens Zeit und zweitens Geld. Und wenn
mal ein Sensor spinnt und kaputte Daten in eine Binärdatei schreibt, ist
womöglich die ganze Datei mit allen Daten verloren, wenn ich nicht schon
wieder viel Geld ausgeben und einen Entwickler daran setzen will.
Nano schrieb:> Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf,> dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier> zu großen Verlusten führen.
Dieses Argument zieht nur, wenn die Daten auch dann nützlich sind, wenn
sie nur in Teilen vorliegen. Bei vielen Messungen haben die Daten aber
nur dann einen Wert, wenn sie über die gesamte Messung hinweg
durchgängig vorliegen. Das heißt: wenn die Aufzeichnung wegen eines
Ausfalls mitten während der Erhebung der Daten endet, ist der gesamte
Test inklusive aller erhobenen Daten nutz- und wertlos.
> Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei> schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust> mehr Sicherheit und das erlaubt dann auch die alten Dateien zu> komprimieren und so Speicherplatz zu sparen.
Textdat(ei)en kann man auch komprimieren, wußtest Du das schon? Meistens
sogar mit ziemlich guten Kompressionsraten...
Mein grundsätzliches Herangehen an solche Datenmengen ist allerdings
ohnehin ein gänzlich anderes: egal, wie ich die Dat(ei)en bekomme, pumpe
ich sie sofort in meinen Opensearch-Cluster. Nicht, weil der die Daten
dann binär speichert, sondern weil der extrem performant und obendrein
hochverfügbar ist, meine Daten direkt und trotzdem strukturell flexibel
in revertierten Indizes speichert, die sich wiederum unfaßbar schnell
durchsuchen, wunderbar mit Opensearch-Dash visualisieren, oder mit allen
möglichen Programmier- und Skriptsprachen weiterverarbyten lassen.
Deswegen kann ich bei Eurem Gespräch über Speicherformate von
Massendaten nur bedauernd mit dem Kopf schütteln -- und dabei vor allem
darüber, daß Du die inhärenten Vorzüge von Textdat(ei)en entweder nicht
(an)erkennen willst oder nicht kennst. Dateien, Jungs, echt mal... das
ist doch total Neunziger. ;-)
Zuletzt sei eine Kleinigkeit angemerkt, die Du anscheinend ebenfalls aus
Deinen Augen verloren hast. Nämlich, daß man als Profi oft gar keine
andere Wahl hat, als Daten so zu verarbeiten, wie man sie bekommt.
Ein T. schrieb:> egal, wie ich die Dat(ei)en bekomme, pumpe> ich sie sofort in meinen Opensearch-Cluster.
Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht,
dass Data-Mining generell uninteressant ist. Geht aber auch etwas besser
mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich
Kunstprodukte ein.
Das passiert zwar auch bei wichtigen Gutachten - naja, sehr viele Leute
sind nicht gut in Statistik (trotz der entsprechenden guten Ausbildung),
und ich eigentlich auch nicht, wenn ich mir keine Mühe gebe - ist
trotzdem nicht schön, und so wohl eher ein Grund zum schmunzeln trotz
des düsteren Hintergrundes.
rbx schrieb:> Ein T. schrieb:>> egal, wie ich die Dat(ei)en bekomme, pumpe>> ich sie sofort in meinen Opensearch-Cluster.>> Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht,> dass Data-Mining generell uninteressant ist.
Verrätst Du mir, wie Du an dieser Stelle auf "Data Mining" kommst? War
es das Stichwort "Cluster", das Dich getriggert hat, oder wie kam das
zustande?
Im Kern geht es erst einmal darum, die Daten möglichst schnell und
möglichst unaufwändig mir und den Kollegen zugänglich zu machen, damit
wir mit den Daten arbeiten können. Dafür werden wir nämlich bezahlt.
Vielleicht magst Du Dir die Software mal näher anschauen, um zu
verstehen, was sie leistet und was nicht.
> Geht aber auch etwas besser> mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich> Kunstprodukte ein.
Schon der erste Schritt, nämlich die explorative Datenanalyse (EDA),
kann ohne fundierte Kenntnisse der Statistik nicht funktionieren, und
für jede Tätigkeit im Bereich des Data Mining gilt dasselbe. Ich bin
daher äußerst irrigiert, wie man da irgendwelche Widersprüche ausmachen
kann. Kann es sein, daß Du Dich mit Data Mining nicht wirklich auskennst
und daher einigen (durchaus populären) Mißverständnissen aufgesessen
bist? Oder, anders gefragt: was glaubst Du eigentlich, was wir im Data
Mining so machen, wie das funktioniert und, vor allem, wie das ohne
fundierteste Kenntnisse in Statistik gehen könnte?
Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Hauptsache
irgendwelche vagen Andeutungen machen, damit keiner weiß worum es geht
und man dann anderen Ahnungslosigkeit vorwerfen kann? Oder warum
antwortet man überhaupt darauf, wenn gar nicht klar ist, worum es geht?
Ein Troll gegen den anderen Troll.
prust schrieb:> Was hat eure Datenpornografie jetzt mit dem Thema zu tun?
Nach 'nem Monat Pause hat sich wieder jemand an einer (längst
widerlegten) Aussage betreffend der Verwendung von großen Textfiles
hochgezogen,
Thread beobachten
Seitenaufteilung abschalten
