Vi Editor ausgestorben?

[3.14 (Gast)]

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.

[Johannes O. (jojo_2)]

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.

[Yalu X. (yalu) (Moderator)]

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:

/*
 * Lorem ipsum
 * dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
 * eirmod tempor invidunt
 * ut labore et dolore magna aliquyam erat, sed diam
 * voluptua.
 *
 * At vero eos et
 * accusam et justo duo dolores et ea rebum. Stet clita kasd
 * gubergren, no sea takimata sanctus est
 * Lorem ipsum dolor sit amet.
 */

int main(void) {
  return 0;
}

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:

/*
 * Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
 * eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
 * voluptua.
 *
 * At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd
 * gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
 */

int main(void) {
  return 0;
}

Das funktioniert natürlich auch bei Kommentaren mit // oder #.

[Nano (Gast)]

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.

[Jack V. (jackv)]

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.

[3.14 (Gast)]

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.

[Zeno (Gast)]

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.

[Nano (Gast)]

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.

[Nano (Gast)]

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?

[(prx) A. K. (prx)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Jack V. (jackv)]

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 :)

[Jack V. (jackv)]

(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?

[Zeno (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Zeno (Gast)]

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.

[Zeno (Gast)]

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.

[Zeno (Gast)]

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.

[rbx (Gast)]

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)

[(prx) A. K. (prx)]

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. ;-)

[Zeno (Gast)]

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.

[Norbert (Gast)]

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…

[3.14 (Gast)]

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.

[rbx (Gast)]

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?

[Nano (Gast)]

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.

[Nano (Gast)]

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.

[Walter K. (walter_k488)]

Nano schrieb:
> …
> Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.

LOL

[Norbert (Gast)]

Ich habe hier eine gerade mal 64MiB große Textdatei.

~/tmp$ l -h XXX
-rw------- 1 norbert norbert 64M Jul  3 20:02 XXX

Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:

  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

Wenn ich die mit nano öffne, dann werden ca 5.1GiB Speicher benötigt:

  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 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. (prx)]

Norbert schrieb:
> Macht nano da etwas ganz Besonderes?

Er ist bloss neuer, von 1999 statt 1991, und konnte sich das leisten.

[Norbert (Gast)]

(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… ;-)

[xy (Gast)]

Zum Bearbeiten von Dateien verwende ich echo und sed, wenn kein ed da 
ist.

[Le X. (lex_91)]

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.

[Zeno (Gast)]

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.

[Norbert (Gast)]

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?

[Le X. (lex_91)]

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.

[Norbert (Gast)]

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.

[rbx (Gast)]

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.

[3.14 (Gast)]

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?

[rbx (Gast)]

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.

[(prx) A. K. (prx)]

rbx schrieb:
> Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich
> geschmacksbefreit allerdings,

Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt 
nennt?

[rbx (Gast)]

