coolman schrieb:> Ich finde es spannend, dass in den letzten wenigen Jahren immer mehr> deutschsprachige Videos auf Youtube zu vim aufgetaucht sind. Es scheinen> also auch wieder mehr junge Leute Gefallen an vim zu finden.
Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem
Jahre 1990.
Scheint mir aber trotzdem eine akademische Erscheinung zu sein. Ich kann
mir kaum vorstellen, dass vim in der Industrie viel genutzt wird. Das
gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an
Universitäten und Forschungseinrichtungen. Selbst an Fachhochschulen
kennt man das nicht. Ich war vor 20 Jahren der einzige, der damit seine
Diplomarbeit geschrieben hat. Als Editor hatte ich übrigens emacs. Alle
anderen Leute hatten Word genommen.
3.14 schrieb:> Wobei der heutige vim ja schon eher benutzbar ist als der vi aus dem> Jahre 1990.> Scheint mir aber trotzdem eine akademische Erscheinung zu sein.
Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen
auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen
oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und
verbinden zu müssen. Es gibt Kollegen die wechseln nun zu Neovim. Aber
ich kann nicht bestätigen, dass es weniger geworden wäre.
3.14 schrieb:> Das> gleiche Phänomen ist ja auch TeX/LaTeX, das kennt man auch nur an> Universitäten und Forschungseinrichtungen.> [...] Ich war vor 20 Jahren der einzige, der damit seine> Diplomarbeit geschrieben hat.
Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs
Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor
allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei
größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen
Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem.
In nicht-Forschungs Firmen hast du andere Tools bzw. PR-Abteilungen
welche die Dokumente für dich "schön" machen.
Nano schrieb:> Kommentarzeichen
A propos Kommentare: Wenn man einen längeren Kommentaren editiert (etwas
hinzufügt oder löscht), sieht dieser hinterher meist ziemlich zerfranst
aus.
Beispiel:
1
/*
2
* Lorem ipsum
3
* dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
4
* eirmod tempor invidunt
5
* ut labore et dolore magna aliquyam erat, sed diam
6
* voluptua.
7
*
8
* At vero eos et
9
* accusam et justo duo dolores et ea rebum. Stet clita kasd
10
* gubergren, no sea takimata sanctus est
11
* Lorem ipsum dolor sit amet.
12
*/
13
14
intmain(void){
15
return0;
16
}
Statt die Zeilen mühevoll manuell zu verbinden, neu umzubrechen und die
Sternchen dabei wieder an die richtige Stelle zu setzen, kann man in Vim
auch einfach gqap eingeben oder alternativ den neu umzubrechenden
Ausschnitt des Kommentars markieren und gq eingeben. Danach sieht der
Kommentar wieder aufgeräumt aus:
1
/*
2
* Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
3
* eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
4
* voluptua.
5
*
6
* At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd
7
* gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.
8
*/
9
10
intmain(void){
11
return0;
12
}
Das funktioniert natürlich auch bei Kommentaren mit // oder #.
Rolf M. schrieb:> Der Punkt ist eben, dass man, wenn man sich mit vim auskennt, auch> schnell ein Kommando findet, mit dem man recht einfach eine Bearbeitung> machen kann, die vielleicht nicht so oft vorkommt, aber bei anderen> Editoren schnell umständlich werden kann.
Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022
haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt
wurden.
Hast du schon einmal in das Menü von bspw. Notepad++ geguckt?
Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer
jemals brauchen wird.
Nano schrieb:> Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022> haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt> wurden.
Süß … du weißt aber schon, dass der Thread mit einer Info zu einem neuen
Major-Release vom Vim wieder ins Leben gerufen worden ist, und dass
Major-Releases üblicherweise ein Zeichen für Weiterentwicklung sind?
Frag ja nur – bei dir liest’s sich so, als wäre die Entwicklung vor
dreißig Jahren eingeschlafen.
Nano schrieb:> Da ist so gut wie alles abgedeckt, was man im Leben als Editorbenutzer> jemals brauchen wird.
Nein.
Johannes O. schrieb:> Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen> auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen> oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und> verbinden zu müssen.
Aber für diesen Zweck braucht man doch nicht so ein kompliziertes
Werkzeug wie vim. Da reicht auch ein nano, der ebenfalls überall
installiert ist.
Jack V. schrieb:> Ist in der Tat schon erschreckend, wenn jemand den Nano so anbetet ...
Ja kann man so sehen. Aber Mein Gott, es gibt Schlimmeres und ob der
Nick wirklich vom gleichnamigen Editor herrührt weis nur der Nano
selbst.
Viel erschreckender finde ich da hingegen Leute, die sich sofort
angepisst fühlen, wenn man bezüglich ihrer Lieblingsspielzeuge, egal OS,
Programme (z.B. vi/vim) oder what ever, eine andere Meinung vertritt als
sie selbst. Das hat schon eher was Religiöses bzw. Sektenhaftes.
Jack V. schrieb:> ich nehm’ dich sowieso nicht mehr ernst
Das beruht dann wohl auf Gegenseitigkeit. Leute die ihre Werkzeuge
verteidigen wie eine Wölfin die Jungen, kann man eh nicht wirklich ernst
nehmen.
Jack V. schrieb:> Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich> die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung> deiner anderen Beiträge sein kann.
Da können die Mitleser aber wirklich froh sein das Du ihnen jetzt ein
Werkzeug in die Hand gibst, mit dem sie meine Beitäge ordentlich
bewerten können. Hoffentlich sind sie von soviel Erleuchtung nicht
geblendet.
Du hast wirklich keine anderen Probleme.
Jack V. schrieb:>
> Ist nur schade, dass du nicht benennen möchtest, welches Problem du> eigentlich mit Vim hast. Die oben geäußerte Vermutung mit dem Trauma war> natürlich nicht ernst gemeint
Wie schon gesagt, du musst einfach auch mal den Thread lesen. Das setzt
natürlich Leseverständnis voraus.
Also nochmal kurz für dich, für Configdateien und kurzen Notizen werde
ich kein Vim üben, weil ich da für das Bisschen keine leistungsfähigen
Editorfeatures brauche und da wo es interessant werden könnte, nämlich
beim Programmieren, da versagt er gegenüber einer IDE bei der
Debuggerintegration.
Warum soll ich mir das dann also antun?
Oben habe ich eine Frage gestellt zu diesem youcompleteme. Anstatt die
Frage mal zu beantworten, suchst du wieder Streit.
Und anstatt ne Vim Config mit Debuggerübersicht zu liefern, was ich ja
als Kritikpunkt erwähnt habe, machst du mit deinen persönlichen
Angriffen nur so weiter, und das nicht nur vorgestern und gestern,
sondern auch heute schon wieder. Wie das Kommentar auf Zeno zeigt, ich
habe deine heutigen persönlichen Angriffe wieder fett markiert:
Jack V. schrieb:> Ist in der Tat schon erschreckend, wenn jemand den *Nano so anbetet,* dass> er sich selbst danach benennt, und schon bei der kleinsten Andeutung,> dass ein Job in einem anderen Programm vielleicht einfacher und> effizienter erledigt werden könnte, *so durchdreht.*>> Zeno schrieb:>> Ich sollte gar nichts und schon gar nicht wenn das ein Jack sagt.>> Natürlich nicht – *ich nehm’ dich sowieso nicht mehr ernst,* selbst, wenn> du jetzt anfangen würdest, dich an der Realität zu orientieren.>> Das war nur ein Hinweis für Mitleser, dass du da ziemlich offensichtlich> die Fakten falsch dargestellt hast – was hilfreich bei der Bewertung> deiner anderen Beiträge sein kann.
Quelle:
Beitrag "Re: Vi Editor ausgestorben?"
All das zeigt, Jack V., du hast ein Problem mit dir selbst und das haben
hier schon viele erkannt und dir versucht mitzuteilen, aber du willst
nicht daraus lernen. Auch wurde dir bereits gesagt, dass dein Verhalten
fanatisch religiöse Züge annimmt, was man in der Tat so unterschreiben
kann, aber auch das bringt dich nicht zum Umdenken, du machst gerade so
weiter fanatisch radikalisiert alle anzugreifen, die vim nicht nutzen
wollen und bspw. andere Editoren haben, mit denen sie die genannten
Problemstellungen lösen können. Und wenn sie dir dann sagen, wie sie mit
den anderen Editoren diese Probleme lösen, insbesondere deine von dir
gestellten Aufgaben, dann passt es dir nicht dass es mit den anderen
Editoren auch geht und du greifst sie wieder an, was dein obiges
Kommentar eindrucksvoll zeigt.
Und auch hier, man achte mal auf die unsachlichen Wertungen und Wörter
in deiner Antwort. Ich habe sie ebenso nochmal fett hervorgehoben:
Jack V. schrieb:>
> – aber irgendwas muss diesem *irrationalen*> Zwang ja zugrunde liegen, aus dem du so krampfhaft zu zeigen *versuchst,*> dass Nano mindestens genauso leistungsfähig wäre und dabei selbst solche> offensichtlichen Absurditäten bringst, wie die Behauptung, deine> Strg-Orgie in Nano wäre mindestens genauso effizient, wie die drei> Tastendrücke im Vim, oder dass man statt fünf Tastendrücken doch einfach> ’nen fully bloated Qt-Editor hochreißen und mit der Maus *rumstochern*> sollte.
Wir haben hier also als Liste:
- irrationale Zwang
- krampfhaft
- Absurditäten
- Orgie
- fully bloated
- hochreißen
- rumstochern
Und das alles wieder bespickt mit deinen religiös getriebenen Vorwürfen,
wie dass ich krampfhaft versuchen würde dir zu beweisen, dass nano
genauso leistungsfähig wäre wie dein vim.
Dabei muss ich das nicht (Anmerkung: wie du weißt, nutze ich nano für
Configs und einfache Sachen) und war auch gar nicht der Fall, sondern du
hast mich gefragt, wie man dies und jenes Problem in nano lösen kann und
ich habe es dir lediglich beantwortet.
Und die Antwort, dass das mit nano geht, das ist das, was dich in deinem
reliögsen Wahn so stört und auf die Palme bringt, die gefällt dir nicht,
vermutlich weil du davon dein vim angegriffen fühlst, in das du so viel
Zeit und Aufwand reingesteckt hast und dann können andere ähnliche
Probleme ohne nennenswerten Aufwand lösen und deswegen greifst du nun
wieder, wie man es oben sehen kann, persönlich an und unterstellst mir
wieder einen Zwang und sonstiges krampfhaftes Verhalten.
Und das ist nicht nur bei mir so, denn auch Zeno hast du angegriffen.
Womit wir wieder bei der Erkenntnis sind, das du ein Problem mit dir
selbst hast und daran arbeiten solltest.
> Nano schrieb:>> Und das mach ich dann nicht in Nano, sondern nutze dafür dann die shell>> mit awk.>> Und bevor ich für so einen trivialen Job den Editor verlasse, den> Awk-Aufruf zusammenschreibe und auf die Datei loslasse, um sie dann> wieder im Editor zu öffnen und weiterzumachen, drücke ich halt meine> fünf Tasten im Editor. So what?
Wen interessiert was du machst? Du hast mich gefragt, wie ich das
löse und ich habe dir die Antwort gegeben. Und daraus machst du jetzt
wieder ein Problem.
Genau das, was ich oben gerade beschrieben habe. Niemand will wissen,
wie du deine Probleme mit vim löst, keiner hat dich gefragt und auch du
wurdest nicht gefragt, denn deine Frage hast du nicht an dich selbst
gestellt, sondern an mich gestellt, aber das was du anderen hier
vorwirfst, dass die krampfhaft versuchen würden, ihren Editor zu
verteidigen, das machst du hier selbst mit deinem vim.
Das sieht man hier deutlich, wenn ich dir sage, dass ich eine solche
Aufgabe mit awk löse und du dann ungefragt und krampfhaft darauf
hinweisen musst, warum vim besser sei als das CLI Tool awk sei und das
obwohl dich keiner danach gefragt hat. Dieses krampfhafte Wettstreit vim
gegen den Rest der Welt, der entsteht ausschließlich in deinem Kopf.
Also guck mal in den Spiegel und schließe nicht immer von dir auf
andere.
Johannes O. schrieb:> Es gibt Kollegen die wechseln nun zu Neovim.
Worin liegt eigentlich der Unterschied zwischen Vim und Neovim?
Was macht Neovim anders?
Wer kann die Frage objektiv und sachlich (Jack V., du bist nicht
gefragt) beantworten?
Ich glaube oben wurde schonmal "unterstützt das Language Server
Protokoll out of the box", erwähnt, aber wie geht es weiter?
Nano schrieb:> Was die vim Fraktion hier ständig übersieht ist, dass wir das Jahr 2022> haben und die anderen Editoren in den letzten 30 Jahren weiterentwickelt> wurden.
Das erste, was ich auf einem neuen System baue, ist ein File .vimrc mit
"syntax off" darin, damit ich das Zeug noch lesen kann. Irgendein
komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten
in einem dunklem Rot vor schwarzem Hintergrund zu verstecken. Sowie zu
Neuheiten. ;-)
Wie schon jemand oben benutze ich vi/vim seit zig Jahren, aber praktisch
nur im Kontext von Systemtechnik, nicht als Programmierplattform. Da ist
es ziemlich Banane, ob vi, vim oder neovim. Man kann das also trennen.
Ernsthafte Programmierung läuft anders ab. Und vi* ist halt drauf.
Nano schrieb:> Das mag sein, aber gerade wenn ich nur kleine Configdateien bearbeiten> will oder mal von der Bash aus kurz eine Notiz in eine TXT Datei> schreiben will, dann nehme ich dafür einen Editor der schnell geöffnet> und geladen ist
Ja, das geht mir auch so. Deswegen nehme ich für solche (wie auch für
alle anderen) Dinge Vim. Der erste Start dauert im Textmodus 0,2s im
Grafikmodus unter X11 1,2s. Das ist zwar etwas länger als bei Nano oder
Vi, aber diesen Zeitnachteil habe ich beim Editieren ganz schnell wieder
aufgeholt :)
> und den man dann auch, weil er so schnell wieder da ist, ohne> Planungsängste, dass er zum Öffnen wieder Zeit kostet, auch gleich> wieder schließen kann.
Beim wiederholten starten von Vim (egal ob im Text- oder Grafikmodus)
ist praktisch kein Zeitverzug erkennbar (also <0,1s).
3.14 schrieb:> Johannes O. schrieb:>> Nein. Wenn ich auf nem Server arbeite, ist dort in den meisten Fällen>> auch vim vorhanden. Das macht es sehr einfach kurz in Dateien zu schauen>> oder kleinere Änderungen vorzunehmen, ohne die komplette IDE starten und>> verbinden zu müssen.>> Aber für diesen Zweck braucht man doch nicht so ein kompliziertes> Werkzeug wie vim.
Natürlich wäre es Unfug, sich nur für das Editieren von Config-Dateien
in Vim einzuarbeiten. Wenn man aber Vim sowieso schon kennt, weil man
ihn auch für andere Dinge einsetzt, wäre es fast genauso unsinnig, sich
in Nano einzuarbeiten, selbst wenn dort die Einarbeitung nur eine
Viertelstunde dauert.
Nano schrieb:> Worin liegt eigentlich der Unterschied zwischen Vim und Neovim?> Was macht Neovim anders?
Neovim wird von einer Community ziemlich offen entwickelt und ist daher
deutlich agiler in der Entwicklung, als Vim, bei dem die Entwicklung in
einer einzelnen Person zusammenläuft. Das hat unter Anderem zu nativem
SLP-Kram geführt, und auch dazu, dass zum Scripten Lua zum Einsatz
kommen kann. Daneben gibt es noch eine Latte an Details, die alle
aufzuführen hier nicht zielführend sein wird.
Nano schrieb:> Jack V., du bist nicht> gefragt
Interessiert mich nicht. Sachliche Fragen bekommen sachliche Antworten –
im Gegensatz zu dem, was du dir einzubilden scheinst, habe ich nichts
gegen dich. Deine komische Textwüste weiter oben, mit den wilden
Vermutungen und Unterstellungen, bei gleichzeitigen
Rechtfertigungsversuchen der eigenen Irrationalität – naja, da sehe ich
mich wirklich nicht mehr gefragt. Das ist mir dann doch zu absurd :)
(prx) A. K. schrieb:> rgendein> komischer Vogel hat eine unbegreifliche Vorliebe dafür, Teile von Texten> in einem dunklem Rot vor schwarzem Hintergrund zu verstecken.
background=dark als Konfigurationsoption ist bekannt?
Nano schrieb:> nano> bietet das Entfernen oder Setzen von Kommentarzeichen mit der Taste ALT> + 3 an.
Oh, das kannte ich noch nicht. Bei Bashscripten und C-Files funktioniert
es perfekt.
Beim Mac muß man übrigens Shift+Option+3 drücken.
Jack V. schrieb:> background=dark als Konfigurationsoption ist bekannt?
Das Kernproblem sind nicht die Farbspiele diverser Tools, sondern meine
Gene. Ist bei LEDs nicht anders, jenen, die für rund 90% der männlichen
Bevölkerung gebaut sind und vom Rest verflucht werden.
Nano schrieb:> Denn Notepad++ nutzt direkt> die WinAPI und ist damit auch sehr schnell geladen.
Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile
bevorzuge ich da aber PSPad. Bei diesem kann man links eine
Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem
anderen Rechner verbinden und durch dessen Verzeichnisstruktur
navigieren.
Jack V. schrieb:> Schreib doch einfach, dass die Aufgabe mit Nano nicht sinnvoll zu lösen> ist, statt Gründe zu suchen, warum man das ja überhaupt nicht brauchen> würde. Ist halt nicht sein Gebiet, damit ist nichts verkehrt.
Tja bei Dir ist es genau anders herum. Du konstruierst eben einfach
etwas, um nachzuweisen das es ohne Dein Lieblingsspielzeug nicht geht.
Johannes O. schrieb:> Ein paar Bekannte und ich hatten damals auch unsere Facharbeiten fürs> Abi in LaTeX geschrieben. So wild ist das nicht. Ich sehe LaTeX vor> allem eher in IT-lastigen Forschungsbereichen. LaTeX skaliert bei> größeren Dokumenten sehr schön. 200+ Seiten Doktorarbeiten mit vielen> Abbildungen, Grafiken, Abkürzungen, ... sind da überhaupt kein Problem.
Ich habe mich lange Zeit mit LaTeX schwer getan. Wenn ich allerdings
eine richtig ordentliche Dokumentation erstellen will, dann benutze ich
das mittlerweile gern, weil man ein ordentliches in sich konsistentes
Ergebnis erhält.
sepp schrieb:> Wieviele Stunden musst du vim-Doku lesen um rauszufinden wie man das> macht. Um ein Problem zu lösen, das einmal im Leben vorkommt.
Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es
einigermaßen beherrscht?
Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um
statt in der Kreisklasse in der Verbandsliga zu spielen?
Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen,
wenn einem mal langweilig ist:
https://www.youtube.com/watch?v=KuLy5LzHEzU
(Kommentare dazu lesen, ist auch gar nicht so schlecht)
rbx schrieb:> Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es> einigermaßen beherrscht?
Hast du schon versucht, eine derart komplizierte Tätigkeit in einem
Alter zu erlernen, in dem du bereits lesen konntest? Vielleicht geht es
sogar leichter, wenn man es nicht kann. ;-)
rbx schrieb:> Wieviele Stunden muss man ein Tischtennisbuch lesen, um> statt in der Kreisklasse in der Verbandsliga zu spielen?
Gar keines, da muß man nur üben bis der Arzt kommt. Und ja ein bissel
Talent wird wohl auch dabei sein.
Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus
wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch
beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu
verändern.
Etwas vergleichbar mit dem Tastendruck R,
nachdem man den vi mit -b gestartet hat.
Ich konnte da in der Hilfe nichts finden…
rbx schrieb:> Wieviele Stunden muss man Bücher übers Schuhe zubinden lesen, bis man es> einigermaßen beherrscht?
gar keins
rbx schrieb:> Oder alternativ: Wieviele Stunden muss man ein Tischtennisbuch lesen, um> statt in der Kreisklasse in der Verbandsliga zu spielen?
vermutlich auch keines, man braucht nur viel Übung.
Aber du willst doch die Bedienung eines Editors hoffentlich nicht als
Selbstzweck sehen wie ein Sportler seine Sportart?
rbx schrieb:> Ansonsten kann man sich heutzutage auch ein paar nette Videos ansehen,> wenn einem mal langweilig ist:> https://www.youtube.com/watch?v=KuLy5LzHEzU
Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es
mitlerweile einiges.
3.14 schrieb:> Und wenn man Glück hat, findet man auch Videos in Deutsch. Da gibt es> mitlerweile einiges.
Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da
oben?
Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens
einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber
ganz schön ein.
Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv)
auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht
allzugroße Sorgen machen.
Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff
open:MINT) kann man doch noch verstehen oder?
Zeno schrieb:> Nano schrieb:>> Denn Notepad++ nutzt direkt>> die WinAPI und ist damit auch sehr schnell geladen.> Das war unter Windows auch lange Zeit mein Lieblingseditor. Mittlerweile> bevorzuge ich da aber PSPad. Bei diesem kann man links eine> Explorerleiste einblenden. Zudem kann man sich auch per SFTP mit einem> anderen Rechner verbinden und durch dessen Verzeichnisstruktur> navigieren.
Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7
auf 10) von PSPad zu Notepad++ gewechselt.
Der Grund war allerdings nur, weil ich Notepad++ mal ausprobieren wollte
und das geht am besten, in dem man ihn installiert und die anderen
Editoren nicht zur Verfügung hat. Also habe ich PSPad nicht installiert
und Notepad++ ist jetzt halt drauf.
Gefehlt hat bis jetzt nichts, anderseits mache ich meine Arbeitssachen
überwiegend nur noch unter Linux, weswegen ich unter Windows kaum dazu
komme, da einen Editor zu benötigen. Deswegen habe ich den da einfach
drauf gelassen.
Norbert schrieb:> Wie kann man eigentlich beim nano Editor in den ›Überschreiben‹ Modus> wechseln? Also anstelle von ›Einfügen‹. Finde ich immer sehr praktisch> beim Bearbeiten von binären Dateien ohne deren Größe oder Struktur zu> verändern.
Keine Ahnung, aber ich habe das auch nie gebraucht und unter DOS, wo man
das per EINF Taste einstellen konnte, hat mich so etwas immer gestört.
Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.
Das ist grob der 14-15 fache Speicherplatz im RAM.
Und der dreifache CPU Resourcen Verbrauch.
Macht nano da etwas ganz Besonderes?
Wie lautete die Eingangsfrage noch gleich…
(prx) A. K. schrieb:> Norbert schrieb:>> Macht nano da etwas ganz Besonderes?>> Er ist bloss neuer, von 1999 statt 1991, und konnte sich das leisten.
Stimmt. Neuer is' besser. Sieht man doch… ;-)
Norbert schrieb:> Wie lautete die Eingangsfrage noch gleich…
Die lautet:
Openbsd schrieb:> Arbeitet von euch noch jemand mit dem vim? [...]> Wenn nein, warum nicht?
Und die hat nano eigentlich gemäß der Fragestellung beantwortet, seitdem
sieht er sich aber starken Missionierungstendenzen ausgesetzt.
Und da er selber auch etwas schwierig ist, die Fanboys nicht ignorieren
kann sondern das letzte Wort haben muss sind wir nun wieder in einer
Diskussion angekommen die zusammen mit dem usenet eigentlich in der
Versenkung hätte verschwinden sollen.
Nano schrieb:> Ich bin bei einer Neuinstallation von Windows 10 (war ein Wechsel von 7> auf 10) von PSPad zu Notepad++ gewechselt.
Der Notepad++ ist schon klasse. Der bietet alles was man braucht. Gerade
wenn man an großen Projekten arbeitet mit vielen Dateien und
Verzeichnissen arbeitet hat das Teil schon seine Stärken, z.B. Suchen
und Ersetzen in allen göffneten Dateien oder auch im gesamten
Verzeichnis.
Auskommentieren von Zeilen oder ganzen Bereichen passend zum geöffneten
Dateityp funktioniert natürlich auch.
Also ich nehme das Teil immer noch sehr gerne. Da ich derzeit an meinem
Wetterserver und der zugehörigen Homepage arbeite kommt mir aber die
FTP-Funktionalität des PSPad sehr gelegen. Der bietet zwar nicht die
Vielfalt wie Notepad++, ist aber für meine aktuellen Arbeiten völlig
ausreichend.
Le X. schrieb:> Norbert schrieb:>> Wie lautete die Eingangsfrage noch gleich…> Die lautet:> Openbsd schrieb:>> Arbeitet von euch noch jemand mit dem vim? [...]>> Wenn nein, warum nicht?
Le.X: Warum lügst du so dreist?
Und ja, eine Auslassung wesentlicher Teile kommt einer Lüge gleich!
Hier die wahre Fragestellung:
> Arbeitet von euch noch jemand mit dem vi?> Wenn ja, warum? Was sind die> ultimativen Vorzuege dieses Editors?> Wenn nein, warum nicht?
Da nano nicht mit vim arbeitet sind die von mir im Zitat mit [...]
ersetzten Fragen nicht relevant, erst die letzte wieder.
Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den
Buckl runterrutschen, da musst dir 'nen andren suchen.
Le X. schrieb:> Da nano nicht mit vim arbeitet sind die vob mir mit [...]> ersetzten> Fragen nicht relevant, erst die letzte wieder.>> Aber lass stecken. Mit solchen Wortklaubereien kannst mir glei' den> Buckl runterrutschen, da musst dir 'nen andren suchen.
Ich würde die Wahrheit jetzt nicht als Wortklauberei bezeichnen.
Das mag für dich und deine ›gefühlte Wahrheit‹ natürlich durchaus so
sein. So lebt halt ein jeder in seiner Welt.
So grob kann man den Vi und auch Vim mit der guten Bedienung vom Emu
Emax2 vergleichen. Beim Emax2 wird man gewissermaßen mit leichter Gewalt
dazu gezwungen, gleich von Anfang an Multisamples zu erstellen.
Das hört sich furchtbar an, ist es aber nicht, weil man sonst Gefahr
läuft, zu einer Art Samplefragment-Messi zu verkommen, und das behindert
die Kreativität auch ganz schön, trotz der freien Zuordnung, die man
aber später noch ausrichten muss.
Beim Vi wie auch beim Vim wird man in ähnlicher Weise dazu gezwungen,
eine "alte" aber bewährte Tastaturbedienung zu lernen. Das ist dann aber
eher analog zum Minimoog. Und meinen konnte ich damals recht günstig
bekommen, weil viele Leute irrtümlich dachten, das wäre der letzte
Schrott von Gestern.
Wer den Minimoog kennt, der weiß auch, dass das Improvisieren mit dem
Ding einen Riesenspaß machen kann.
rbx schrieb:> Kannst du kein Englisch? Vermutlich auch darum der Argwohn gegen Unis da> oben?> Unabhängig von den Hochschulen, wenn man Englisch nicht wenigstens> einigermaßen lesen kann, schränkt das heutzutage die Internetsuche aber> ganz schön ein.> Außerdem geht heutzutage fast jeder zur Uni, da fällt man eher (positiv)> auf, wenn das mal nicht so ist. Also würde ich mir deswegen nicht> allzugroße Sorgen machen.>> Aber den Begriff "Open Mind" (und den nett abgeleiteten Begriff> open:MINT) kann man doch noch verstehen oder?
Sach mal was hast du denn geraucht?
Argwohn gegen Unis? Nur weil ich gesagt habe, dass nur dort vi und LaTeX
benutzt wird und eher nicht in der Industrie? Gehts noch? Und wo habe
ich geschrieben, dass ich kein Englisch kann? Und wenns so wäre, ginge
es dich auch nichts an. Und ja das Hörverstehen ist bei mir
verbesserungswürdig und mit Prosa von Shakespeare tue ich mich auch
etwas schwer. Wenn du unbedingt Streit suchst, bist du bei mir an der
falschen Adresse. Da mache ich nicht mit und antworte dir Streithahn
einfach nicht mehr. Hast wohl selber noch keine höhere Lehranstalt von
innen gesehen, was?
3.14 schrieb:> Sach mal was hast du denn geraucht?
Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich
geschmacksbefreit allerdings, da fragt man sich, ob das früher zur
Zichorienzeit (als Kaffeeersatz) auch schon so fade geschmeckt hatte.
Und wenn wir schon dabei sind. Ich stehe nicht sonderlich auf
Plattitüden, oder sich absichtlich sehr dumm stellen.
Wenn man Pflanzen, Kräuter oder Blumen bestimmen oder besser,
unterscheiden muss, hilft nicht immer ein Buch weiter, dafür aber die
Nase.
Auch dieses wurde uns abgewöhnt, obwohl es (das Erschnuppern) für die
Menschen früher überlebenswichtig war, und oft auch schwierige Dinge
ganz einfach macht.
rbx schrieb:> Geraucht eher nicht, aber dafür Carokaffee getrunken. Ziemlich> geschmacksbefreit allerdings,
Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt
nennt?
(prx) A. K. schrieb:> Was erwartest du von einem Produkt, dass sich Kaffeesurrogatextrakt> nennt?
Und dann auch noch von einem bestimmten Unternehmen..
Tatsächlich hatte ich nicht viel erwartet. Aber Reformhäuser sind bei
uns im Kreis alle weg, auch im größeren Bereich. Ich dachte schon daran,
Hoffnung in eine etwas höhere Qualität zu setzen. Bevor ich mein Glück
bei einer Apotheke versuche, könnte ich noch schauen, ob man bei uns in
einer Supermarktecke mit Allnatura-Produkten noch etwas anständige(er)s
erwischen kann.
Aber die Geruchswelt von damals wird schon noch eine andere gewesen
sein, teilweise wohl auch deswegen, weil die Leute auch oft hungern
mussten, und soviel Fleisch wie heutzutage auch nicht auf den Tisch kam.
Gibt es eigentlich in Wien in diesen Kaffeehäusern guten
Zichorienkaffee? Bzw. gibt es die Kaffeehäuser überhaupt noch? Die
kleine Kneipe gibt es bei uns schon lange nicht mehr.
Und wo früher unser recht großer Dorfsupermarkt war, ist jetzt (in den
alten Supermarkträumlichkeiten) ein großes Beerdigungsinstitut.
Walter K. schrieb:> Nano schrieb:>> …>> Zum Bearbeiten von Binärdateien verwende ich einen Hexeditor.>> LOL
Wieso LOL?
Das ist nunmal die Aufgabe eines Hexeditors, der ist für Binärdateien
da.
Ein normaler Editor muss nur Text können, denn er heißt nunmal
Texteditor und nicht Binäreditor.
Falls du das bspw. nicht weißt, aber ein UTF-8 Zeichen kann bis zu 4
Bytes lang sein. In der Textansicht im Editor steht da also nur 1
solches Zeichen, das intern aber 4 Bytes groß ist.
Im Hexeditor sieht man jedes der 4 Byte.
Manche Texteditoren erlauben es auch in den Hexeditormodus umzuschalten,
dann kannst du das auch auf Binärebene ändern, während die Daten dann in
Hexansicht und daneben in normaler Zeichenansicht angezeigt werden. Das
ist aber kein muss für einen Texteditor so etwas zu können.
Norbert schrieb:>
> Wenn ich die mit vi öffne, dann werden ca 350MiB Speicher benötigt:>
1
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+
2
> Command
3
> 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi
4
> XXX
vi oder vim?
350 MiB sind für vi ziemlich viel, wenn man bedenkt, dass er aus einer
Zeit stammt, als die Rechner weniger RAM hatten als die Disketten
Speicherplatz boten.
Da musste man also noch direkt auf Disketten operieren können, weil man
längere Textdateien gar nicht ins RAM bekam.
Hat sich das jetzt bei vi verschlechtert? Eine Rückentwicklung?
Nano wurde später entwickelt, da hatte man schon üppig RAM zur Verfügung
und dicke Bücher, wie bspw. die Bibel konnte man bereits komplett in das
RAM laden. Da war bereits das direkte Arbeiten auf dem Datenträger keine
Anforderung von Editoren mehr.
Nano schrieb:> vi oder vim?
vi ist bei debian ein symlink (über Umwege) auf vim. Also ja, es ist
natürlich vim dahinter.
Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend
nicht mehr unter den Fingerkuppen. Selbst in Debian Hamm (die Älteren
werden sich erinnern) war schon vim drin.
Also, hmm, vi? Könnte Sinix oder Xenix oder SCO gewesen sein. Ganz
sicher aber auf dem UNIX einer Perkin-Elmer.
> 350 MiB sind für vi ziemlich viel,
Ja, schon. Der Traditionelle hat sich immer nur ein Häppchen genommen.
Aber der Punkt ist ein anderer:
5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp
80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das
lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung
erklären. Oder einer massiv fehlerhaften Implementation. Der
Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300%
der Zeit braucht.
Norbert schrieb:> Aber der Punkt ist ein anderer:> 5100 MiB beim nano (1450% des von vi genutzten RAM) und das knapp> 80-fache der Dateigröße sind jedoch nicht nur ein paar Bytes mehr. Das> lässt sich eigentlich nur noch mit ziemlich schlampiger Programmierung> erklären. Oder einer massiv fehlerhaften Implementation. Der> Geschwindigkeit wegen kann es ja nicht sein wenn's dann auch noch 300%> der Zeit braucht.
Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der
Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch
auf eine 3,5 DD Diskette passen.
Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im
Arbeitsspeicher (Windows Taskmanager).
Das Installationsprogramm von gvim verbraucht auch nicht unbedingt viel
mehr Speicherplatz, so 10 MB. Vieviel Speicher der jetzt nach der
Installation belegt, oder wieviel Arbeitsspeicher im Betrieb, kann ich
nicht sagen, aber allzuviel mehr wird das auch nicht sein.
https://www.vim.org/download.php
Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich
bei der "Recherche" schon ein wenig schmunzeln:
https://superuser.com/questions/938093/nano-alternative-for-windows-powershellhttps://nano-editor.org/dist/win32-support/
Norbert schrieb:> Einen traditionellen vi hatte ich (glaube ich) in diesem Jahrtausend> nicht mehr unter den Fingerkuppen.
Die gibt's auch kaum noch, weil der vi-Sourcecode lange Zeit nicht als
Opensource verfügbar war. So haben die BSDs halt schon vor 30 Jahren auf
nvi gesetzt, der sich zwar vom feature set weitgehend am Original
orientiert (außer dass man im Insert-Mode mit den Cursortasten
navigieren kann ;-) aber eben trotzdem ein Rewrite ist.
rbx schrieb:> Vielleicht ist auch die Anzeige verbuggt, oder irgendetwas anderes. Der> Watcom-Vi belegt bei mir etwa 300kb (Windows-Explorer) und würde auch> auf eine 3,5 DD Diskette passen.> Im Betrieb verbraucht der in etwa das doppelte an Speicherplatz im> Arbeitsspeicher (Windows Taskmanager).
Die Anzeigen bezüglich der RAM-Belegung:
Da kann ich mit 100% Sicherheit einen Fehler ausschließen.
Sowohl ›top‹ als auch ›htop‹ als auch die graphische Systemüberwachung
sind sich da einig. Da gab's auch noch nie Probleme.
Vielleicht war ich aber auch etwas unklar:
Der nano belegt die zig-zig-zig-fache Menge an Speicher.
Der vi verhält sich hingegen tadellos.
Norbert schrieb:> Ich habe hier eine gerade mal 64MiB große Textdatei.> ...> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command> 9417 norbert 20 0 404M 352M 14316 S 0.0 1.5 0:02.65 vi XXX> ...> 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX
Das sieht schon heftig aus, allerdings kann ich das bei mir nicht ganz
nachvollziehen:
1
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2
8778 yalu 20 0 164M 98M 18648 S 0.0 1.7 0:00.23 vim big1
Die Zahlenwerte sowohl für RES als auch für TIME sind also deutlich
kleiner als bei dir. Der Speicherverbrauch hängt aber auch etwas vom
Inhalt der Datei ab.
Die Datei big1 enthält 1048576-mal die Zeile
Ich verwende vim ganz gerne. Allerdings brauche ich nur ein kleines
Subset der Features, das kann man in 15 Minuten lernen. Im Laufe der
Zeit habe ich immer mehr Kürzel vergessen...
Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features
nicht gut funktionieren, wie finden der Funktionsdefinition oder
debuggen. Auch gibt es keine einfache Projektverwaltung.
Und schlimmer: man kann mit keiner IDE mehr arbeiten, wenn man die vim
Kürzel erst mal gewohnt ist...
Der vim ist aber auch ein Code-Monster mit schlechter Doku und mehr
Sourcecode Zeilen als der Emacs und grauslicher Script Sprache. Dazu
Bloat ohne Ende, aber OK - er funktioniert und stürzt nicht ab, die
Windows Integration ist sehr bescheiden.
Norbert schrieb:> head -c64M /dev/zero | tr "\000" "\n" >XXX
Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :)
Nano scheint also in seiner internen Datenrepräsentation einen riesigen
zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte
bei Vim).
Norbert schrieb:> Der nano belegt die zig-zig-zig-fache Menge an Speicher.> Der vi verhält sich hingegen tadellos.
Nicht nur das: den Vi oder gvim oder neovim usw. gibt es auch für
Windows, reichlich problemlos.
Der Watcom-Compiler hatte bei dem Übersetzungsversuch der Nano-Quellen
trotz mehrerer Versuche und Ansätze mit zigfachen Fehlermeldungen
abgebrochen.
Da ist man wohl tatsächlich besser dran, wenn man erstmal ein minimales
Cygwin (s.o.) für nano nutzt.
(abgesehen davon, dass der VMware Player auch so ein tolles Programm
ist)
(Früher konnte man bei Cygwin eine Art Fullinstall machen, die maximale
Menge war 4 GB.
Aktuell gibt es bis zu 150 GB an Software, da muss man sich vor dem
Installieren dann wohl auf Empfehlungen verlassen. Früher hatte ich nur
den Compiler als Programm, das brauchte auch nicht viel Speicher, also
eher vergleichbar mit dem, was heute typischerweise mit MinGW-Setups
läuft.)
Yalu X. schrieb:> Norbert schrieb:>> head -c64M /dev/zero | tr "\000" "\n" >XXX>> Ah, ok, jetzt erhalte ich ähnliche Ergebnisse :)>> Nano scheint also in seiner internen Datenrepräsentation einen riesigen> zeilenbezogenen Overhead zu haben (ca. 79 Byte im Vergleich zu 4 Byte> bei Vim).
Und das da oben ist noch eine ›Spielzeugdatei‹
Hatte - blauäugig wie ich bin - mal eine unserer echten Messreihen mit
›nano‹ geöffnet. Die braucht normalerweise gerade mal 20 Sekunden zum
öffnen. (Für 180E6 Zeilen, ~4GB)
Konnte gerade noch schnell genug ein zweites Terminal aufmachen und bei
ca. 20GiB RAM Nutzung ein freundliches kill -9 an den ›nano‹ senden.
Noch bevor die wilde Swap-Orgie starten konnte.
Wäre aber sicherlich gut für eine autoexec.bat oder config.sys zu
gebrauchen… (Nee ich nehme das zurück, das war böse)
Stefan ⛄ F. schrieb:> Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir> im Büro> für Java EE Anwendungen.
Möchte jemand anderes AHA sagen, oder soll ich das machen?
rbx schrieb:> Der vi verhält sich hingegen tadellos.
Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den
Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.
Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM
für eine Bildschirm-Seite braucht...
udok schrieb:> Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den> Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.
müsste man man schauen, was neovim diesbezüglich macht. Beim Watcom-Vi
hatte ich eine ca 30 MB große Pdf Datei geladen - Speicherverbrauch des
ganzen lag bei 32 MB.
Wenn man allerdings eine Pdf im Reader läd, und dann auf den Taskmanager
schaut, dann grabscht sich dieser Reader eine ganze Menge Speicherplatz
selbst nach dem Beenden.
Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus
bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als
dieser grottige Dos-Editor Edlin.
Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf
die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe
übersehen müssen.
rbx schrieb:> Bei Nano ist der Bedarf wohl in etwa verdoppelt. Allerdings musste ich> bei der "Recherche" schon ein wenig schmunzeln:>> https://superuser.com/questions/938093/nano-alternative-for-windows-powershell
Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Ich selbst installiere immer Git for Windows, da ist er dann neben der
Bash und weiteren wichtigen Tools automatisch dabei und das wurde auch
in deinem Link vorgeschlagen.
https://gitforwindows.org/
Bei der Lösung über den Chocolatey package manager fehlte bei meiner
letzten Recherche vor ein paar Jahren über Chocolatey noch das Vertrauen
in die Pakete, weil es damals dort keinerlei Signierung gab. Keine
Ahnung ob das inzwischen besser gelöst ist.
>> Nochmal getestet, Werte bleiben etwa gleich.
Was du da produziert hast, ist vieles, aber keine Textdatei, wie du
anfangs behauptet hast.
Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles
modifiziert, was kein Teil einer Textdatei ist.
Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner.
Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine
Arbeit. Für Binärdateien nimm einen Hexeditor, wie ich es anfangs schon
sagte.
udok schrieb:> Fürs programmieren würde ich ihn nicht empfehlen, da wichtige Features> nicht gut funktionieren, wie finden der Funktionsdefinition oder> debuggen. Auch gibt es keine einfache Projektverwaltung.
Die Erfahrung habe ich auch gemacht, deswegen habe ich mich mit vim
damals nicht mehr weiter beschäftigt und vim nach ca. 1 Woche Testzeit
zu den Akten gelegt.
Und für Configs brauch ich vim nicht, die sind so klein, da komme ich
mit jedem Editor zurecht. Aber das sagte ich schon.
udok schrieb:> rbx schrieb:>> Der vi verhält sich hingegen tadellos.>> Der vim liegt da unter Windows im Mittelfeld. Ich hatte mal den> Speicher gemessen, da lag der vim bei ca. 4 Bytes pro Zeichen.>> Nix besonderes wenn man bedenkt, das ein Editor eigentlich nur den RAM> für eine Bildschirm-Seite braucht...
4 Byte pro Zeichen sprechen für eine interne Unicode UTF-32
Verarbeitung. Etwas anderes würde ich bei neuen Editoren nicht erwarten.
Früher wären es UTF-16, also 2 Byte pro Zeichen gewesen.
Was nano betrifft, hätte ich neben der ebenfalls UTF-32 Verarbeitung
noch folgende Vermutung:
Möglicherweise wird bei nano beim Laden eine Wörterbuchsuche mit
Zeilennummern angelegt, das würde dann die Suche beschleunigen, aber
auch die notwendige Datenmenge im RAM erhöhen. Also nichts
weltbewegendes.
rbx schrieb:> Der Watcom Vi hat noch andere Vorteile. Den kann man auch mit der Maus> bedienen, und der wäre früher auch sehr viel angenehmer gewesen, als> dieser grottige Dos-Editor Edlin.
EDLIN.COM wurde ab MS-DOS 5.0 ja durch EDIT.EXE ersetzt und DR DOS hatte
schon von Anfang an mit EDITOR.EXE einen besseren Editor als EDLIN.COM
im Programm.
> Hätten die Linux-Vis die Vorzüge vom Watcom-Vi, dann hätten viele auf> die Flucht zu Nano verzichten können, und in der Eile auch nicht Joe> übersehen müssen.
Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen
intuitiven Editoren auch bereits pico zur Verfügung.
Und pico hat meistens gegen joe gewonnen, so war es auch bei mir.
nano kam dann später und hat pico ersetzt.
Und nano hatte keine lizenzrechtlichen Fragen mehr und war kurze Zeit
später so beliebt, dass er in allen gängigen Distributionen
vorinstalliert wurde.
Yalu X. schrieb:> Nano schrieb:>> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du>> anfangs behauptet hast.> $ file XXX> XXX: ASCII text
Ich habe schon mal mit sort und uniq eine mehrere GB große Wörterliste
sortiert und auf einen Eintrag pro Wort begrenzt, so sollte es sein, mit
kleiner Datenmenge habe ich die Kommandos auch vorher entsprechend
getestet, aber das Ergebnis war etwas ganz anderes.
Entweder sort oder uniq haben sich herhaspelt, d.h. die Wörter kamen
immer noch doppelt vor, und deswegen glaube ich nicht, dass eine pipe
und tr die richtige Vorgehensweise ist um sehr große Binärdatei zu
bearbeiten.
Nano schrieb:> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du> anfangs behauptet hast.
Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht.
Gut, kann man ein bisschen als corner case ansehen.
Statistik nach dem Laden der Datei (Ubuntu):
1
VSZ RSS
2
vi: 350496 343320
3
nano: 5252636 5246748
4
Emacs (GUI): 790164 129796
5
Emacs (TUI): 289072 100728
Emacs ist vorsichtig und fragt lieber erstmal nach, ob er so eine große
Datei denn wirklich laden soll. ;-)
Aber da dir die Daten ja nicht gefallen haben, probieren wir es mit
einer Menge an 5stelligen Zufallszahlen:
1
$ jot -r 11500000 10000 99999 > XXX
2
$ wc XXX
3
11500000 11500000 69000000 XXX
Sind jetzt ein paar MB mehr als vorher, aber nur noch 11,5 Millionen
Zeilen.
1
VSZ RSS
2
vi: 129808 122972
3
nano: 908136 902160
4
Emacs (GUI): 792220 131716
5
Emacs (TUI): 290920 102700
Nano steht jetzt deutlich besser dar als im pathologischen Fall von nur
Newlines, aber es fällt immer noch auf, dass er praktisch fast den
gesamten allozierten VM einmal "anfasst", sodass er komplett auch als
resident set im Speicher benutzt wird. vi(m) macht das auch, aber auf
deutlich niedrigerem Niveau, bei Emacs ist eine große Differenz (viel
mehr VM angefordert als tatsächlich erstmal benutzt). vi(m) gewinnt
ebenfalls gegenüber dem pathologischen Fall, Emacs zeigt keine
nennenswerten Unterschiede.
[Edit: einige Aussagen korrigiert, die offensichtlich inkorrekt waren.]
Nano schrieb:> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du> anfangs behauptet hast.
Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte
bedarf.
> Ich würde mal ganz stark davon ausgehen, dass dein tr nicht alles> modifiziert, was kein Teil einer Textdatei ist.
Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten
prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile.
> Eine andere Erklärung wäre noch kaputtes RAM in deinem Rechner.
Du meine Güte… ehrlich jetzt?
> Gebe dem nano eine vernünftige Textdatei, dann macht er auch seine> Arbeit.
Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du
verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen
absondern.
Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen
Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich
völlig überfordern.
Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt
mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor
er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt).
Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für
Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro
Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen,
dann ist das kein Grund panisch zu reagieren. Das ist unser
Tagesstandard.
Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen
dauert länger. Einen Glitsch in den Messdaten beseitigen,
Fingerschnippen.
Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch.
Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei.
Vielleicht noch ein kleiner Tipp: Nicht immer den eigenen Horizont als
Maßstab für alles andere nehmen. Nur weil man selbst nur mit Dateien in
Spielzeuggröße zu tun hat, bedeutet das nicht automatisch das alle
anderen das auch tun.
Ich verweise nochmal auf die ursprüngliche Frage und die Antwort lautet:
Man nimmt den vi für Aufgaben denen kaum ein andere Editor gewachsen
ist.
Die bewältigt er mit Bravour.
Und darum wird er auch nicht aussterben!
Aus hoffentlich offensichtlichen Gründen kann ich hier keine Messdaten
zur Verfügung stellen. Ein Upload einer 3.8GB TEXTDATEI würde vermutlich
nicht gerne gesehen.
Aber bau dir ruhig selber eine, genau so ist das Format: VORSICHT 3.8GB
1
#!/usr/bin/python3
2
importsys
3
importrandom
4
N=4*3600*10000# Vier Stunden lang, 100µs pro Messung
Speichernutzung geht von ~7GB auf ~12GB
Ladezeit: knapp 18 Sekunden
die Eingabe von 100000000<Enter> springt zur 100 Millionsten Zeile in
einem Wimpernschlag.
Jörg W. schrieb:> Es ist eine 64 MiB große Textdatei, die nur aus Zeilenumbrüchen besteht.> Gut, kann man ein bisschen als corner case ansehen.
Könnte man einzeln betrachtet so sehen, aber es dient auch nur dazu zu
zeigen das nano enorme Probleme hat wenn es um richtige Arbeit geht.
Die Probleme sind selbstverständlich auch in anderen großen Textdateien
(mit mehr 0x20…0x7e) vorhanden.
Nano schrieb:> Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Die eigentlich einzig sinnvolle ist: Gar nicht.
Gilt allerdings für vi unter Windows genauso.
Oliver
Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich
viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut):
Für jede Textzeile wird eine solche Struktur angelegt:
1
typedefstructlinestruct{
2
// Größe in Byte
3
char*data;// 8
4
ssize_tlineno;// 8
5
structlinestruct*next;// 8
6
structlinestruct*prev;// 8
7
short*multidata;// 8
8
boolhas_anchor;// 4
9
}linestruct;
Gesamtgröße inkl. Padding: 48 Byte
Dazu kommt der Malloc-Chunk, auf den data zeigt. In 64-Bit-Linux ist die
minimale Chunk-Größe 32 Byte. Auch für Leerzeilen, die außer dem LF
keine weiteren Zeichen enthalten, werden diese 32 Byte benötigt.
Eine Leerzeile belegt also 48 + 32 =qa80 Byte. Entsprechend belegen die
64 Mi Zeilen der Datei XXX 80 · 64 MiB = 5120 MiB.
Norbert schrieb:> PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command> 9604 norbert 20 0 5127M 5123M 3112 S 0.0 21.3 0:07.30 nano XXX
Das passt also sehr gut. Die verbleibende 3 MiB in RES werden vom
Programmcode und weiteren Daten belegt.
Andere Editoren wie bspw. Vim und erst recht Emacs gehen weit weniger
verschwenderisch mit dem Speicher um, wie man an den Testergebnissen von
Norbert und Jörg sehen kann.
Yalu X. schrieb:> Hier ist die Erklärung,
Wow, du gibst dir ja richtig Mühe. Alle Achtung!
Mit Emacs hab ich das nie probiert.
Die beiden Parteien (vi, Emacs) haben sich ja früher immer gegenseitig
angefrozzelt. ;-)
Könnte mir aber gut vorstellen das der auch keine Probleme hätte. Gut
abgehangene Software eben (beide ;-) ).
rbx schrieb:> (Früher konnte man bei Cygwin
Heute kann man unter Windows das WSL2 installieren und damit direkt
originale Ubuntu-Pakete installieren und nutzen. Kein Bedarf mehr für
Cygwin und Co.
Stefan ⛄ F. schrieb:> Die IntelliJ IDEA Communiy edition ist kostenlos. Die nutzen wir im Büro> für Java EE Anwendungen.
Hm, merkwürdig... In anderen Sprachen kenne ich eine Menge Profis, die
"einfache" Editoren wie Atom, Sublime, vi(m), Emacs, UltraEdit,
Notepad++, Kate, Programmer's Notepad und Ähnliche benutzen. Nur unter
Java scheinen alle auf irgendeine IDE zu setzen, woran liegt das? Hat
dazu jemand -- im Gegensatz zu mir -- eine Idee?
Norbert schrieb:> Man muss halt Werkzeuge für Erwachsene nehmen
Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer.
Das wirkt nur überheblich.
Norbert schrieb:> Mit Emacs hab ich das nie probiert.
Er lädt das auch einigermaßen schnell (beide brauchen so um die 9
Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen.
Aber zum anderen Ende der Datei zu navigieren, dauert bei Emacs eine
gefühlte Ewigkeit, während es bei vi(m) ratz-batz geht.
Jörg W. schrieb:> Ohne solche blöden (sorry) Bemerkungen wären deine Beiträge angenehmer.> Das wirkt nur überheblich.
Ja, das war wohl die Reaktion auf das grausame und völlig faktenlose
Geschreibsel das sich zuvor in meine Netzhaut brannte. Normalerweise
versuche ich das zu vermeiden, aber manchmal geht's halt nicht…
Grundsätzlich gebe ich dir aber Recht.
Interessant: sogar die grafische Version des Emacs genehmigt sich in
beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.
Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen
des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal
sagen...
Jörg W. schrieb:> Er lädt das auch einigermaßen schnell (beide brauchen so um die 9> Sekunden hier), wobei beide stolze 4 GiB oder so an Speicher brauchen.
Ach, solange es ohne swappen in den Speicher passt, dafür isser ja da.
Ein T. schrieb:> Interessant: sogar die grafische Version des Emacs genehmigt sich in> beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal> sagen...
In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt
wohl auf ewig ein Rätsel.
Glücklicherweise installiert man ein Debian System meistens nur einmal
und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich.
Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere
ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-)
Ein T. schrieb:> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal> sagen...
Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die
meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei
bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal
"leichter verdaulich" als ein vi.
Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz
gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie
einen vi dann doch auf Dauer bevorzugen.
Norbert schrieb:> Nano schrieb:>> Was du da produziert hast, ist vieles, aber keine Textdatei, wie du>> anfangs behauptet hast.>> Das ist bodenloser Quatsch. Und zwar soviel das es keiner weiteren Worte> bedarf.
Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern
enthält ist KEINE Textdatei und da kannst du so viel auf dem Boden
herumstampfen wie du willst, daran wird sich nichts ändern.
Dein Beispiel mit lauter Newline Zeichen, also Zeichen, die lediglich
dem Editor sagen, dass eine neue Zeile beginnt ist kein Text und somit
ist das auch keine Textdatei.
Labere also jemanden anderen voll mit deinem Blödsinn!
> Du solltes viel weniger von ›irgendetwas ausgehen‹, dafür mehr Fakten> prüfen. Wie das geht steht oben. Mit der passenden Kommandozeile.
Und dann noch mehr Zeit mit deinem Blödsinn verschenken? Nein danke!
Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier
verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten und
wenn dein \000 Code nicht durch ein Newline ersetzt wird, dann hast du
am Ende eine ziemlich miese Eingabe in den Editor, insbesondere die
Abwesenheit von Text.
> Nein, macht er eben nicht wenn sie sehr groß sind. Auch das könntest du> verifizieren wenn du wolltest. Und nicht einfach nur unhaltbare Thesen> absondern.
Das hat Yalu X. hier schon getan:
Beitrag "Re: Vi Editor ausgestorben?"
Und da macht nano alles im üblichen Rahmen.
Auf UTF-32 und ein Wörterbuchdictionary zwecks schnellerer Suche habe
ich bereits verwiesen und ja, so etwas darf ein Editor machen ohne das
man ihm das negativ ankreiden darf, wie du es hier machst.
> Ich hatte bereits erwähnt das ich hier regelmäßig mit SEHR großen> Textdateien hantiere die dein Vorstellungsvermögen ganz offensichtlich> völlig überfordern.
Eine Datei aus Newlinezeichen ist keine Textdatei, siehe oben.
Und wenn du solche große Dateien hast und sie mit einem Texteditor
anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine
weitere Datenverarbeitung aufbereitest. Die Bearbeitung von GB Weise
Daten gehört nämlich ganz gewiss nicht in das Aufgabenspekturms eines
Texteditors, der zum Bearbeiten von Configdateien,
Programmiersprachencode, Skriptcode oder HMTL Text da ist.
> Der ›vi(m)‹ arbeitet mit denen völlig ohne zu murren, der ›nano‹ kotzt> mir den Arbeitspeicher so dermaßen voll das man ihn killen muss (bevor> er sich vermutlich selbst vor lauter Verzweiflung das Leben nimmt).
Dann beschwer dich bei den Entwicklern von nano was denen einfällt, den
nano zum Bearbeiten von Configdateien und Programmiersprachencode zu
entwickeln und deinen Anwendungsfall aus lauter Newlinezeichen zu
vergessen.
Hörst du dir eigentlich mal selbst beim Reden zu?
> Es ist nun einmal so, es gibt erwachsene Menschen, die Arbeit für> Erwachsene machen müssen. Und wenn unsere Mess-Systeme mehrmals pro> Woche 150 Millionen Zeilen (oftmals sogar mehr) mit Messdaten erzeugen,> dann ist das kein Grund panisch zu reagieren. Das ist unser> Tagesstandard.
Dann schreibt man dafür aber auch ein entsprechendes Programm, dass die
Daten entsprechend aufbereitet und verarbeitet und frickelt darin nicht
händisch mit einem Texteditor herum der nie für solche Datenmengen
entwickelt wurde.
Und dann noch etwas, wenn ich so große Datenmengen zu verarbeiten hätte,
dann würde ich mir an deiner Stelle mal Gedanken über Binärdateien
machen. Die können Computer nämlich weitaus besser verarbeiten und ja,
für die nimmst du dann das entsprechend dafür geschrieben Programm zum
aufbereiten, was du aber ohnehin brauchst, siehe oben.
> Im vi mal eben schnell zu Zeile 145*10⁶ springen, nun, Fingerschnippen> dauert länger. Einen Glitsch in den Messdaten beseitigen,> Fingerschnippen.
Ein Mensch der Endanwender ist und in Messdaten gucken will, möchte in
der Regel einen Messzeitpunkt oder Messzeitbereich angeben, da springt
er ganz gewiss nicht in Zeilen herum, sondern erwartet ein Programm bzw.
eine Oberfläche, in das er einen Zeitpunkt oder Zeitpunktbereich
eingeben kann und dann bereitet ihm eine entsprechend programmiertes
Programm das auf und zeigt es auf einer Oberfläche an und gibt die Daten
da aus. Nix da mit Zeilennummer eingeben. Verlange doch gleich, dass er
mit dem Debugger Addresszeilen im RAM eingeben soll um sein Messdaten zu
finden.
Und auf so viel Gestümper bist du auch noch stolz und schwärmst darüber,
dass vim damit klar kommt? Lachhaft!
> Man muss halt Werkzeuge für Erwachsene nehmen. Dann geht das auch.> Man geht auch nicht mit 'nem Pappschwert zu einer Schießerei.
Dann würdest du das umsetzen, was ich hier dir gerade geschrieben habe
und nicht vom Kunden erwarten, dass er mit VIM in deinen Messdaten
herumwühlen soll.
> und sieh' selbst was nano alles nicht kann und was ein richtiger Editor> problemlos kann.
Nano ist ein richtiger Editor. Er ist zum Bearbeiten von Textdateien,
Skripten, Programmcode und Konfigurationsdateien da und das kann er.
Yalu X. schrieb:> Hier ist die Erklärung, warum Nano für Norberts XXX-Datei so unglaublich> viel Speicher belegt (ich habe im Quellcode von Nano nachgeschaut):>> Für jede Textzeile wird eine solche Struktur angelegt:>>
1
>typedefstructlinestruct{
2
>// Größe in Byte
3
>char*data;// 8
4
>ssize_tlineno;// 8
5
>structlinestruct*next;// 8
6
>structlinestruct*prev;// 8
7
>short*multidata;// 8
8
>boolhas_anchor;// 4
9
>}linestruct;
10
>
>> Gesamtgröße inkl. Padding: 48 Byte
Danke und so etwas darf ein Texteditor, der zum Editieren von
Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,
auch.
Also kein Fehler des Programms.
Wenn Norbert anderes erwartet, dann ist das Problem vor dem Bildschirm.
Übrigens für die nicht Programmierer hier.
So ein struct das als Liste benutzt wird beschleunigt das Tauschen,
Einfügen und Entfernen von Zeilen erheblich, also eine Hauptaufgabe von
Editoren und da es algorithmisch eine Liste mit Zeiger zum vorherigem
und nächstem Listenelement ist, darf diese Liste beliebig lange werden,
solange der Rechner genug RAM an.
Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,
sondern er seinem Rechner zu wenig RAM verpasst hat.
Und ja, wenn man andere Anforderungen hat, dann kann man als Entwickler
einer Anwendung die Daten speichertechnisch auch anders organisieren,
z.B. die Zeilen zu Blöcken zusammenfassen und mit Blöcken arbeiten, das
bedeutet dann beim Entfernen und Einfügen von Zeilen dann aber erheblich
mehr Aufwand und reorganisation der Daten.
Nano schrieb:> Danke und so etwas darf ein Texteditor, der zum Editieren von> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,> auch.
Ist er denn als solcher irgendwo deklariert?
1
DESCRIPTION
2
nano is a small and friendly editor. …
Das ist das einzige Auftreten des Worts "small" in der ganzen man page.
Also es steht zumindest nicht da, dass er nur für "small files" da sei …
> Also kein Fehler des Programms.
Aber zumindest ungeschickt programmiert.
Nano schrieb:> Und wenn du solche große Dateien hast und sie mit einem Texteditor> anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine> weitere Datenverarbeitung aufbereitest.
Wer legt das fest? Du?
In aller Regel muss man in der Praxis einfach mal mit dem leben, was
einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor.
Nano schrieb:> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,> sondern er seinem Rechner zu wenig RAM verpasst hat.
Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so
einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch
dem Nano zur Verfügung steht.
Norbert schrieb:> Glücklicherweise installiert man ein Debian System meistens nur einmal> und pflegt's in den folgenden Jahren(Jahrzehnten) nur noch gelegentlich.
So ist das mit einem vi(m) oder Emacs ja auch: die Konfigurationsdatei
meines Emacs ist zum größten Teil schon über zwanzig Jahre alt, in den
letzten Jahren sind da nur ein paar ELPA-Pakete für Dockerfiles und
Kubernetes-Deployments hinzu gekommen. Das ist auch so eine schöne
Eigenschaft von alter, gut abgehangener Software -- wenn ich sehe, wie
viel Aufwand die Kollegen bisweilen betreiben müssen, um ihre IDEs
wieder lauffähig zu machen, wenn sie die aktualisiert haben oder auf
einen neuen Computer gewechselt sind, finde ich das schon ein bisschen
erschreckend.
> Ist so ein bisschen wie ein Bonsai. Ab und an mit einer winzigen Schere> ein kleiner Schnipp, dann ein halbes Jahr ansehen und genießen. ;-)
;-)
Nano schrieb leider schon wieder im Beitrag #7117082:
> eine Menge Gequirltes…
Und er erklärt schon wieder was andere machen sei falsch. Ohne auch nur
den geringsten Schimmer einer Ahnung zu haben…
Jörg W. schrieb:> Ohne …
Tja Jörg, schau es dir an und erkläre wie man mit Menschen umgehen soll
die sich ihre eigene Realität schaffen. ;-)
Ignorieren? Ja, das ist ein Plan!
Norbert schrieb:> Ein T. schrieb:>> Interessant: sogar die grafische Version des Emacs genehmigt sich in>> beiden Fällen weniger Arbeitsspeicher als der rein textbasierte nano.>> Das läßt die schon oben von mir für irrsinnig erklärten Entscheidungen>> des Debian-Projekts noch viel irrsinniger aussehen, würde ich mal>> sagen...>> In der Tat. Was die Jungs (und Mädels) sich dabei gedacht haben bleibt> wohl auf ewig ein Rätsel.
Für jemand der programmieren kann und Informatikvorlesungen,
insbesondere die Fächer Algorithmen und Datenstrukturen besucht hat ist
das Verwalten von Daten als Liste kein Rätsel, sondern je nach
Aufgabenstellung eine sinnvolle Lösung der Aufgabenstellung.
In deinem Fall tippe ich also mal auf Umschuler, der in das
Programmieren von Python so nebenbei reingerutscht ist.
Kein Wunder, dass du Gigabyteweise Messdaten als Textdaten ablegen
willst, anstatt dir Gedanken über ein effizientes Binärformat zu machen.
Und ja, wenn man das nicht kann, dann ist es natürlich verständlich,
dass man seine Rettung in vim sucht.
Jörg W. schrieb:> Naja, "irrsinnig" sind sie nicht. Wenn du davon ausgehst, dass die> meisten Leute tatsächlich auf der Kommandozeile nur mal 'ne Config-Datei> bearbeiten oder sowas, dann ist der Nano auf jeden Fall erstmal> "leichter verdaulich" als ein vi.
Keine Frage, der nano ist "zugänglicher" für Einsteiger. Das erklärt
aber nicht, warum man den guten alten vim eines Teils seiner gewohnten
Funktionalität berauben mußte und dies nicht einmal deutlich kenntlich
gemacht hat. Das verwirrt dann die erfahrenen vim-Nutzer, die sich
natürlich darauf verlassen, daß dieser Editor auch unter Debian
funktioniert wie gewohnt. Ähnliches gilt für die Nummer mit der dash. Da
wird der Wechsel auf Debian für Einsteiger erleichtert und für erfahrene
Nutzer erschwert, und das bei einer Distribution, die sich laut Aussagen
von Mitgliedern dieses Projekts vornehmlich an erfahrene Benutzer
richtet. Äh?
> Das Beispiel beantwortet aber die initiale Frage des Threads dafür ganz> gut, warum es halt nach wie vor ausreichend Leute gibt, die sowas wie> einen vi dann doch auf Dauer bevorzugen.
Definitiv, ja.
Leute, bitte tauscht eure Kindergarten-Anschuldigungen ("Umschuler"
(sic), "Werkzeuge für Erwachsene", "Gestümper") künftig per Email aus.
Das Forum braucht sowas nicht.
Ein T. schrieb:> Das erklärt aber nicht, warum man den guten alten vim eines Teils seiner> gewohnten Funktionalität berauben mußte und dies nicht einmal deutlich> kenntlich gemacht hat.
Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn
auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist
es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht
erwarten sollte, dass sie eine Bash ist.)
Nano schrieb:> Danke und so etwas darf ein Texteditor, der zum Editieren von> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,> auch.>> Also kein Fehler des Programms.
Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler.
Nano schrieb:> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,> sondern er seinem Rechner zu wenig RAM verpasst hat.
Das sagt Microsoft bei jeder neuen Windows-Version auch ;-)
Yalu X. schrieb:> Nano schrieb:>> sondern er seinem Rechner zu wenig RAM verpasst hat.>> Das sagt Microsoft bei jeder neuen Windows-Version auch ;-)
Und diverse Dealer voin Placebo und sonstiger Betrugssoftware wie
seineszeiten "SoftRAM"
"Trotzdem ist der SoftRAM-Treiber mit 54 724 Bytes viel größer als das
Original DynaPage.VxD. Beim näheren Anschauen trauten wir unseren Augen
kaum: Er enthält 41 820 Nullen! Nur rund 12,6 KByte werden überhaupt
genutzt, das Original belegt dagegen rund 8 KByte." aus
https://www.heise.de/ct/artikel/Placebo-forte-284374.html
Nano schrieb:> Eine Textdatei, die keinen einzigen Buchstaben, ja nicht einmal Ziffern> enthält ist KEINE Textdatei
Also bist Du jetzt hier der Chef und bestimmst über "richtige"
Dateitypen und -Inhalte, und die Aufgaben, die andere mit ihren
Werkzeugen bearbeiten dürfen?
> Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier> verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten
Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei
mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,
zuverlässig, performant, stabil und absolut reproduzierbar
funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei
Dir angeblich Probleme gemacht haben sollen -- obwohl Dein
Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler
gemacht hast.
Jörg W. schrieb:> Nano schrieb:>> Also kein Fehler des Programms.>> Aber zumindest ungeschickt programmiert.
Wenn man normale Datenmengen <= 1 MiB erwartet und die Hauptaufgabe das
Einfügen, Entfernen, Tauschen und Hinzufügen von Zeilen ist, dann ist
eine verkettete Liste mit Listenattributen für ein vorheriges und
nächstes Listenelement als Datenstruktur völlig ausreichend und
ungeschickt programmiert kann man hier auch nicht sagen, weil es für
kleine Datenmengen sogar die bessere, da einfacher zu handhabende,
Datenstruktur ist und große Messdatenreihen ganz gewiss nicht eine der
Anforderungen war, als der Editor von den Programmierern programmiert
wurde.
Würdest du dagegen die Zeilen zu bspw. Zeilenblöcken verarbeiten, die
insgesamt bspw. 64 KiB fassen können, dann müsstest du beim Einfügen in
der Mitte von so einem vollen Block eine neuen Block, der dann gleich 64
LIb belegt anlegen und im Worst Case Fall, falls du das dann nicht noch
komplizierter verwaltest, alle Zeilen, die ab der Hälfte des Blocks
folgen nach unten schieben, so dass die unterste Zeile dann im nächsten
Block landet.
Für lahme Rechner ist das ein erheblicher Aufwand. In nano müssten
stattdessen dazu nur zwei Adresszeiger vertauscht werden, fertig.
Die Struct Liste ist somit sehr effizient, wesentlich effizienter als so
eine Blockdatenstruktur. Und ja, natürlich braucht man für die extra
Zeiger dann mehr Platz. Kein Vorteil ist umsonst.
Wenn Norbert hier dann sagt, dass nano nicht gescheit programmiert wäre
und Spielzeug sei, dann bedeutet das nichts anderes, als das er keine
Ahnung von Datenstrukturen hat.
> Nano schrieb:>> Und wenn du solche große Dateien hast und sie mit einem Texteditor>> anfasst, dann bedeutet das, dass du sie nicht entsprechend für eine>> weitere Datenverarbeitung aufbereitest.>> Wer legt das fest? Du?
Das man sich über eine sinnvolle Datenstruktur bei gegebener
Aufgabenstellung Gedanken machen sollte, lernt man im Info Studium.
> In aller Regel muss man in der Praxis einfach mal mit dem leben, was> einem andere vorsetzen. Große Datenmüllhaufen kommen da schon mal vor.
Das ist leider wahr. All zu oft wird dann von den falschen Leuten ohne
entsprechende Qualifikation eine Simple Quick & Dirty, aber Hauptsache
billig Lösung hingeschludert und das ist dann das Ergebnis, was man hier
bei Norbert sehen kann.
> Nano schrieb:>> Im Fall von Norbert bedeutet das also, dass nicht nano das Problem ist,>> sondern er seinem Rechner zu wenig RAM verpasst hat.>> Das wird dadurch widerlegt, dass andere Editoren zumindest besser mit so> einem Datenmüllhaufen zurecht kommen, bei gleichem RAM-Ausbau, der auch> dem Nano zur Verfügung steht.
Die Liste kann prinzipiell beliebig lang anwachsen, es braucht also nur
mehr RAM.
Das Einlesen und Anlegen der Datenstruktur kostet natürlich anfangst
etwas mehr Zeit, aber wenn sie dann im RAM liegt, dann geht das Einfügen
oder Löschen von neuen Zeilen sehr effizient.
Lass mal 10000000 neue Zeilen in so eine 64 MiB Datei automatisiert von
nano und dann einmal von vim auf einem Rechner ohne Cache einfügen. Ich
würde dann mal stark schätzen, dass nano deutlich schneller fertig sein
wird.
Jörg W. schrieb:> Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn> auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist> es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht> erwarten sollte, dass sie eine Bash ist.)
Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens
20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.
Nano schrieb:> Ich würde dann mal stark schätzen, dass nano deutlich schneller fertig> sein wird.
Ich denke, einen Kasten Bier solltest du darauf lieber nicht verwetten.
;-)
Nanolator schrieb:> Nano schrieb:>> Danke und so etwas darf ein Texteditor, der zum Editieren von>> Configdateien, Skriptcode und eventuell noch Programmcode usw. da ist,>> auch.>>>> Also kein Fehler des Programms.>> Doch, unbegründete Verschwendung ist ein (Architektur-) Fehler.
Listenstrukturen sind beim Einfügen (insbesondere überall da, wo nicht
das Datenende ist) und Löschen besonders effizient und daher sinnvoll.
Daher ist das definitiv keine Verschwendung und schon gar nicht ist sie
unbegründet.
Siehe dazu nochmal mein vorheriges Kommentar.
Jörg W. schrieb:> Naja, wenn man ihn nur als "vi" installiert, geht das an, dass man ihn> auf den Feature set eines vi einkürzt. Wenn er auch auf "vim" hört, ist> es allerdings Mist. (Ist genauso, wie man von einer /bin/sh nicht> erwarten sollte, dass sie eine Bash ist.)
Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch
bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt
das Folgende aus:
Ein T. schrieb:> Nano schrieb:>> Zumal ich dir bereits gesagt habe, dass die CLI Tools sich hier>> verhaspeln können, weil sie das nunmal in meinem Fall schonmal taten>> Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei> mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,> zuverlässig, performant, stabil und absolut reproduzierbar> funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei> Dir angeblich Probleme gemacht haben sollen -- obwohl Dein> Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler> gemacht hast.
Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es
memtest86+?) überprüft.
Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch
die doppelten Einträge alle entfernen willst und das ganze noch durch
eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und
die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche
Datenmengen nie erwartet wurden.
Um herauszufinden, was da genau das Problem war, müsste man sich
natürlich den Code von sort und uniq, sowie der Shell ansehen. Ich habe
mir dann was eigenes programmiert und mir so anders geholfen um eine
richtige sortierte Liste mit einzigartigen Einträgen zu erhalten.
Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen
und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen
und das ganze dann wieder zu einer großen mehrere GB großen Datei
zusammenfügen und dann anschließend sort und uniq darauf loslassen.
Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein,
wenn sort und uniq alles richtig machen.
Jörg W. schrieb:> Hmm, das ist dann schon bissel irreführend.
Der relevante Hinweis ist auch leicht zu übersehen:
Ein T. schrieb:> ~ Running in Vi compatible mode
Norbert schrieb:> Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens> 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.
Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität
gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche
Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre
gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen,
daß die meisten funktionieren und manche wieder nicht. Ich kann mir nur
wenige bessere Möglichkeiten vorstellen, um Verwirrung zu stiften.
Nano schrieb:> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch> die doppelten Einträge alle entfernen willst und das ganze noch durch> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche> Datenmengen nie erwartet wurden.
Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden
die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas
falsch gemacht hast.
Also was vim.tiny betrifft.
Ja, da stimme ich zu. Da hätte man bei Programmstart schon als Titel
angeben können, dass es sich hier um vim.tiny handelt und nicht um VIM
- Vi IMproved , wie es bei vim.tiny ebenfalls im Titel steht.
Wer will, der kann ja mal einen Bugreport an das Debianprojekt
schreiben.
https://www.debian.org/Bugs/Reporting
Der einzige Unterschied, der am Splashscreen erkennbar ist, ist
lediglich, dass die Vollversion von vim einen deutschen Text hat, sofern
das System auf DE eingestellt ist, während die tiny Version englisch
bleibt.
nano,
ich finde du hast die Eingangsfrage, ob und wieso du nicht vim nutzt gut
und (für dich) richtig beantwortet.
Auf der Konsole, zum Editieren von Config-Files, reicht dir der nano und
für größeres Zeugs hast du deine IDE.
Soweit OK.
Jetzt lockst du natürlich die übliche Meute an die dir zeigen will dass
ihr Spielzeug viel toller ist (mir unverständlich was diesen Reflex
auslöst).
Und dein Problem dabei: die haben recht. Objektiv betrachtet kann der
vim mehr als der nano, und wie man sieht sogar mit geringerem
Ressourceneinsatz.
Dein Fehler ist, dich aufgrund der Schilderung von Usecases, die für
dich ja eh nicht relevant sind, zu einer Diskussion hinreißen zu lassen.
Du musst keine Binärdateien ändern.
Du musst keine 4Gb++ großen Textdateien ändern.
Fancy find&replace-Orgien brauchst du auch nicht bzw. falls doch kriegst
du sie anders abgebildet.
Dann sag das doch einfach. Sag dass dein Anspruch an deinen CLI-Editor
ist, Config-Dateien zu bearbeiten, und fertig.
Das Problem ist, du versuchst diese Beispiele zu kontern, und das kann
nur daneben gehen.
Denn jetzt hast du nicht mehr die Frage "Nutzt du vim? [...] Wieso
nicht?" sondern du hast die Diskussion "nano vs. vim" an der Backe und
da siehst du kein Land.
Ich stelle fest, du blamierst dich hier - ohne Not - bis auf die Knochen
und die streitlustigen Subjekte dürfen heute mit der grimmigen
Befriedigung ins Bett gehen, jemanden im Netz mal so richtig verdroschen
zu haben.
Mombert H. schrieb:> Nano schrieb:>> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch>> die doppelten Einträge alle entfernen willst und das ganze noch durch>> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und>> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche>> Datenmengen nie erwartet wurden.>> Bei dem was du hier so in den letzten Tagen von dir gegeben hast, werden> die meisten Leute wahrscheinlich erstmal davon ausgehen, dass du etwas> falsch gemacht hast.
Du darfst natürlich gerne glauben, dass lang bewährte Software keine
Bugs hat.
Beim Finden der Heartbleed Lücke hat das allerdings ein paar Jahre
gedauert, insofern kann das halt doch vorkommen.
Ein T. schrieb:> Norbert schrieb:>> Letzten Endes ist das ja auch kein Thema das sich nicht in schlimmstens>> 20 Sekunden beheben lässt. Und danach hat man 20 Jahre Ruhe.>> Das ist nicht mein Punkt. Mein Punkt ist, daß die Kompatibilität> gebrochen wird, für so ziemlich keinen Gewinn und ohne, daß es deutliche> Hinweise darauf gibt. Erfahrene vim-User versuchen dann natürlich, ihre> gewohnten Kommandos zu benutzen, nur um dann plötzlich festzustellen,> daß die meisten funktionieren und manche wieder nicht.
Ja, in der Tat.
Mir fiel das immer unangenehm auf wenn ich meine .vimrc auf ein anderes
System transferiert und dann den vi (nicht vim) gestartet hatte.
Error detected while processing .vimrc:
E319: Sorry, the command is not available in this version:
> Ich kann mir nur wenige bessere Möglichkeiten vorstellen,> um Verwirrung zu stiften.
Ach, da geht noch was… ;-)
Nano schrieb:> Du darfst natürlich gerne glauben, dass lang bewährte Software keine> Bugs hat.
Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software
sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine
Folge von fehlerhafter Anwendung waren.
Nano schrieb:> Ein T. schrieb:>> Ich finde das schon ein bisschen merkwürdig, daß diese CLI-Werkzeuge bei>> mir und vielen anderen Benutzern seit Jahrzehnten fehlerfrei,>> zuverlässig, performant, stabil und absolut reproduzierbar>> funktionieren, auch mit sehr großen Datenmengen, aber ausgerechnet bei>> Dir angeblich Probleme gemacht haben sollen -- obwohl Dein>> Arbeitsspeicher gar nicht kaputt ist und Du noch nie einen Fehler>> gemacht hast.>> Das war nun einmal so. Und mein RAM habe ich mit memtest86 (oder war es> memtest86+?) überprüft.
Hm.
> Wenn du mehrere GB an Datenmengen zuerst sortieren musst und dann noch> die doppelten Einträge alle entfernen willst und das ganze noch durch> eine Pipe schiebst, dann kann das schon sein, dass die CLI Werkzeuge und> die Pipe hier dann nicht mehr das machen, was sie sollen, weil solche> Datenmengen nie erwartet wurden.
Merkwürdig, solche Dinge mache ich seit vielen Jahren sehr regelmäßig
und kann mich nicht daran erinnern, jemals ein Problem dabei gehabt zu
haben. Übrigens benutze ich UNIX-Pipes auch oft mit Binärdaten, ohne daß
es Probleme gäbe -- einer meiner häufig genutzten Befehle ist es, die
Ausgabe von tar(1) auf pigz(1) zu pipen, denn parallel komprimieren geht
natürlich viel schneller.
> Aber wenn du willst, dann kannst du ja mal eine Wörterbuchliste nehmen> und die ein paar mal kopieren, dann jede Einzelliste gründlich mischen> und das ganze dann wieder zu einer großen mehrere GB großen Datei> zusammenfügen und dann anschließend sort und uniq darauf loslassen.> Am Ende müsste das Ergebnis dann mit der ersten Liste identisch sein,> wenn sort und uniq alles richtig machen.
Ich habe keinerlei Zweifel daran, daß das völlig problemlos
funktionieren wird, wenn ich das mache, schließlich hat das ja auch in
den letzten Jahren auch immer absolut problemlos funktioniert -- auch
mit Dateien von mehreren Terabyte Größe, aber dann natürlich auf unseren
fetten Eisen. Mittlerweile benutze ich für sowas nur deshalb unseren
Spark-Cluster, weil das parallelisiert natürlich viel schneller geht.
Aber mit kleinen Dateien von ein paar Gigabyte geht das natürlich auch
lokal. Ich frage morgen aber mal meine Kollegen, ob denen etwas
aufgefallen ist.
Ist schon ziemlich verwirrend, zumindest bei Linux Mint (und
wahrscheinlich auch noch bei vielen anderen, die von Debian abstammen)
Ruft man vim auf, so wird nichts gefunden.
Ruft man vi auf, so meldet sich vim, obwohl es sich in Wirklichkeit um
vim.tiny handelt.
Will man vim benutzen, muss man es extra installieren.
Das muss man auch erst mal verstehen.
Norbert schrieb:> Ein T. schrieb:>> Ich kann mir nur wenige bessere Möglichkeiten vorstellen,>> um Verwirrung zu stiften.>> Ach, da geht noch was… ;-)
Bitte weck' jetzt keine schlafenden Geister den Debian-Leuten, ja? ;-)
Nano schrieb:> Es gibt mehrere Möglichkeiten nano unter Windows zu installieren.
Eigentlich nur sinnvoll als Teil eines anderen Softwarepaketes.
Nano schrieb:> Joe wurde nicht übersehen, damals stand von den bedienungsfreundlichen> intuitiven Editoren auch bereits pico zur Verfügung.> Und pico hat meistens gegen joe gewonnen, so war es auch bei mir.
Es hat sich in der Zwischenzeit einiges getan..aber als eigenständiges
Konsoleprogramm habe ich joe und seine Zwillingsbrüder noch nicht zum
laufen bekommen. Entweder funktioniert der Download nicht, oder aber
muss sich nochmal die Konfigurierhinweise genauer ansehen. Also Nix Plug
and Play.
Etwas Nano-Soziologie..:
https://news.ycombinator.com/item?id=11953229
( die Frage lautet: don't want to sound nasty , but is anyone there
using nano really ? i know it come by default in some distros but that's
about it really. )
Die Antworten sind recht lesenswert.
Ein T. schrieb:> Heute kann man unter Windows das WSL2 installieren
Noch einer, der noch Bedarf nach einem Aha hat?
Ein T. schrieb:> Kein Bedarf mehr für> Cygwin und Co.
So sehe ich das nicht. WSL ist eine Alternative neben anderen, teilweise
auch viel besser zugeschnittenen Angeboten. Grundsätzlich aber keine
schlechte.
Mein Problem ist z.B. ich habe gar kein Windows 10 oder Windows 11. Und
ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht
vernüftig auf Linux spielen kann.
(Und Dualboot brauche ich auch nicht)
Hier noch ein Link auf die Suche in etwa "große Dateien editieren"
https://askubuntu.com/questions/28847/text-editor-to-edit-large-4-3-gb-plain-text-file
rbx schrieb:> Und> ja, ich finde das sch.. dass ich Baldurs Gate, d2r oder Horizon nicht> vernüftig auf Linux spielen kann.
Zumindest dafür gibts Abhilfe ;-)
https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition
Läuft bei mir unter Arch Linux nativ und problemlos.
(Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat
minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag
für Puristen evtl. nicht duldsam sein)
Mombert H. schrieb:> Nano schrieb:>> Du darfst natürlich gerne glauben, dass lang bewährte Software keine>> Bugs hat.>> Im Gegenteil, ich bin mir sehr sicher, dass da Bugs in der Software> sind. Ich halte es aber für wahrscheinlicher, dass deine Probleme eine> Folge von fehlerhafter Anwendung waren.
Du liest einfach nicht, was ich oben geschrieben habe.
Ich erwähnte, dass ich damals den CLI Befehl mit sort und uniq mit
kleiner Datenmenge auf Funktionsrichtigkeit überprüft habe.
D.h. der CLI Befehl und die angegebenen Parameter waren korrekt und das
Ergebnis richtig.
Eine fehlerhafte Anwendung der CLI Tools würde bedeuten, dass das hier
hätte spätestens auffallen müssen. Zumal du dich auch fragen solltest,
wie viel man überhaupt bei sort und uniq bei der Parameterangabe falsch
machen kann und ob dann überhaupt noch die Wahrscheinlichkeit einer
fehlerhaften Anwendung durch den Nutzer ausreichend groß ist.
Aber wie dem auch sei, glaub halt was du willst. Ich weiß, was ich
beobachten konnte und die Wörter waren am Ende nach sort und uniq eben
nicht einzigartig, sondern kamen mehrmals in der Datei vor, wie grep
zeigte..
Du kannst jetzt gerne, wenn du möchtest, prüfen, ob sort oder uniq
vielleicht mit irgendwelchen Puffergrößen arbeitet und dann bei
Überschreitung von diesem nur noch auf die kleinere Puffergröße
entsprechend sortiert bzw. auf einzigartige Elemente reduziert, das
würde dann nämlich das Ergebnis erklären.
Bedenke nämlich bitte, wenn du eine bspw. 20 GiB große Datei hast, dann
muss die Zeile, die bspw. mit A beginnt und sich gerade ganz am Ende der
Datei befindet, nach ganz vorne sortiert werden. Wenn du die 20 GiB
nicht auf einmal in das RAM bekommst, dann reicht ein einfaches Array
auf das man einen Sortieralgo anwendet nicht, sondern dann musst du dir
einen entsprechenden Algorithmus ausdenken der das berücksichtigt.
Gleiches gilt für das finden der uniq Elemente.
Und es ist durchaus möglich, dass ein Programm, abhängig von der
Datenmenge und dem verfügbaren RAM unterschiedliche Algorithmen
anwendet, weil der Algo, der mit kleinen Daten, die komplett ins RAM
passen vielleicht schneller ist, als der andere, der auch das
Zwischenauslagern auf Festplatte berücksichtigt und den Umgang mit
großen Datenmengen erlaubt.
Das Resultat davon ist, dass du im gleichen Programm unterschiedlich gut
getestete Algorithmen haben kannst
Das ganze dürfte jetzt schon über 10 Jahre her sein.
Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war
zu groß und ich musste die Festplatte mitverwenden.
Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück
überzeugt und springe gleich ans Ende:
Nano schrieb:> Das ganze dürfte jetzt schon über 10 Jahre her sein.> Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war> zu groß und ich musste die Festplatte mitverwenden.
Mit "über 10 Jahren" meinst du 30 Jahre oder so? Oder meinst du 8 GB?
Nur so zur Erinnerung:
-Anfang 2013 kam der Raspberry Pi mit 256 MB
-Ende 2007 kam das iPhone mit 128 MB
auf den Markt.
Mombert H. schrieb:> Ich gehe mal nicht auf die Mauer aus Text ein, die mich kein Stück> überzeugt und springe gleich ans Ende:>> Nano schrieb:>> Das ganze dürfte jetzt schon über 10 Jahre her sein.>> Mehr als 8 MiB RAM hatte ich damals nicht im Rechner, die Datenmenge war>> zu groß und ich musste die Festplatte mitverwenden.
Oh, kleiner Tippfehler. Es waren natürlich 8 GiB RAM.
Ich habe das damals auf meinem Core2Duo durchgeführt und die Distri war
irgendeine LTS Ubuntuversion aus der damaligen Zeit.
Jack V. schrieb:> Nano schrieb:>> Und es stellt sich hier dann auch gleich noch die Frage, warum man unter>> Rasbian für eine Rasberry Pi 3 keine vollwertige Version nimmt.>> Kommt so von Debian. So sehr ich die Distri auch mag – das ist eine der> Sachen, die ich noch nie nachvollziehen konnte. Ist aber auch kein Drama> – dauert keine Minute, bis man das behoben hat.
Eine Diskussion dazu im Debian-Devel-Forum findet man hier
switching to vim-tiny for standard vi?
https://lists.debian.org/debian-devel/2005/12/msg00796.html
Der richtige vim wurde für base als zu groß angesehen und es wird lange
diskutiert, welche optionale kleinere Version genommen werden soll.
Wahrscheinlich haben sie auch irgendwo diskutiert wie man die Nutzer
darüber informieren soll. Dazu habe ich aber auf die Schnelle keine
Stelle gefunden.
In der Paketbeschreibung von vim-tiny werden die Einschränkungen zwar
erwähnt, aber das sieht der Nutzer eines frisch installierten base
systems natürlich nicht, wenn er vim oder vi aufruft.
https://packages.debian.org/bullseye/vim-tiny
"This package contains a minimal version of Vim compiled with no GUI and
a small subset of features. This package's sole purpose is to provide
the vi binary for base installations. If a vim binary is wanted, try one
of the following more featureful packages: vim, vim-nox, vim-athena, or
vim-gtk3."
Siehe auch
Ein T. schrieb:> Ein Aufruf von "vim" gibt tatsächlich einen Hinweis aus, man möge doch> bitte den richtigen vim installieren. Ein Aufruf von "vi" hingegen gibt> das Folgende aus:
Nano schrieb:> BTW, der popularity Contest bei Debian ist auch immer wieder> interessant:
… solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild
ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig
abgewählt.
Le X. schrieb:> Zumindest dafür gibts Abhilfe ;-)> https://www.gog.com/de/game/baldurs_gate_2_enhanced_edition> Läuft bei mir unter Arch Linux nativ und problemlos.
Danke für den Hinweis. :)
Allerdings hatte ich das normale BG2 schon auf meinem Rechner
installiert, und grundsätzlich läuft es ja, nur die Maussteuerung kommt
nicht in die Gänge. In Windows gibt es solche Probleme auch, aber aber
meist nur für ein paar Minuten oder Sekunden. Das war z.B. bei Kolibri
OS so. Aber nach ein paar Minuten hatte sich die Maussteuerung gefangen.
> (Achtung: die enhanced Edition erlaubt eine höhere Auflösung und hat> minimal neuen Content (leider nicht vom ursprünglichen Studio), das mag> für Puristen evtl. nicht duldsam sein)
Finde ich nicht schlimm. Aber eigentlich mochte ich das Zusammenzählen
der Punkteverteilung beim Auswürfeln. Das hatte so einen netten
Überraschungseffekt.
Überhaupt scheinen mir die Arch-Entwickler der Abteilung Spiel und Spaß
viel aufgeschlossener zu sein. Das aber nur eine Vermutung am Rande. Bei
Fedora haben die schon angefangen, Benchmarks mit Far Cry 5 zu
veröffentlichen - aber natürlich ohne sich ein paar Gedanken zu machen,
was tatsächlich Gamemäßig abläuft, wo die Ansätze sind, oder wie man sie
ordentlich dokumentiert.
https://fedoramagazine.org/fedora-workstation-state-of-gaming-far-cry-5/Nano schrieb:> Joe 1146 votes, Rang 4218
Naja, für Nano gab es auch kleine Einführungen vom Rechenzentrum an
Unis. Teilweise waren (Einstiegs-)Kurse auch auf Nano ausgerichtet. Also
von daher kein unbekannter Editor.
Hinsichtlich der eigenständigen, unabhängigen Version auf Windows hat
Joe aber deutlich die Nase vor Nano.
Auch den MC gibt es schmerzfrei für Windows.
So ein wenig kann man sich in der Situation hier auch an Basic erinnert
fühlen. Letztlich war Basic für viele DIE Einstiegssprache schlechthin
in das Programmieren. Und die Verbreitung von Basic war auch extrem.
Irgendwie finde ich die Fortran 77 Werkzeuge der Watcom-Installation
auch noch etwas ansprechender als GNU-Fortran.
Jack V. schrieb:> Nano schrieb:>> BTW, der popularity Contest bei Debian ist auch immer wieder>> interessant:>> … solange man sich der Tatsache bewusst ist, dass es ein verzerrtes Bild> ist: Popcon ist optional und wird von fortgeschritteneren Usern häufig> abgewählt.
Wie bereits zuvor erwähnt:
"Leute, die bei der Installation von Debian dieser Survey Funktion
Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern
zu."
Beim Wählen ist das auch so. Wer nicht wählen geht, legitimiert die
Gewählten.
Nano schrieb:> "Leute, die bei der Installation von Debian dieser Survey Funktion> Datenerhebung nicht zugestimmt haben, stimmen automatisch den Siegern> zu."
Was halt dazu führt, dass es nicht dazu geeignet ist, die Verbreitung
oder gar Beliebtheit von irgendwas aufzuzeigen. Es war dazu gedacht, zu
bestimmen, was auf den ersten Installationsimages landet, und ist heute
weitgehend Deko.
Wie auch immer – ist halt wieder so’n irrelevanter Nebenschauplatz, der
eigentlich zum Thema nicht mal was beiträgt.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2
44684 root 20 0 69420 68264 1744 S 0.0 0.1 0:00.32 fe XXX
Dass hier der Speicherverbrauch nur geringfügig über der Größe der 64M
Datei, welche nur aus Newlines besteht, hatte ich in diesem Thread hier
mal kurz angedeutet:
Beitrag "Re: Vi Editor ausgestorben?"
Die Crux an den gängigen Editoren ist nämlich immer noch, dass sie
zeilenorientiert arbeiten. Deshalb bauen sie da pro Zeile
Verwaltungsstrukturen auf, die man gar nicht braucht.
Den Text-Speicher kann man auch viel einfacher aufbauen, nämlich aus je
zwei zusammenhängenden Blöcken, welche durch eine Lücke (gap)
voneinander getrennt sind:
1
buf1 | gap | buf2
2
size1 gapsize size2
Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per
memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in
die Lücke. Die gapsize wird dann um 1 verkleinert, size1 um 1
vergrößert. Bei weiteren Zeicheneinfügungen wird nichts mehr verschoben,
es wird nur noch size1 inkrementiert und gapsize dekrementiert.
Löschen per Backspace ist ebenso einfach:
1
size1--;
2
gapsize++;
Das wars. Und es funktioniert sogar zeilenübergreifend: Beim Löschen
eines Newlines passiert nicht mehr!
Ist die Lücke auf die Länge 0 geschrumpft, geschieht ein realloc(), um
eine neue Lücke zu erzeugen. Auf heutigen Betriebssystemen, wo der
Speicher sowieso nur virtuell gehandhabt wird, ist auch ein realloc()
auf 1 GB oder mehr überhaupt kein Problem.
Alle anderen Editierfunktionen werden analog implementiert, auf eine
zeilenorientierte Speicherstruktur kann komplett verzichtet werden. Die
Operationen auf den Speicher sind blitzschnell, da hier
zusammenhängender Speicher verwendet wird. Man muss sich also nicht mehr
von Zeile zu Zeile hangeln. Deshalb sind auch die Geschwindigkeiten bei
einer Textsuche im zusammenhängenden Speicher kaum zu toppen. Verkettete
Pointer auf die Zeilen oder ähnlich aufgebaute Verwaltungsstrukturen
sind damit obsolet.
Einziger Nachteil: Der Editor weiß nicht, in welcher Zeile sich der
Cursor befindet. Diese Position muss er entweder auf Anfrage selbst
ermitteln oder permanent bei jeder Textoperation nachhalten. Ich
persönlich brauche solch eine Permanentanzeige nicht, die mir sagt, dass
ich gerade in Zeile 9999 von 200000 stehe. Das kann der Editor auf
Tastendruck auch ad hoc ermitteln, wenn ich es mal brauche.
Frank M. schrieb:> Alle anderen Editierfunktionen werden analog implementiert, auf eine> zeilenorientierte Speicherstruktur kann verzichtet werden.
Das ist zu kurz gedacht. Die Anzeige von Text in einem Texteditor ist
ziemlich stark zeilenbasiert. Alle "comfort-Funtkionen" sind
zeilenbasiert. diff, git-blame, Fehlermeldungen und Warnungen vom
Compiler und so weiter. Es ist also naheliegend eine zeilenbasierte
Datenstruktur zu nutzen.
Frank M. schrieb:> Wenn man nun ein Zeichen einfügen will, verschiebt man die Lücke per> memcpy an die Stelle, wo der Cursor steht und schreibt das Zeichen in> die Lücke. Die Größe der Lücke wird dann um 1 verkleinert. Ist die Lücke> auf 0 geschrumpft, geschieht ein realloc, um eine neue Lücke zu> erzeugen.
Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es
plötzlich zwei Lücken und 3 Speicherblöcke. Führt man eine automatische
Umbenennung von Variablennamen durch, gibt es N_umbennenung + 1
Speicherblöcke. Und entfernt man die überflüssigen Leerzeichen am Ende
jeder Zeile gibt es N_zeilen+1 Speicherblöcke. Oder soll bei jeder
dieser Aktionen durch kopieren wieder auf 2 Speicherblöcke reduziert
werden? Für kleine Config-Files ist das egal, für eine 10k Zeilen
Quelltextdatei oder größe CSV-Datein kann das schnell in einer
Katastrophe enden.
mh schrieb:> Die Anzeige von Text in einem Texteditor ist ziemlich stark> zeilenbasiert.
Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei
der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt
wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein
Bildschirmfenster hat.
mh schrieb:> Und wenn man an mehreren Stellen im Text Operationen durchführt gibt es> plötzlich zwei Lücken und 3 Speicherblöcke.
Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die
Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben.
Es gibt immer nur eine Lücke.
Der Editor existiert und ist real. Was er unter anderem kann, hatte ich
in obigem Link mal angerissen:
Beitrag "Re: Vi Editor ausgestorben?"
Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache,
kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles
mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen
Blatt. Es gibt ihn nämlich nicht öffentlich.
Frank M. schrieb:> mh schrieb:>> Die Anzeige von Text in einem Texteditor ist ziemlich stark>> zeilenbasiert.>> Für die Anzeige brauche ich lediglich einen Start-Pointer in buf1, bei> der Bildschirmausgabe läuft der los und zählt die Newlines mit. Gestoppt> wird dann nach N Zeilen - je nachdem, wieviele Zeilen mein> Bildschirmfenster hat.
Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer
gestartet werden muss. Auch wenn man in Zeile 424242 und der
Start-Pointer 2GB entfernt ist.
Frank M. schrieb:> Du hast das Prinzip nicht verstanden: Bei jeder Operation wird die> Lücke, wenn sie gerade nicht an der richtigen Stelle steht, verschoben.> Es gibt immer nur eine Lücke.
Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die
Lücke fällt.
Frank M. schrieb:> Er kann Makros, mehrere Fenster, hat eine eigene Programmiersprache,> kann UNIX/Linux-Befehle im editierbaren(!) Fenster ausgeben und vieles> mehr. Dass Du noch nie was von "fe" gehört hast, steht auf einem anderen> Blatt. Es gibt ihn nämlich nicht öffentlich.
Wieviele Personen haben denn diesen "fe" schon getestet?
mh schrieb:> Das erfordert dann aber, dass für jedes Neuzeichnen beim Start-Pointer> gestartet werden muss. Auch wenn man in Zeile 424242 und der> Start-Pointer 2GB entfernt ist.
Der Start-Pointer liegt immer mindestens 3 Zeilen vor der
Text-Cursor-Position. Das ist überhaupt nicht weit weg. Wenn ich mit dem
Cursor eine Zeile tiefer gehe, wandert der Start-Pointer zum nächsten
Newline (aus seiner Sicht) vor.
Warum 3 Zeilen? Ich hasse Editoren, bei denen man die darüberliegende
Zeile erst sieht, wenn man mit dem Cursor oben am Bildschirmrand
anschlägt. Dasselbe gilt für den unteren Rand. Nähere ich mich ihm, dann
fängt er frühzeitig an zu scrollen.
> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die> Lücke fällt.
Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle
steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb
eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000
und dann 8000.
> Wieviele Personen haben denn diesen "fe" schon getestet?
Gestetet? Ungefähr ein Dutzend. Aktiv genutzt? Ein paar tausend. Er
wurde u.a. an staatliche Stellen verkauft, z.B. an die Bundeswehr und
diverse Staatsministerien - aber mit anderem Namen und Kontext. "fe" ist
nur eine private Variante davon.
P.S.
Wenn Du dem Link in obigem Beitrag von mir gefolgt wärst, dann wüsstest
Du, dass die Idee mit dem Gap nicht auf meinem Mist gewachsen ist,
sondern von James Gosling stammt.
Hier ein kleiner Literaturhinweis dazu:
https://en.wikipedia.org/wiki/Gosling_Emacs oder auch zu seiner Person:
https://en.wikipedia.org/wiki/James_Gosling . Er war unter anderem der
Chefdesigner bei der Entwicklung von Java.
Von daher behaupte ich mal, dass Editoren, die mit einer Lücke arbeiten,
von mehreren hunderttausenden Anwendern genutzt wurden bzw. wird.
P.P.S.
Diese Stelle in seinem Code finde ich einfach genial:
https://gist.github.com/jart/0a6a402b480e7dbcf8e61895759f2058
Unter einem ASCII-Art-Totenkopf steht folgendes:
1
If you think you understand it,
2
You Don't,
3
So Look Again.
Ergänzung: Ich habe lediglich seine Idee übernommen, nicht seinen Code.
Den finde ich nämlich ziemlich gewöhnungsbedürftig. Zudem wurde
"Gosmacs" von Gosling in den 80ern entwickelt. Da war der
C-Sprachstandard längst nicht so weit wie heute. Von daher sieht der
Code einfach "alt" aus.
Richard Stallman (GNU Foundation) hatte ursprünglich für seinen "GNU
Emacs" Teile von Gosmacs übernommen, hat diese dann auf Bitten von
Unipress, welche mittlerweile Gosmacs kommerziell erworben hatte, wieder
entfernt und neu implementiert. Ob "GNU Emacs" heute noch genauso mit
einer Lücke arbeitet, weiß ich nicht.
Offenbar ja: Nch kurzem Googlen finde ich folgendes:
http://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html
GNU Emacs scheint ebenso mit der Lücke (gap) zu arbeiten... da haben wir
ja noch ein paar hunderttausend bis Millionen Anwender mehr ;-)
Frank M. schrieb:>> Es muss also bei jeder Operation kopiert werden, wenn sie nicht in die>> Lücke fällt.>> Du ahnst gar nicht, wie oft die Lücke bereits an der richtigen Stelle> steht. Normalerweise bearbeitest Du nämlich einen Textblock innerhalb> eines Kontexts und nicht Zeichen nacheinander in Zeile 100, 2000, 5000> und dann 8000.
Selbst wenn: Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs
aktuellen PC kein Ding.
Yalu X. schrieb:> Mal eben 1 GB im RAM zu kopieren ist für einen halbwegs> aktuellen PC kein Ding.
So ist es. Und man springt ja nicht dauernd vom Anfang zum Ende und
wieder zurück. Und selbst wenn, wird noch lange nicht die Lücke
verschoben. Verschoben wird sie erst, wenn ich auch tatsächlich an
entfernter Stelle eine Textmanipulation vornehme.
Frank M. schrieb:> Alle anderen Editierfunktionen werden analog implementiert, auf eine> zeilenorientierte Speicherstruktur kann komplett verzichtet werden.
Solch einen Editor (in der Art) hab ich damals (tm) in Z80-Assembler
geschrieben. Hat wirklich sehr effizient funktioniert.
Nachtrag: Heute würde ich es nicht wieder in Assembler machen. ;)
Wie schnarchlangsam zeilenorientierte Editoren arbeiten, kann man
einfach nachprüfen, wenn man XXX mal auf 640 MB vergößert.
1
head -c640M /dev/zero | tr "\000" "\n" >XXX
Dann startet man seinen Wunscheditor und drückt sofort die erforderliche
Tastenkombination, um den Editor wieder zu verlassen:
1
$ time fe XXX
2
real 0m3.046s
3
user 0m2.930s
4
sys 0m0.116s
5
6
$ time vi XXX
7
real 0m12.316s
8
user 0m11.648s
9
sys 0m0.668s
10
11
$ time nano XXX
12
real 0m56.437s
13
user 0m46.112s
14
sys 0m10.324s
Einen Kommentar kann ich mir dazu mal sparen, nano säuft jedenfalls
gnadenlos ab. Auch die sys-Zeit, welche angibt, wie lange die Anwendung
den Kernel beansprucht, ist unterirdisch.
P.S.
Getestet unter Linux mit
- AMD Ryzen 9 3900 (12 Kerne)
- 128 GB RAM
- 2x Samsung SSD PM983 1.92TB im Soft-Raid 1
Frank M. schrieb:> Dann startet man seinen Wunscheditor und drückt sofort die erforderliche> Tastenkombination, um den Editor wieder zu verlassen:
Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg? (Wäre auf
jeden Fall standardisierter).
Da es neovim auch für Windows gibt, dachte ich, den schau ich mir mal
genauer an, weil das beim Watcom Vi mit den Plugins nicht so toll ist.
Nicht grundsätzlich aber für Neovim gibt es so nette Sachen und Lua
Programming.
Außerdem wird schon ein Plugin Manager empfohlen, da fühlt man sich fast
wie bei Skyrim wo manche nicht vor > 300 Mods loslegen können.
Auf die schnelle Gucken war aber auch erstmal nix, weil offenbar eine
dll vergessen wurde, dem Packet beizulegen - oder wenigstens ein Readme
diesbezüglich.
Bei gvim geht das alles schon lange viel problemloser.
(bei cygwin auch)
Bei den Plugins für neovim sieht man oft Begleitbefehle für die
Powershell. Da fragt man sich auch, was soll das. Können die Leute keine
normale Windowskonsole mehr benutzen?
rbx schrieb:> Wäre beim Vi ZQ - oder klickt man einfach die Konsole weg?
Ich habe bei vi einfach ":q[CR]" gedrückt, ohne die Gänse. Da die
Ladezeit immer die Tastendruck-Zeit übertraf, hat das auch keine Rolle
gespielt.
Das kann man auch ganz gut daran erkennen, dass in allen 3 Fällen
ziemlich genau
Frank M. schrieb:> Dann startet man seinen Wunscheditor und drückt sofort die erforderliche> Tastenkombination, um den Editor wieder zu verlassen:>
1
> $ time fe XXX
2
> real 0m3.046s
3
> user 0m2.930s
4
> sys 0m0.116s
5
>
6
>
Und wie soll die Zukunft deines fe Editors aussehen?
Proprietärer Code neigt dazu, sofern er nicht in einem Unternehmen über
mehrere Generationen hinweg weitergepflegt wird, zu sterben.
rbx schrieb:> Bei den Plugins für neovim sieht man oft Begleitbefehle für die> Powershell. Da fragt man sich auch, was soll das. Können die Leute keine> normale Windowskonsole mehr benutzen?
Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,
aber nicht wollen. Die Powershell kann laut deren Aussage an vielen
Stellen deutlich mehr.
Ein T. schrieb:> Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,> aber nicht wollen. Die Powershell kann laut deren Aussage an vielen> Stellen deutlich mehr.
Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super
mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht.
Windows funktioniert anders als Linux, man sucht sich erstmal zusammen,
was man so gebrauchen kann, wie z.B. die Sysinternals Programme.
(oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu
compilieren)
rbx schrieb:> Ein T. schrieb:>> Ich kenne mehrere, die die normale Windowskonsole zwar benutzen können,>> aber nicht wollen. Die Powershell kann laut deren Aussage an vielen>> Stellen deutlich mehr.>> Klar, heißt ja auch Powershell. Poweruser, die ich so kenne, kamen super> mit der normalen Dos-Konsole bei Admin-Aufgaben zurecht.> Windows funktioniert anders als Linux, man sucht sich erstmal zusammen,> was man so gebrauchen kann, wie z.B. die Sysinternals Programme.>> (oder den tiny C Compiler von Fabrice Bellard z.B. um Lua zu> compilieren)
Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser"
fundamental von der meinen unterscheidet. Ich rede da von (und mit)
Profis, weißt Du, und die sagen mir alle, daß die Powershell nicht nur
so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe.
Ein lieber Segelfreund von mir ist etwa spezialisiert auf MS Exchange,
früher bei IBM und heute bei Microsoft. Der sagt, daß er früher meistens
die GUI des Exchange-Servers und manchmal außerdem RegEdit benutzt hat,
und mittlerweile nur noch die Powershell benutzt -- weil er damit viel
schneller, sicherer und vor allem auch reproduzierbarer zum Ziel kommt.
Ein anderer Mitsegler ist bei MS Deutschland im Azure-Bereich tätig und
erzählt mir ganz Ähnliches.
Klar, wenn die wesentlichsten und wichtigsten Tätigkeiten am Computer
sich auf Spiele und etwas... exotischere Hobbies wie die von Dir
genannten C-Compiler beschränken, dann wird man die Leistungsfähigkeit
einer modernen Kommandozeile natürlich weder benötigen noch zu schätzen
wissen. Das ist auch nicht schlimm.
Aber darüber zu lästern und zu unterstellen, die Leute würden die
Powershell nur benutzen, weil sie zu blöd für die klassische cmd.exe
wären, das geht mir dann doch ein bisschen zu weit. Wie gesagt, Du hast
halt keinen Bedarf nach einer modernen, leistungsfähigen Kommandozeile,
und deswegen offensichtlich auch weder Erfahrung damit noch eine Ahnung
davon, was die Powershell kann.
Aber gräm' Dich nicht, in diesem Forum bist Du da in guter Gesellschaft:
es gibt hier viele Leute, die alles ablehnen, das sie nicht verstehen
(wollen), von der Objektorientierung über Skriptsprachen bis hin zu
modernen Kommandozeilen, von Machine Learning über Fuzzy Logic bis hin
zu bewährten Editoren... q.e.d. ;-)
Ein T. schrieb:> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.
Sie kann mehr, macht aber alles anders, und vor allem kann sie
Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich
schmerzlich feststellen.
Jörg W. schrieb:> Ein T. schrieb:>> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.>> Sie kann mehr, macht aber alles anders, und vor allem kann sie> Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich> schmerzlich feststellen.
Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!
Das ist eine ganz andere Philoshopie.
Nano schrieb:> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!
Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein
generischer Ersatz für ein cmd.exe sein kann und/oder will.
Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset
von cmd.exe sei. Ist sie halt nicht.
Ein T. schrieb:> und die sagen mir alle, daß die Powershell nicht nur> so heißt, sondern auch sehr viel mehr kann als die klassische cmd.exe.
Das ist allerdings auch keine große Kunst.
Ein T. schrieb:> Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser"> fundamental von der meinen unterscheidet.
Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun?
Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden
wird.
Sicher kann die einiges, aber vergleichen würde ich das, was die
Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit
konnte man auch viel machen.
Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm.
Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm
zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim??
Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen
auf Spatzen schießen.
Die Powershell könnte man auch mit einem interaktiven Interpreter (z.B.
Python-Shell) vergleichen. Eine Posix-Shell möchte sie ja offenkundig
nicht sein.
Ich höre über die Powershell auch nur gutes, auch von wenig MS-affinen
Personen.
Da ich damit aber kaum gearbeitet habe kann ich das weder bejajen noch
verneinen.
Um wirklich krasses Zeugs damit machen zu können braucht man wohl auch
etwas .NET-Background.
Nano schrieb:> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!> Das ist eine ganz andere Philoshopie.
Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan
(sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind.
Jörg W. schrieb:> Ja, aber das erklärt, warum sie eben nur wegen des "Power" im Namen kein> generischer Ersatz für ein cmd.exe sein kann und/oder will.
Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf
ausgelegt, .NET-Objekte zu verknüpfen. Wenn dies das Designziel war,
dann sollte und wird sie gar kein generischer Ersatz für cmd.exe sein.
> Obige Aussage implizierte jedoch, dass die Powershell eine Art Superset> von cmd.exe sei. Ist sie halt nicht.
Diese Implikation war von mir keineswegs intendiert, und vermutlich auch
nicht von jenen Leuten, die mir von der Powershell erzählt haben.
rbx schrieb:> Ein T. schrieb:>> Vielleicht liegt das daran, daß sich Deine Definition von "Poweruser">> fundamental von der meinen unterscheidet.>> Was haben jetzt unsere Persönlichkeiten mit bestimmten Workflows zu tun?> Mein Verdacht ist einfach der, dass die "Power"-Shell missverstanden> wird.
Du hattest den Begriff "Poweruser" eingebracht, nicht ich.
> Sicher kann die einiges, aber vergleichen würde ich das, was die> Powershell bietet eher mit Visual Basic und Visual Basic Script. Damit> konnte man auch viel machen.
Wen ich mich recht entsinne, waren VB, VBA und VBS aber niemals
interaktiv. Aber die Powershell ist genau das: eine interaktive Shell.
> Für Profis bei Microsoft ist die Powershell sowieso ein Pflichtprogramm.> Oder man würde es so annehmen. Aber die Powershell als Pflichtprogramm> zum Konfigurieren für Plugins für einen noch viel zu linuxoiden neovim??> Das ist grober Unfug, oder man könnte auch sagen: Mit ungenauen Kanonen> auf Spatzen schießen.
Unter den meisten Linux-Systemen gibt es bereits sehr moderne,
leistungsfähige Shells, und das .NET-Framework, auf das die Powershell
zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären
Ansätzen. Insofern stellt sich mir gerade die Frage, wie Du darauf
kommst, daß jemand die Powershell unter Linux benutzen wollen würde --
erst Recht zur Konfiguration von neovim?!
Ein T. schrieb:> Nano schrieb:>> Das sind bei der Powershell keine Datenströme, sondern das sind Objekte!>> Das ist eine ganz andere Philoshopie.>> Also sind Datenströme keine Objekte? Dann sollen wir mal wimalopaan> (sp?) fragen, was std::cin, std::cout, std::cerr und std::clog sind.
Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf
anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und
Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Auch der Austausch von komplexen Datenstrukturen ist textbasiert
natürlich etwas schwieriger.
Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein
Einwand inhaltlich richtig, wenn auch nicht unbedingt berechtigt.
Ein T. schrieb:> und das .NET-Framework, auf das die Powershell> zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären> Ansätzen
Veto.
Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht
schlechter) läuft (als unter Windows) ;-)
Ein T. schrieb:> Das hatten wir doch schon vor Kurzem: die Powershell ist wohl darauf> ausgelegt, .NET-Objekte zu verknüpfen.
Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der
ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass
sie unbrauchbar werden (irgendwelches Padding eingefügt).
Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle
ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur
.NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind.
Le X. schrieb:> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und
"Daten" gibt es dort sowieso nicht, entsprechend ist es auch völlig
egal, ob ich lesbare Texte oder irgendwelche Binärklumpen dort durch die
Kante schiebe. Das funktioniert einfach™-
Jörg W. schrieb:> Le X. schrieb:>> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf>> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und>> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.>> Was allerdings Unsinn ist, denn die Unterscheidung zwischen "Text" und> "Daten" gibt es dort sowieso nicht
Wieso schneidest du beim Zitieren denn meinen essentiellen Satz ab?
Sorry, aber das ist ganz mies, sowas brauchts echt nicht.
Ich hab extra für die ganz-päpstliche Fraktion klargestellt:
Le X. schrieb:> Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein> Einwand inhaltlich richtig,
Aber ein Textinterface funktioniert halt in der Praxis ganz anders als
ein Interface mit definierten Objekten aus einem systemweiten Framework,
und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon
sehr schwierig (weswegen Dinge wie xml und json erfunden wurden).
Bei Text muss halt Tool A den Output von Tool B genau parsen können,
notfalls muss man mit Tools C, D und E den Zwischenoutput umformen.
Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar:
> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Ich sehe schon dass der Powershell-Ansatz hier interessante Ansätze hat.
Darauf wollte nano wohl hinaus, auch wenn er's mal wieder geschafft hat
das sehr unglücklich zu formulieren.
Die Diskussion ob Texte auch Daten sind müssen wir aber wirklich nicht
führen.
Le X. schrieb:> Und das apt auf meinem fileserver stellt schon mal vorsichtshalber klar:>> WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Das hat den Hintergrund, dass ›apt‹ für die direkte Verwendung gedacht
ist, während es zum Scripten dafür geeignete Komponenten gibt, die man
anstelle von ›apt‹ nutzen sollte.
Le X. schrieb:> Le X. schrieb:>> Aber klar, Strings sind natürlich auch Datenströme, von dem her ist dein>> Einwand inhaltlich richtig,>> Aber ein Textinterface funktioniert halt in der Praxis ganz anders als> ein Interface mit definierten Objekten aus einem systemweiten Framework,> und an manchen Stellen (komplexe Datenstrukturen) wirds mit Text schon> sehr schwierig (weswegen Dinge wie xml und json erfunden wurden).> Bei Text muss halt Tool A den Output von Tool B genau parsen können,> notfalls muss man mit Tools C, D und E den Zwischenoutput umformen.
Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann
(zumindest unter unixoiden Systemen), nicht nur Text. Das kann man z.B.
bei einem tar.gz-Archiv sehen. Das lässt sich z.B. so erzeugen:
1
tar c mydir | gzip > mydir.tar.gz
Früher, bevor tar selbst gzip aufrufen konnte, musste man es sogar in
der Art schreiben. Der Output von tar besteht nicht aus Text, und der
von gzip erst recht nicht.
Rolf M. schrieb:> Der Punkt ist, dass man durch eine Pipe beliebige Daten schicken kann> (zumindest unter unixoiden Systemen), nicht nur Text.
So ist es (und so funktioniert es ja auch in cmd.exe), niemand hat
jemals festgelegt, dass eine Pipe nur für Strings da wäre. Daher hatte
ich das Zitat auch eingekürzt (weil ich die Unterscheidung nicht einmal
verstanden habe).
Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das
eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn
beide aus der .NET-Welt sind, dann sind das halt wie auch immer
serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die
nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen
sollte.
Aber gut, wir hatten die Diskussion schon, ich weiß, dass die Powershell
offenbar nur für .NET-Freunde richtig Sinn hat und weiß sie zu meiden.
Mit .NET habe ich eh nichts weiter am Hut.
Ein T. schrieb:> Insofern stellt sich mir gerade die Frage, wie Du darauf> kommst, daß jemand die Powershell unter Linux benutzen wollen würde --> erst Recht zur Konfiguration von neovim?!
Eher so: Warum benutzen Linuxer nicht die normale Shell (CMD) oder
wenigstens einer der normalen Alternativen dazu?
Da gibt es ja einige. Ich fand es z.B. recht interessant, debug auch in
der Cygwin Konsole aufrufen zu können.
Mit Cygwin geht so einiges, sicher nicht alles, aber man kann seinen
Spaß haben.
Mit dem ghci oder dem Watcom Vi in der Powershell zu arbeiten, ist
dagegen eher nervtötend.
Möglicherweise hatte ich mich bei dem Plugs auch etwas verguckt..
https://github.com/junegunn/vim-plug#installation
Le X. schrieb:> Naja, aus dem Kontext ergibt sich doch echt klar dass nano darauf> anspielt dass die unixoiden Standard-Streams textbasiert arbeiten und> Programm A nicht ohne weiteres Ausgaben von Programm B verarbeiten kann.
Das scheint für die Powershell auch zu gelten, wenn ich die Ausführungen
von Jörg Wunsch zu diesem Thema lese. Er berichtete diesbezüglich von
Schwierigkeiten mit Wireshark, wenn ich mich recht entsinne.
> Auch der Austausch von komplexen Datenstrukturen ist textbasiert> natürlich etwas schwieriger.
Kommt halt darauf an. Die textbasierte Weitergabe hat den großen
Vorteil, daß sie ausgesprochen flexibel ist und man mit Werkzeugen wie
grep(1), sed(1), awk(1) etc manipulieren kann (und manchmal muß), was
auf der Empfängerseite ankommt. Wie die erfahreneren Nutzer von
unixoiden Pipes wissen, kann das bisweilen in ziemlich... aufwändigen
Reformatierungen münden, die bei größeren Datenmengen durchaus auch
manchmal zeit- und ressourcenaufwändig sein können.
Wenn man wie Microsoft hingegen ein Framework wie .NET hat, mit dem man
die meisten Funktionen des Systems und der eigenen Applikationen nutzen
kann, dann macht das mit der Weitergabe von Objekten dieses Frameworks
natürlich Sinn. Das heißt aber auf der anderen Seite allerdings auch,
daß die verwendeten Komponenten mit den Objekten des Frameworks
umzugehen wissen.
Die Grundfunktion -- nämlich die Aus- oder Rückgabe einer Komponente als
Eingabe einer anderen Komponente zu verwenden und die einzelnen
Komponenten so flexibel zu einer komplexeren Funktionalität zu verbinden
-- ist insofern im Kern dieselbe. Nur die Umsetzung ist bei den beiden
Lösungen ganz unterschiedlich realisiert.
> Ein T. schrieb:>> und das .NET-Framework, auf das die Powershell>> zugeschnitten sein soll, gibt es unter Linux auch nur in rudimentären>> Ansätzen>> Veto.> Mono ist zumindest so weit entwickelt dass Kerbal Space Program (nicht> schlechter) läuft (als unter Windows) ;-)
Das mag sein, davon habe ich keine Ahnung und verlasse mich daher gerne
auf Deine Aussage. Tatsache ist allerdings, daß ich um Software, bei der
Miguel De Icaza die Finger im Spiel hatte, lieber einen großen Bogen
mache. ;-)
Jörg W. schrieb:> Ja, aber es ist natürlich trotzdem albern, wenn Daten von jemandem, der> ganz offensichtlich nicht aus .NET-Land kommt, so verhunzt werden, dass> sie unbrauchbar werden (irgendwelches Padding eingefügt).
Wenn einem so etwas begegnet, ist das sicherlich ärgerlich. Womöglich
gibt es für solche Fälle sogar einen Workaround?
> Dann sollten sie besser die komplette Ausgabeumlenkung in so einem Falle> ablehnen mit einer Fehlermeldung, die klar und deutlich sagt, dass nur> .NET-fähige Absender und Empfänger für EA-Umleitungen zulässig sind.
Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine
Software läuft, welche nicht .NET-fähig ist?
Ein T. schrieb:> Müßte die Pipe dazu nicht wissen, daß auf der Empfängerseite eine> Software läuft, welche nicht .NET-fähig ist?
Keine Ahnung, was sie sich überhaupt dabei gedacht haben. Ich vermute ja
mal, dass das gar nicht so sehr mit .NET zusammenhängt, sondern dass sie
nur versuchen, da irgendwelche Zeichensatz-Konvertierungs-Geschichten
drauf anzuwenden. Mir genügte es dann, den Schuldigen gefunden zu haben
und zu meiden. (Absender war bei mir ein Python-Script, der .pcap
erzeugt, Empfänger Wireshark. Abspeichern der .pcap-Datei per
Ausgabeumlenkung hat sie genauso verhunzt.)
Jörg W. schrieb:> Wenn so ein Datenstrom dann serialisierte Objekte enthält, dann wäre das> eine reine Vereinbarung zwischen Sender und Empfänger der Daten (wenn> beide aus der .NET-Welt sind, dann sind das halt wie auch immer> serialisierte .NET-Objekte); ich verstehe nicht, warum die Shell, die> nur die Pipeline aufbauen soll, in diesen Daten dann noch herum pfuschen> sollte.
Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder
nur Zeiger auf Objekte, die in einer Art Shared Memory liegen. Damit
könnte man sich den ganzen Aufwand mit Serialisierung und
Deserialisierung sparen. Keine Ahnung, ob Microsoft das in der
Powershell so implementiert hat, aber clever wär's.
Ein T. schrieb:> Die Frage ist halt, ob das wirklich serialisierte Objekte sind -- oder> nur Zeiger auf Objekte, die in einer Art Shared Memory liegen.
Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand
an so einem Agreement nicht teilnimmt und in dem Falle entweder die
Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen.
Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle
Option.
(Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in
einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch
ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das
ganz normale VM-System das bereits kann.)
Noch einmal 2 Fragen zu vim:
1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl
ausgeben?
Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es
nett, wenn man nicht selber zählen muss.
2. Nochmal meine Frage von weiter oben.
Wie damals bereits gesagt, habe ich youcompleteme installiert:
1
apt search ^vim-youcompleteme
2
Sortierung… Fertig
3
Volltextsuche… Fertig
4
vim-youcompleteme/stable,now 0+20200825+git2afee9d+ds-2 all [installiert]
5
fast, as-you-type, fuzzy-search code completion engine for Vim
Ein T. schrieb:> Tipp für größere Archive:> tar c mydir | pigz > mydir.tar.gz>> HF! ;-)
Kenn ich. Und wenn man stärker komprimieren will per bzip2, kann man zum
Beschleunigen pbzip2 verwenden. Bevor ich clonezilla entdeckt habe, hat
mir das deutlich geholfen beim Komprimieren von 500GB-Festplatten-Images
:)
Ein T. schrieb:> Keine Ahnung, ob Microsoft das in der> Powershell so implementiert hat, aber clever wär's.
Naja, dann muss das ganze ja auch irgendwie über Prozessgrenzen hinweg
verwaltet werden, und Zugriffe müssen synchronisiert werden. Durch das
Kopieren umgeht die Pipe solche Probleme komplett.
Nano schrieb:> Noch einmal 2 Fragen zu vim:>> 1. Kann vim auch die Zeichen zwischen zwei "" zählen und die Anzahl> ausgeben?
Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro
stecken, um es direkt nutzen zu können.
Navigiere zum ersten " des Strings, dann:
yt"
:echo strlen(<C-r>")
(<C-r> steht für Ctrl und r)
> Aber vim-addons zeigt an:> vim-addons> # Name User Status System Status> apparmor removed removed> editexisting removed removed> espeak removed removed> justify removed removed> matchit removed removed> youcompleteme removed removed>> Und wie nutze ich das jetzt?
Jörg W. schrieb:> Kann natürlich sein, aber dann sollten sie zumindest merken, wenn jemand> an so einem Agreement nicht teilnimmt und in dem Falle entweder die> Daten 1:1 weiterleiten, oder zumindest eine Fehlermeldung bringen.>> Verhunzen der Daten halte ich jedenfalls nicht für eine sinnvolle> Option.
Naja... hätte, wäre, wenn. Anscheinend war das wohl nicht gewollt oder
jedenfalls nicht vorgesehen. Da müßte man die Entwickler fragen, warum
sie das nicht gemacht haben und ob es eventuell Workarounds gibt.
> (Btw., auf aktuellen unixoiden Systemen dürfte die Datenübergabe in> einer Pipe tatsächlich auf sowas wie shared memory basieren. Geht auch> ganz ohne irgendein Agreement über den Inhalt des Datenstroms, weil das> ganz normale VM-System das bereits kann.)
Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über
physikalische Dateien, mithin über den Dateisystempuffer arbeiten
würden. Keine Ahnung, ob das stimmt, oder ob meine Erinnerung mich
womöglich trügt.
Nano schrieb:> Wie damals bereits gesagt, habe ich youcompleteme installiert:> [...]> Und wie nutze ich das jetzt?
Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast,
ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits
gefunden. Na, dann benutz' die doch einfach.
Ein T. schrieb:> Irgendwann und irgendwo habe ich mal gelesen, daß Shell-Pipes über> physikalische Dateien, mithin über den Dateisystempuffer arbeiten> würden.
Nö, intern (zumindest im BSD, in Linux kenne ich mich nicht aus)
arbeiten sie genauso wie local domain sockets. Sind also eigentlich
bidirektional, allerdings ist dieses Feature nicht portabel.
Könnte sein, dass sowas wie command.com das mal mit Dateien emuliert
hat, oder war's die microshell auf CP/M?
Rolf M. schrieb:> Ja. Es ist etwas umständlich, aber das kann man sich auch in ein Makro> stecken, um es direkt nutzen zu können.> Navigiere zum ersten " des Strings, dann:> yt"> :echo strlen(<C-r>")>> (<C-r> steht für Ctrl und r)
Ja du hast recht, das ist umständlich, aber:
>
1
> vim-addons install youcompleteme
2
>
youcompleteme, wenn es per vim-addons install dann eingerichtet ist,
danke für den Hinweis, zeigt automatisch an, wenn ein String, der einem
char Array zugewiesen wird zu klein ist. Das ist also sogar noch besser.
Ändern müsste man nur die Farbe, rosa Schrift auf rotem Hintergrund ist
schlecht lesbar.
> Ich musste noch zusätzlich folgendes tun:>
1
> sudo apt install python3-distutils
2
>
Das wurde bei mir automatisch mitinstalliert und war schon drauf.
Ein T. schrieb:> Nano schrieb:>> Wie damals bereits gesagt, habe ich youcompleteme installiert:>> [...]>> Und wie nutze ich das jetzt?>> Gar nicht. Wie Du uns bereits mehrmals überaus ausführlich erklärt hast,> ist vi(m) nichts für Dich, und Du hast Deine Arbeitsumgebung(en) bereits> gefunden. Na, dann benutz' die doch einfach.
Nur weil ich etwas ausprobieren will, heißt das nicht, dass ich das dann
dauerhaft benutzen will.
Und youcompleteme ist nicht vim, sondern ein Addon zu vim. Das ist ein
großer Unterschied!
Nano schrieb:> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es> nett, wenn man nicht selber zählen muss.
Könnte man aber auch einer Suchmaschine fragen:
https://vim.fandom.com/wiki/Word_count
rbx schrieb:> Nano schrieb:>> Die Länge eines Strings zu wissen ist manchmal hilfreich, da wäre es>> nett, wenn man nicht selber zählen muss.>> Könnte man aber auch einer Suchmaschine fragen:>> https://vim.fandom.com/wiki/Word_count
Da steht nirgends etwas von "word count between """ und das war ja meine
Frage.
Um eine generelle Zeichenzählung geht es ja gerade nicht.
Und ja, sicher kann man das wie oben mit etwas mehr Eingabeparametern
dann auch irgendwie hinbiegen, aber diese aufwendigere Methode zeigt
dann auch, dass das Zeichenzählen zwischen zwei "" nicht explizit
vorgesehen war.
Und das wollte ich wissen ob es da entsprechendes gibt.
Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert
hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim), wäre
dir sicher aufgefallen, dass beim Markieren mit v, shift-V oder ctrl-V
die Größe des markierten Bereichs in der Statuszeile angezeigt wird.
Also markierst du einfach den String mit vi" (s. mein Beitrag weiter
oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der
String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als
auch in Bytes angezeigt.
Nano schrieb:> zeigt dann auch, dass das Zeichenzählen zwischen zwei "" nicht> explizit vorgesehen war.
Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die
nicht explizit vorgesehen sind, nämlich durch das Kombinieren von
Operatoren, Motions usw.
Yalu X. schrieb:> Wenn du die Dinge, die dir bisher gezeigt wurden, auch ausprobiert> hättest (nicht nur im vim.tiny, sondern in einem richtigen Vim),
Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich
schon längst vim installiert habe.
> Das Schöne an Vim ist, dass man auch Dinge elegant umsetzen kann, die> nicht explizit vorgesehen sind, nämlich durch das Kombinieren von> Operatoren, Motions usw.
Lies oben nochmal und verstehe was ich geschrieben habe.
Nano schrieb:> Wenn du lesen würdest was da steht, dann würdest du wissen, dass ich> schon längst vim installiert habe.
Und die Länge des markierten Bereichs hat er nicht angezeigt?
Yalu X. schrieb:> Also markierst du einfach den String mit vi" (s. mein Beitrag weiter> oben), und schon wird seine Länge angezeigt. Besser noch: Wenn der> String Multibyte-Zeichen enthält, wird die Länge sowohl in Zeichen als> auch in Bytes angezeigt.
Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16
Bytes raus, was falsch ist. Richtig wären 15 Bytes (da \n in dem String
ein Zeichen ist, aber im Quellcode aus zweien besteht und daher in
diesem Fall auch so gezählt wird). Die von mir gezeigten Methode bekommt
das korrekte Ergebnis raus.
Rolf M. schrieb:> Bei "Hällo wörld\n", bekomme ich da aber (mit utf-8) 14 Zeichen und 16> Bytes raus, was falsch ist.
Ok, die angezeigte Länge berücksichtigt keine Escape-Backslashes. Diese
muss man selber von der angezeigten Länge subtrahieren, falls es sich um
ein C-Stringliteral handelt.
Suchmaschine spukt u.a. aus:
wc -m
g Strg G
vimscript
Bei letzten Punkt denkt man dann: neovim? Lua!
(war das mit der fehlenden dll für Windows nur ein Fettnäpfchen? Leider
nicht, das wurde wohl gezielt so anvisiert, im Sinne von
Nutzplattformfokussierung bzw. -beschränkung)
(xkcd bzw. Randall Munroe erinnert recht stark an die Tagebücher und
Briefe oder andere Schriften von Georg Christoph Lichtenberg
https://de.wikipedia.org/wiki/Sudelb%C3%BCcher )
vim vs emacs?
Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher
als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder
ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass
mehr Erklärung notwendig ist?
willi schrieb:> vim vs emacs?>> Wenn man sich bei amazon umsieht, findet man über vim viel mehr Bücher> als über emacs. Ist das ein Indiz, dass vim viel mehr genutzt wird, oder> ist das ein Indiz, dass vim so kompliziert in der Bedienung ist, dass> mehr Erklärung notwendig ist?
Ohne diesbezüglich Daten erhoben und analysiert zu haben, würde ich das
als Indiz werten, daß der vi(m) schon deswegen häufiger genutzt wird,
weil er auf unixoiden Systemen so ziemlich immer vorhanden ist. Außerdem
gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von
einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.
Stallman himself.
Ein T. schrieb:> Außerdem> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.> Stallman himself.
wann hat er diese Dokumentation geschrieben? ;-)
Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.
VimScript. (war wohl doch nicht gut durchdacht)
spricht eher dafür schrieb:> Ein T. schrieb:>> Außerdem>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von>> einem der Autoren der GNU-Version, nämlich St. IGNUcius Richard M.>> Stallman himself.>> wann hat er diese Dokumentation geschrieben? ;-)
Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber
die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The
Extensible, Customizable, Self-Documenting Display Editor", stammt von
1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen
Jahren heißt es "GNU Emacs Reference Manual" [3].
Auch wenn mir nicht ganz klar ist, was Du mit Deiner Frage bezweckst, so
hoffe ich doch, sie hinreichend informativ beantwortet zu haben.
[1] https://dl.acm.org/doi/book/10.5555/888850
[2]
https://books.google.de/books/about/GNU_Emacs_Manual.html?id=v3QZAQAAIAAJ&redir_esc=y
[3] https://www.amazon.de/GNU-Emacs-24-5-Reference-Manual/dp/9888381954> Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.> VimScript. (war wohl doch nicht gut durchdacht)
Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal
wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die
Software eben auch mal umbauen, um die Anforderungen abdecken und die
neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und
Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine
Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die
Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht
gewesen, erscheint mir daher vollkommen verfehlt.
Jörg W. schrieb:> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich> ging's ja die ganze Zeit um vim vs. nano.
Nein, darum ging es nie. Es gab hier lediglich vim Fanboys, wie man dies
und das in nano löst. Es war am Ende also ein nano only Thread.
Nano schrieb:> Jörg W. schrieb:>> Das kommt davon, wenn die Leute den Thread verschlafen. Schließlich>> ging's ja die ganze Zeit um vim vs. nano.>> Nein, darum ging es nie. Es gab hier lediglich vim Fanboys *, wie man dies> und das in nano löst. Es war am Ende also ein nano only Thread.
Satz vergessen:
*die wissen wollten.
Ein T. schrieb:> und dann muß man die> Software eben auch mal umbauen
aber nicht die Programmiersprache. Lisp ist die beste Programmiersprache
der Welt und darum wird emacs da nie was ändern (müssen).
Und VimScript ist ein Ding, dass außer Vim keine Bedeutung hat und eine
komische Syntax verwenden. Und auch darum ist NeoVim besser: Dort wird
VimScript durch Lua ersetzt.
Emacs ist da wirklich konsequent und besser. Aber diese
Tastenkombinationen....
Ein T. schrieb:>> Aber das könnte auch für emacs sprechen. Vim ändert jetzt z.B.>> VimScript. (war wohl doch nicht gut durchdacht)>> Ach, weißt Du, im Lebenszyklus von so einer Software gibt es immer mal> wieder neue Anforderungen und neue Möglichkeiten -- und dann muß man die> Software eben auch mal umbauen, um die Anforderungen abdecken und die> neuen Möglichkeiten nutzen zu können. Pflege, Wartungen und> Erweiterungen gehören zum Lebenszyklus einer Software, und wenn eine> Software diese Dinge nicht mehr macht, stirbt sie bald. Deswegen die> Unterstellung zu äußern, die Software sei zuvor nicht richtig durchdacht> gewesen, erscheint mir daher vollkommen verfehlt.
Das Referenzbeispiel hier ist aber eher Elvis.
( http://elvis.the-little-red-haired-girl.org/ )
Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober
der viel besser auf Windows läuft, als neovim.
rbx schrieb:> Das Referenzbeispiel hier ist aber eher Elvis.>> ( http://elvis.the-little-red-haired-girl.org/ )>> Aufgrund des netten Hexeditors könnte man da zumindest mal schauen, ober> der viel besser auf Windows läuft, als neovim.
Unter Windows läuft der Elvis in der Version 2.2. Der ist von den
Features
auch heute noch top!
Mir gefällt auch der WinVi: http://www.winvi.de/de/scrnshts.html
Der hat auch einen Hex Editor eingebaut.
Beide werden leider seit über 10 Jahren nicht mehr weiterentwickelt.
Beide (genauso wie der Original vi) verstehen die hier
als Beispiele gezeigten Befehle nicht.
1
gg - geht nicht
2
da" - geht nicht
3
va" - geht nicht
vi ist also auch nicht vi.
Hier noch die Anzahl der Codezeilen. Da sind die Vim "Erweiterungen"
nicht dabei. Auch fehlen etliche externe Libs.
Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr
als 100k Zeilen aber irgendwas falsch.