(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.

[Nano (Gast)]

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.

[Nano (Gast)]

Norbert schrieb:>
> Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:
>

  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

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.

[Zeno (Gast)]

Nano schrieb:
> Das
> ist aber kein muss für einen Texteditor so etwas zu können.
Trotzdem können das moderne Texteditoren - zumindest unter Windows.

[Norbert (Gast)]

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.

[rbx (Gast)]

Norbert schrieb:
> Aber der Punkt ist ein anderer:
> 5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp
> 80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das
> lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung
> erklären. Oder einer massiv fehlerhaften Implementation. Der
> Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300%
> der Zeit braucht.

Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der 
Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch 
auf eine 3,5 DD Diskette passen.
Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im 
Arbeitsspeicher (Windows Taskmanager).

Das Installationsprogramm von gvim verbraucht auch nicht unbedingt viel 
mehr Speicherplatz, so 10 MB. Vieviel Speicher der jetzt nach der 
Installation belegt, oder wieviel Arbeitsspeicher im Betrieb, kann ich 
nicht sagen, aber allzuviel mehr wird das auch nicht sein.

https://www.vim.org/download.php

Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich 
bei der "Recherche" schon ein wenig schmunzeln:

https://superuser.com/questions/938093/nano-alternative-for-windows-powershell

https://nano-editor.org/dist/win32-support/

[mh (Gast)]

Openbsd schrieb:
> Wenn ja, warum?

Weil neovim offensichtlich die Antwort auf die Frage nach dem Leben, dem 
Universum und dem ganzen Rest ist.

:: Starting full system upgrade...
Packages (50) borg-1.2.1-1 [...]  neovim-0.7.2-2 [...]
[...]
(42/50) upgrading neovim [##################################################] 100%
[...]

[Jörg W. (dl8dtl) (Moderator)]

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.

[Norbert (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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:

    PID USER       PRI  NI  VIRT   RES   SHR S  CPU% MEM%   TIME+  Command
   8778 yalu        20   0  164M   98M 18648 S   0.0  1.7  0:00.23 vim big1
   8183 yalu        20   0  151M  147M  3116 S   0.0  2.5  0:00.53 nano big1

Die Zahlenwerte sowohl für RES als auch für TIME sind also deutlich
kleiner als bei dir. Der Speicherverbrauch hängt aber auch etwas vom
Inhalt der Datei ab.

Die Datei big1 enthält 1048576-mal die Zeile

012345678901234567890123456789012345678901234567890123456789012

jeweils mit einem LF am Ende, also 64 Byte/Zeile. Die Gesamtgröße der
Datei ist damit wie bei dir 64 MiB.

Welchen Inhalt hat bei dir die Datei XXX?

[Norbert (Gast)]

Yalu X. schrieb:
> Welchen Inhalt hat bei dir die Datei XXX?

head -c64M /dev/zero | tr "\000" "\n" >XXX

Nochmal getestet, Werte bleiben etwa gleich.

[Norbert (Gast)]

Man kann dem ›nano‹ sogar in ›htop‹ beim Ackern zusehen.
Diesmal hat er keine 7.3 Sekunden gebraucht, er war in 7.06 Sekunden 
fertig.

[udok (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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).

[rbx (Gast)]

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.)

[Norbert (Gast)]

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. (Gast)]

Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir im Büro 
für Java EE Anwendungen.

[Norbert (Gast)]

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?

[udok (Gast)]

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...

[rbx (Gast)]

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.

[Nano (Gast)]

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.

[udok (Gast)]

Es gibt unter Windows auch noch den WinVi, leider wird der nur sehr 
selten geupdated.

[Nano (Gast)]

Norbert schrieb:
> Yalu X. schrieb:
>> Welchen Inhalt hat bei dir die Datei XXX?
>
>

head -c64M /dev/zero | tr "\000" "\n" >XXX

>
> Nochmal getestet, Werte bleiben etwa gleich.

Was du da produziert hast, ist vieles, aber keine Textdatei, wie du 
anfangs behauptet hast.

Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles 
modifiziert, was kein Teil einer Textdatei ist.
Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner.

Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine 
Arbeit. Für Binärdateien nimm einen Hexeditor, wie ich es anfangs schon 
sagte.

[Nano (Gast)]

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.

[Nano (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

Nano schrieb:
> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du
> anfangs behauptet hast.

$ file XXX
XXX: ASCII text

[Nano (Gast)]

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.

[Nano (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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):

                 VSZ     RSS
vi:           350496  343320
nano:        5252636 5246748
Emacs (GUI):  790164  129796
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:

$ jot -r 11500000 10000 99999 > XXX
$ wc XXX
11500000 11500000 69000000 XXX

Sind jetzt ein paar MB mehr als vorher, aber nur noch 11,5 Millionen 
Zeilen.

                 VSZ     RSS
vi:           129808  122972
nano:         908136  902160
Emacs (GUI):  792220  131716
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.]

[Norbert (Gast)]

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

#!/usr/bin/python3
import sys
import random
N = 4 * 3600 * 10000  # Vier Stunden lang, 100µs pro Messung
print(f'Zeilen:{N}')
offset_µs = 8_500_972_123  # µs Zeitstempel
with open('file.testfile', 'w') as fr:
    for n in range(N):
        fr.write(f'{offset_µs + n:12d} {random.randrange(0,4095):4d} {random.randrange(0,4095):4d} {random.randrange(0,4095):4d}\n')

und sieh' selbst was nano alles nicht kann und was ein richtiger Editor 
problemlos kann.

[Norbert (Gast)]

Speichernutzung geht von ~7GB auf ~12GB
Ladezeit: knapp 18 Sekunden
die Eingabe von 100000000<Enter> springt zur 100 Millionsten Zeile in 
einem Wimpernschlag.

[Norbert (Gast)]

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.

[Oliver S. (oliverso)]

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

[Yalu X. (yalu) (Moderator)]

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:

typedef struct linestruct {
                             // Größe in Byte
  char *data;                //   8
  ssize_t lineno;            //   8
  struct linestruct *next;   //   8
  struct linestruct *prev;   //   8
  short *multidata;          //   8
  bool has_anchor;           //   4
} 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.

[Norbert (Gast)]

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 ;-) ).

[Ein T. (ein_typ)]

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.

[Ein T. (ein_typ)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.

[Norbert (Gast)]

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.

[Ein T. (ein_typ)]

Jörg W. schrieb:
>

>                  VSZ     RSS
> nano:        5252636 5246748
> Emacs (GUI):  790164  129796
>

>
>

>                  VSZ     RSS
> nano:         908136  902160
> Emacs (GUI):  792220  131716
>

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...

[Norbert (Gast)]

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.

[Norbert (Gast)]

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. ;-)

[Jörg W. (dl8dtl) (Moderator)]

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.

[Nano (Gast)]

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.

[Nano (Gast)]

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:
>
>

> typedef struct linestruct {
>                              // Größe in Byte
>   char *data;                //   8
>   ssize_t lineno;            //   8
>   struct linestruct *next;   //   8
>   struct linestruct *prev;   //   8
>   short *multidata;          //   8
>   bool has_anchor;           //   4
> } linestruct;
>

>
> 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.

[Nano (Gast)]

Ü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.

[Jörg W. (dl8dtl) (Moderator)]

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?

DESCRIPTION
       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.

[Ein T. (ein_typ)]

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. ;-)

;-)

[Norbert (Gast)]

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!

[Nano (Gast)]

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.

[Ein T. (ein_typ)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Leute, bitte tauscht eure Kindergarten-Anschuldigungen ("Umschuler" 
(sic), "Werkzeuge für Erwachsene", "Gestümper") künftig per Email aus. 
Das Forum braucht sowas nicht.

[Jörg W. (dl8dtl) (Moderator)]

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.)

[Nanolator (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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 ;-)

[Zeno (Gast)]

Schon toll wie man sich am Thema "Texteditor" aufgeilen kann.

[Nanolator (Gast)]

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

[Ein T. (ein_typ)]

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.

[Nano (Gast)]

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.

[Norbert (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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. 
;-)

[Nano (Gast)]

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.

[Ein T. (ein_typ)]

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:

~                    VIM - Vi IMproved                      
~                                                           
~                     version 8.1.3741                      
~                 by Bram Moolenaar et al.                  
~         Modified by [e-mail]           
~       Vim is open source and freely distributable         
~                                                           
~              Help poor children in Uganda!                
~      type  :help iccf<Enter>       for information        
~                                                           
~      type  :q<Enter>               to exit                
~      type  :help<Enter>  or  <F1>  for on-line help       
~      type  :help version8<Enter>   for version info       
~                                                           
~              Running in Vi compatible mode                
~      type  :set nocp<Enter>        for Vim defaults       
~      type  :help cp-default<Enter> for info on this

[Jörg W. (dl8dtl) (Moderator)]

Ein T. schrieb:
> Ein Aufruf von "vi" hingegen gibt das Folgende aus:

Hmm, das ist dann schon bissel irreführend.

[Nano (Gast)]

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.

[Jack V. (jackv)]

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

[Ein T. (ein_typ)]

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.

[Mombert H. (mh_mh)]

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.

[Nano (Gast)]

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.

[Le X. (lex_91)]

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.

[Nano (Gast)]

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.

[Norbert (Gast)]

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… ;-)

[Mombert H. (mh_mh)]

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.

[Ein T. (ein_typ)]

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.

[⁣Gast (Gast)]

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.

[Ein T. (ein_typ)]

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? ;-)

[rbx (Gast)]

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

[Le X. (lex_91)]

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)

[Nano (Gast)]

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.

[Mombert H. (mh_mh)]

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.

[Nano (Gast)]

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.

[Alexander S. (alesi)]

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 (Gast)]

BTW, der popularity Contest bei Debian ist auch immer wieder 
interessant:

https://qa.debian.org/popcon.php?package=nano

https://qa.debian.org/popcon.php?package=vim


Die Spalte "installed base" ist wenig aussagekräftig, wenn nano und 
vim-tiny vorinstalliert kommt, aber zumindest bei der Spalte vote dürfte 
man aussagekräftigere Daten haben.
Vote steht da, wie die Beschreibung zeigt für:
"Vote is the number of people who use this package regularly"

Leute, die bei der Installation von Debian dieser Survey Funktion 
Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern 
zu.
(Anmerkung: Ist wie beim nicht Wählen gehen).

Nano liegt da mit 28311 votes auf Rang 817
Vim mit 20073 votes auf Rang 1013
und
vim-tiny mit 11061 votes auf Rang 1423

Es scheint also viele zu geben, denen vim-tiny genügt oder denen nicht 
aufgefallen ist, dass sie einen abgespeckten vim verwenden.

Andere Editoren habe ich mir auch mal angesehen:

Joe 1146 votes, Rang 4218
https://qa.debian.org/popcon.php?package=joe

Bei Emacs bin ich mir gerade nicht so sicher, ob emacs ohne namenszusatz 
nur für so ein Metapaket steht. Also guckt euch die Liste selber an:
https://qa.debian.org/popcon.php?package=emacs


Diverse GUI Editoren:
kate v 4910 r 2215
https://qa.debian.org/popcon.php?package=kate

gedit
v 13374  r 1272
https://qa.debian.org/popcon.php?package=gedit

geany
v 1853  r 3409
https://qa.debian.org/popcon.php?package=geany

pluma
v 2420  r 3053
https://qa.debian.org/popcon.php?package=pluma

mousepad
v 3917  r 2471
https://qa.debian.org/popcon.php?package=mousepad

Schade, dass man mehrere Pakete nicht auf einmal vergleichen kann.

[Jack V. (jackv)]

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.

[rbx (Gast)]

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.

[Nano (Gast)]

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.

[Jack V. (jackv)]

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.

[Frank M. (ukw) (Moderator)]

Nano schrieb:
> head -c64M /dev/zero | tr "\000" "\n" >XXX

Norbert schrieb:
> Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:

>   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

> Wenn ich die mit nano öffne, dann werden ca 5.1GiB Speicher benötigt:

>   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

Es geht auch anders:

$ head -c64M /dev/zero | tr "\000" "\n" >XXX
$ fe XXX

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  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:

buf1   |   gap   | buf2
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:

  size1--;
  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.

[mh (Gast)]

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.

[Frank M. (ukw) (Moderator)]

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.

[mh (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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:

                    If you think you understand it, 
                              You Don't, 
                            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 ;-)

[Yalu X. (yalu) (Moderator)]

Frank M. schrieb:
>> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die
>> Lücke fällt.
>
> Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle
> steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb
> eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000
> und dann 8000.

Selbst wenn: Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs
aktuellen PC kein Ding.

[Frank M. (ukw) (Moderator)]

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.

[900ss (900ss)]

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. ;)

[Frank M. (ukw) (Moderator)]

Wie schnarchlangsam zeilenorientierte Editoren arbeiten, kann man 
einfach nachprüfen, wenn man XXX mal auf 640 MB vergößert.

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:

$ time fe XXX
real    0m3.046s
user    0m2.930s
sys     0m0.116s

$ time vi XXX
real    0m12.316s
user    0m11.648s
sys     0m0.668s

$ time nano XXX
real    0m56.437s
user    0m46.112s
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

[rbx (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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

user + sys = real

rauskommt. Idle-Zeiten gab es also keine ;-)

[Nano (Gast)]

Frank M. schrieb:
> Dann startet man seinen Wunscheditor und drückt sofort die erforderliche
> Tastenkombination, um den Editor wieder zu verlassen:
>

> $ time fe XXX
> real    0m3.046s
> user    0m2.930s
> sys     0m0.116s
> 
>

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.

[Le X. (lex_91)]

Kommt jetzt also vim vs. fe?
Wann gehts los? Wer sind die Kombattanten? ;-)

[Ein T. (ein_typ)]

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.

[rbx (Gast)]

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)

[Ein T. (ein_typ)]

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. ;-)

[Jörg W. (dl8dtl) (Moderator)]

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.

[Nano (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Rolf M. (rmagnus)]

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.

[rbx (Gast)]

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.

[Le X. (lex_91)]

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.

[Ein T. (ein_typ)]

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.

[Ein T. (ein_typ)]

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.

[Ein T. (ein_typ)]

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?!

[Le X. (lex_91)]

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) ;-)

[Jörg W. (dl8dtl) (Moderator)]

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™-

[Le X. (lex_91)]

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.

[Jack V. (jackv)]

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.

[Rolf M. (rmagnus)]

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:

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[rbx (Gast)]

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

[Ein T. (ein_typ)]

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. ;-)

[Ein T. (ein_typ)]

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?

[Jörg W. (dl8dtl) (Moderator)]

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.)

[Ein T. (ein_typ)]

Rolf M. schrieb:
>

> tar c mydir | gzip > mydir.tar.gz
>

Tipp für größere Archive:

tar c mydir | pigz > mydir.tar.gz

HF! ;-)

[Ein T. (ein_typ)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.)

[Nano (Gast)]

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:

apt search ^vim-youcompleteme
Sortierung… Fertig
Volltextsuche… Fertig
vim-youcompleteme/stable,now 0+20200825+git2afee9d+ds-2 all  [installiert]
  fast, as-you-type, fuzzy-search code completion engine for Vim

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?

[Rolf M. (rmagnus)]

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?

vim-addons install youcompleteme

Ich musste noch zusätzlich folgendes tun:

sudo apt install python3-distutils

[Ein T. (ein_typ)]

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.

[Ein T. (ein_typ)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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?

[Nano (Gast)]

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:

>

> vim-addons install youcompleteme
>

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:
>

> sudo apt install python3-distutils
>

Das wurde bei mir automatisch mitinstalliert und war schon drauf.

[Nano (Gast)]

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!

[rbx (Gast)]

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

[Nano (Gast)]

rbx schrieb:
> Nano schrieb:
>> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es
>> nett, wenn man nicht selber zählen muss.
>
> Könnte man aber auch einer Suchmaschine fragen:
>
> https://vim.fandom.com/wiki/Word_count

Da steht nirgends etwas von "word count between """ und das war ja meine 
Frage.

Um eine generelle Zeichenzählung geht es ja gerade nicht.
Und ja, sicher kann man das wie oben mit etwas mehr Eingabeparametern 
dann auch irgendwie hinbiegen, aber diese aufwendigere Methode zeigt 
dann auch, dass das Zeichenzählen zwischen zwei "" nicht explizit 
vorgesehen war.
Und das wollte ich wissen ob es da entsprechendes gibt.

[Nano (Gast)]

Nano schrieb:
> Da steht nirgends etwas von "word count between """ und das war ja meine
> Frage.

Korrektur ich meinte: character count beteen "".

[Yalu X. (yalu) (Moderator)]

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.

[Nano (Gast)]

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.

[Yalu X. (yalu) (Moderator)]

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?

[Rolf M. (rmagnus)]

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.

[Yalu X. (yalu) (Moderator)]

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.

[Alexander S. (alesi)]

Einige hier werden es bereits kennen: Seite 19, "Editors (a touchy 
subject)"
http://www.cs.cmu.edu/afs/cs/academic/class/15213-f15/www/recitations/linux_boot_camp.pdf

[Nano (Gast)]

Alexander S. schrieb:
> Einige hier werden es bereits kennen: Seite 19, "Editors (a touchy
> subject)"
> 
http://www.cs.cmu.edu/afs/cs/academic/class/15213-f15/www/recitations/linux_boot_camp.pdf

Das Original findet man hier, kein Grund eine dicke PDF zu verlinken:

https://xkcd.com/378/

[rbx (Gast)]

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  )

[willi (Gast)]

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?

[Jörg W. (dl8dtl) (Moderator)]

willi schrieb:
> vim vs emacs?

Nö, war nicht die Frage.

[Ein T. (ein_typ)]

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.

[willi (Gast)]

Jörg W. schrieb:
> willi schrieb:
>> vim vs emacs?
>
> Nö, war nicht die Frage.

Irgendwie schon oder nicht? Ist vim ausgestorben (zu Gunsten von emacs)?

[Ein T. (ein_typ)]

rbx schrieb:
> Suchmaschine spukt u.a. aus:

In Deiner Suchmaschine spukt es? 8-O

[Jörg W. (dl8dtl) (Moderator)]

willi schrieb:
> zu Gunsten von emacs

Nein, dieser Teil der Frage stand nie zur Debatte.

[spricht eher dafür (Gast)]

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 (Gast)]

emacs vs vim war gestern.

heute gilt vim vs. neovim.

und morgen wieder emacs vs. neovim.

weil vim gegen neovim verlieren wird.

[Jörg W. (dl8dtl) (Moderator)]

Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich 
ging's ja die ganze Zeit um vim vs. nano.

[Ein T. (ein_typ)]

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.

[Nano (Gast)]

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 (Gast)]

Nano schrieb:
> Jörg W. schrieb:
>> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich
>> ging's ja die ganze Zeit um vim vs. nano.
>
> Nein, darum ging es nie. Es gab hier lediglich vim Fanboys *, wie man dies
> und das in nano löst. Es war am Ende also ein nano only Thread.

Satz vergessen:

*die wissen wollten.

[Jörg W. (dl8dtl) (Moderator)]

Nano schrieb:
> Es gab hier lediglich vim Fanboys

Und nano Fanboys. ;-)

[Mombert H. (mh_mh)]

Jörg W. schrieb:
> Und nano Fanboys. ;-)
nano oder Nano? Ich bin ein echter Nano Fan. Selten ist die ▼ 
Entscheidung so einfach. :-)

[spricht eher dafür (Gast)]

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....

[rbx (Gast)]

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.

[udok (Gast)]

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.

gg - geht nicht
da" - geht nicht
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.

                vi-neatvi:       6475
                 vi-WinVi:      31191
                   vi-vis:      42059
                 Notepad2:      55996
      vi-BSD_4_4_nvi.1.43:      94195
        vi-nvi-Berkely_vi:     121728
                 vi-Elvis:     149560
                Notepad++:     254831
                   vi-vim:     726514
                    Emacs:    2142385