Forum: PC Hard- und Software Vi Editor ausgestorben?


von Karl Otto II. (Gast)


Lesenswert?

Ein T. schrieb:
> spricht eher dafür schrieb:
>> Ein T. schrieb:
>>> Außerdem
>>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von
>>> einem der Autoren der GNU-Version, nämlich  St. IGNUcius Richard M.
>>> Stallman himself.
>>
>> wann hat er diese Dokumentation geschrieben? ;-)
>
> Der Titel hat sich im Laufe der Jahre immer mal wieder gewandelt, aber
> die früheste seiner Publikationen zum GNU Emacs, Titel: "EMACS: The
> Extensible, Customizable, Self-Documenting Display Editor", stammt von
> 1979 [1]. 1987 hieß das dann schon "GNU Emacs Manual" [2], seit einigen
> Jahren heißt es "GNU Emacs Reference Manual" [3].

Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL 
erfunden hat.

rbx schrieb:
> Das Referenzbeispiel hier ist aber eher Elvis.
>
> ( http://elvis.the-little-red-haired-girl.org/ )

Sehr schön. Elvis war schon Anfang der 90er für mich ein abschreckendes 
Beispiel für einen Editor unter Linux. Habe ihn dann trotzdem 
gelegentlich genutzt weil immer vorhanden. Später habe ich ihn dann nie 
mehr gefunden. Auch nicht die Website. Deshalb danke für die Verlinkung.

udok schrieb:
> Hier noch die Anzahl der Codezeilen.  Da sind die Vim "Erweiterungen"
> nicht dabei.  Auch fehlen etliche externe Libs.
> Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr
> als 100k Zeilen aber irgendwas falsch.

Die neuste Version von vim ist auch schon ganz schön fett geworden.

von Norbert (Gast)


Lesenswert?

udok schrieb:
> Meiner bescheidenen Meinung nach macht ein Editor mit wesentlich mehr
> als 100k Zeilen aber irgendwas falsch.

Ich muss gestehen das ich mir noch nie die Anzahl der Zeilen Sourcecode 
angesehen habe um eine Pro/Contra Entscheidung zu treffen.
Ich fand's immer recht angenehm wenn der Editor mich einfach meine 
Arbeit machen ließ.

von Heinz (Gast)


Lesenswert?

Ein T. schrieb:
> Außerdem
> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von
> einem der Autoren der GNU-Version, nämlich  St. IGNUcius Richard M.
> Stallman himself.

Original-Dokus sind oft schwer verständlich und didaktisch eine halb- 
bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.

von rbx (Gast)


Lesenswert?

Heinz schrieb:
> Original-Dokus sind oft schwer verständlich und didaktisch eine halb-
> bis vollkatastrophe ;) Dazu kommt noch die Sprachbarriere.

und der Quellcode erst..

Stallmann meinte mal er hatte den Algoteil (der mit dem Totenkopf in der 
Originalquelle) noch viel eleganter bzw. smarter hinbekommen.

Man stelle sich den Emacs Assembler-Optimiert vor, mit allem was man da 
heute so hat, mit Profiler einsteigen, Algoschinken, Rip-Mode, SSE, AVX 
(por Reg (String drin) 20h)(Alternative, OR AH, 20h) viele 64 Bit 
Register, Cuda als Rechenhilfe (also sowas wie Excel - Ersatz bzw. der 
neue Emacs- "Excel-Mode") und dann auch noch "Cloud-Optimierung" mit 
richtig guten Leuten..

Ansonsten scheinen ja keine Dokumentation (etwa wie bei Grafikkarten 
oder bei ARM hier und da), nur teilweise Dokumentation oder erbärmliche 
Dokumentation recht beliebt zu sein.
Naja, wenn man das Know How hat und den Grips und eine gute 
Uniausbildung/UniBib auch noch, hat man zumindest einen 
Wettbewerbsvorteil.

Vimscript ohne populäre Schnittstelle hat zumindest den Vorteil, nicht 
gleich wie mit Java an die Wand fahren zu müssen, oder mit neovim 
gewissermaßen Skyrim heavily-modded zu spielen.

Der Cloud-Gedanke, bzw. das was Stallmann meint, ist ja so schlecht 
nicht, wenn man z.B. an die Automagie beim Start von Knoppix denkt, oder 
an den Emacs (der "Ersatzdesktop") bei Cygwin.
Bei Cygwin ist (oder war, keine Ahnung) auf jeden Fall der Emacs der 
beste Editor ;)
(da kann glaube ich auch kein WSL mithalten)

Bei Fedora Workstation beschäftigt mich auch die Frage, Vim oder Neovim? 
Viel fesselnder finde ich aber die Frage, wie Neovim in Windows 
compilieren?
Mit Watcom 32 Bit sollte das  schon mal (weitgehend) reibungslos gehen. 
Spannender wird es bei 64 Bit.
Wie weit kommt man mit Open Watcom V2?

Aber neovim als 16-Bit Variante wäre meiner Meinung nach auch nicht so 
verkehrt. Back to the roots - würde ich mal so sagen.
(das wäre dann z.B. Neovim für DOSBox)

(könnte man statt Lua den C-Script Support vom Tiny C Compiler benutzen. 
Aber ach, der ist ja auch so 32 Bit..)

Na, alles nicht so einfach.. 
https://stackoverflow.com/questions/3827370/h


Ein T. schrieb:
> rbx schrieb:
>> Suchmaschine spukt u.a. aus:
>
> In Deiner Suchmaschine spukt es? 8-O

Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken, 
hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so 
körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw. Das 
hat natürlich auch gewisse Vorteile, z.B. wenn man als Anrufer (wie ein 
echter Engel) bevorzugt wird in der ansonsten körperlich anwesenden 
Wartesschlange.

von udok (Gast)


Lesenswert?

Hier noch Infos zum Speicherverbrauch und zur Suche unter Windows 10.
Gemessen mit ProcessHacker.

Der gvim ist auch unter Windows ein guter Allrounder - wenn man ihn 
bedienen kann...

Interessanterweise ist auch der Notepad - über denn ja jeder lästert - 
vorne dabei.

Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze
100MByte File in den Speicher holt.  Bei der Suche kackt er aber ab.

Alle anderen sind abgeschlagen.

Wordpad und Word sind abgeschlagen, aber die konvertieren das Format 
intern um, und haben daher einen ordentlichen Nachteil.
1
Peak Speicherverbrauch beim Öffnen von 100 Megabyte File mit 10 Millionen
2
Zeilen (Zahlen von 000000000 - 009999999)
3
=> File Öffnen und Suchen des Strings 009999999, OS = Win 10
4
5
Editor              | Peak Speicher [MB] | CPU Cycle [1e9-Cycles] | Kommentar
6
==========================================================================
7
WinVi               |    4.5             |  22.9
8
gvim                |  149               |   6.5
9
Win10 Notepad       |  272               |   4.3
10
Notepad++           |  362               |  15.2
11
Notepad2            |  372               |  12.3
12
Visual Studio 2008  |  445               |  10.8
13
Visual Studio 2022  |  616               | 149.8
14
Wordpad             |  845               | 236.0
15
WinWord 2010        | 1230               | 579.0
16
Notepad3            |                    |            | Öffnet nicht
17
PsPad               |                    |            | Öffnet nicht
18
vi-Elvis            |                    |            | Öffnet nicht
19
==========================================================================

von Nano (Gast)


Lesenswert?

udok schrieb:
> Der WinVi ist der einzige Editor, der nicht so blöde ist und das ganze
> 100MByte File in den Speicher holt.  Bei der Suche kackt er aber ab.
>
> Alle anderen sind abgeschlagen.

Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am 
Speicherbedarf zu messen.
Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei 
WinVi, Speicher nicht nutzt obwohl er vorhanden ist.

Wichtig ist nur, dass er selbst für sich nicht viel braucht, also 
schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal 
etwas editieren" ist.

Ich hatte, wie bereits gesagt, noch nie die Notwendigkeit solche großen 
Dateien mit Texteditoren zu öffnen.
Was ich schonmal öffnen musste, war eine große Datendatei, für so etwas 
nutze ich aber einen Hexeditor und da sind drei Kriterien wichtig:

1. Kann der Hexeditor größere Dateien öffnen und bearbeiten als RAM 
vorhanden ist?
2. Nutzt er für die Bearbeitungsfunktionen das RAM oder lässt er es 
brach liegen.
3. Kann er auf solche in 1 beschriebenen Dateien auch Search and Replace 
anwenden ohne auszusteigen? Leider scheiterten da viele HexEditoren, die 
damit warben, unlimitiert große Dateien öffnen und bearbeiten zu können.
Die S&R Funktion ist wohl leider oft so implementiert, dass hier dann 
nicht an den Speicherbedarf gedacht wird. Vermutlich rührt das daher, 
dass im RAM zuerst eine Datentstruktur aller gefunden Matches aufgebaut 
wird und dann der Nutzer gefragt wird, was er mit diesen jeweils einzeln 
oder auf alle angewendet machen möchte. Und hier steigen viele 
Hexeditoren dann aus, weil kein RAM mehr vorhanden ist und die aber mehr 
brauchen um die Sucheinträge unterzubringen.

> Visual Studio 2008  |  445               |  10.8
> Visual Studio 2022  |  616               | 149.8

Wer eine 100 MiB große Quellcodedatei in eine IDE lädt, der macht etwas 
falsch.

von udok (Gast)


Lesenswert?

Nano schrieb:
> Ich halte es nicht für sinnvoll, die Editoren bezüglich der Nutzdaten am
> Speicherbedarf zu messen.
> Denn du siehst ja selbst, dass es auch Nachteile hat, wenn man wie bei
> WinVi, Speicher nicht nutzt obwohl er vorhanden ist.
>
> Wichtig ist nur, dass er selbst für sich nicht viel braucht, also
> schnell geladen ist, wenn die Anwendung eine im Sinne von "schnell mal
> etwas editieren" ist.

Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.
Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.
Startupzeit ist sicher ein weiteres wichtiges Kriterium.
Einfache intuitive Bedienung und Integration ins OS ist auch wichtig,
An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie 
gewöhnen. Schon interessant und frustrierend, das es nach >50 Jahren 
Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.

von Andreas H. (ahz)


Lesenswert?

udok schrieb:
> An die gvim eigenen Copy+Paste Tasten unter Windows werde ich mich nie
> gewöhnen.

Du kannst Dir die Tastaturbelegung doch beliebig umbasteln :)

Ich finde es eher nervig, dass die GVIM packager für Windows immer ein 
"Windowsuseraugliches" Keymapping aktivieren. Aber das kann man ja zum 
Glück auch wieder rausschmeissen ;)

/regards

von alex (Gast)


Lesenswert?

udok schrieb:
> Einfache intuitive Bedienung ist auch wichtig,

Da bist du aber bei vi und Derivaten davon absolut falsch ;)

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Ich benutze den vim in der Geschmacksrichtung "cream", das läuft auch 
unter wine. Für AVR-Assembler habe ich allerdings eine 
Syntax-highlighting-Datei im Web suchen müssen, die war nicht dabei. 
Schon von 2005, ist hier angehängt.
Aber Geany kann es auch, in letzter Zeit habe ich den Cream nicht mehr 
benutzt.

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Ich habe geany mit gedit verwechselt. Dort heißen die syntax-Dateien 
(xml) ".lang" und liegen unter 
/usr/share/gtksourceview->Version>/language-specs
Speziell AVR habe ich nicht, aber mit "asm.lang" sieht es schon 
einigermaßen korrekt aus.
Mit cream ist die Druckereinstellung etwas umständlich. Ich habe es für 
den PDF-Druck in mir angenehme Form eingerichtet.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Karl Otto II. schrieb:
> Das unterliegt ja noch nicht mal der GPL. Obwohl Stallmann die GPL
> erfunden hat.

Das stimmt, die Dokumentationen [1] unterliegen der GNU Free 
Documentation License [2]. Die GFDL ist die Lizenz des GNU-Projekts für 
Dokumentationen.

Irgendwie beschleicht mich das Gefühl, daß Du mir etwas sagen möchtest. 
Aber leider komme ich nicht darauf, was das sein könnte.


[1] https://www.gnu.org/software/emacs/manual/
[2] https://www.gnu.org/licenses/fdl-1.3.de.html

von Ein T. (ein_typ)


Lesenswert?

Heinz schrieb:
> Ein T. schrieb:
>> Außerdem
>> gibt es für den Emacs perfekte Dokumentationen nicht zuletzt auch von
>> einem der Autoren der GNU-Version, nämlich  St. IGNUcius Richard M.
>> Stallman himself.
>
> Original-Dokus sind oft schwer verständlich und didaktisch eine halb-
> bis vollkatastrophe ;)

Das sehe ich nicht so.

> Dazu kommt noch die Sprachbarriere.

Englisch kann man lernen, das ist gar nicht so schwierig -- und wer 
Software oder Elektronik entwickeln will, kommt darum ohnehin nicht 
herum. Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für 
die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus, 
da ist bestimmt auch etwas für Dich dabei.

von Ein T. (ein_typ)


Lesenswert?

rbx schrieb:
> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,
> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so
> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.

Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit 
mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche 
Gesellschaft. ;-)

von timol (Gast)


Lesenswert?

Ein T. schrieb:
> Obendrein gibt die Suchmaschine meines geringsten Mißtrauens für
> die Suchbegriffe "emacs dokumentation deutsch" über 950.000 Treffer aus,
> da ist bestimmt auch etwas für Dich dabei.

Da habe ich schon vor über 20 Jahren gesucht und nur von der Fernuni 
Hagen etwas brauchbares zu Emacs gefunden. Aber etwas, das Inhaltlich im 
Umfang darüber hinausgeht, dann leider nicht. Habe dann mit Emacs sogar 
meine Diplomarbeit geschrieben. Heute benutze ich vi und emacs nur mal 
um einen Wert in einer Konfigurationsdatei zu ändern, dazu reichen dann 
meine Kenntnisse auch. Ansonsten benutze ich heute Notepad++ und VS 
Code. Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir 
meine Zeit zu schade. Deren Zeit ist einfach abgelaufen.  Ein Editor ist 
für mich Werkzeug und nicht Selbstzweck.

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


Lesenswert?

timol schrieb:
> Um mich in diese Uralt-Editoren richtig einzuarbeiten, ist mir meine
> Zeit zu schade.

Um mit VScode effizient zu arbeiten, musst du dich genauso einarbeiten. 
Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten 
("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal 
(mindestens die unterschiedliche Modi muss man kennen).

Ich staune da immer wieder über meine Kollegen, weil ich mir viele der 
nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs 
effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in 
Ordnung so.

von timol (Gast)


Lesenswert?

Jörg W. schrieb:
> Ich staune da immer wieder über meine Kollegen, weil ich mir viele der
> nötigen VScode-Tastenkürzel nicht merken kann. Daher bin ich mit Emacs
> effizienter, er mit VScode (und andere mit Vim). Ist doch völlig in
> Ordnung so.

Klar ist es völlig in Ordnung. Mir kann es doch egal sein, womit sich 
hier wer quälen will. Ich kenne nur keinen Entwickler, der mit vim 
programmiert, aber ich weiß natürlich dass es welche gibt. In den 
meisten Firmen gibt es auch sehr strenge Vorgaben womit entwickelt wird, 
wie dokumentiert wird und wie der Code auszusehen hat. Oft hat da sogar 
auch der Kunde noch mitzureden. Gut, in irgendwelchen 3-Mann-Klitschen 
ist das sicher etwas anders.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jörg W. schrieb:
> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten
> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal
> (mindestens die unterschiedliche Modi muss man kennen).

Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man
direkt im Insert-Mode, und es können die von Windows bekannten
Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S
(save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur
Verfügung.

Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann
sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.

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


Lesenswert?

timol schrieb:
> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.

Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was 
du hier gerade heraus hängen lässt.

von Kiffer (Gast)


Lesenswert?

udok schrieb:
. Schon interessant und frustrierend, das es nach >50 Jahren
> Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.

Das könnte vielleicht auch daran liegen, dass diese Wünsche ein sehr 
bewegliches Ziel sind. Der Eine will mal schnell eine Zeile in einer 
Konfigdatei ändern, ein anderer hingegen grosse Datendateien editieren, 
wieder einer möchte das Gesamtkunstwerk grafisch, aberauch über eine 
SSH-Verbindung nutzen, und jeder davon hätte es gerne möglichst 
komfortabel. Also im eigenen Sinne und für alle möglichen Definitionen 
des Wortes komfortabel, versteht sich.

Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast), 
für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die 
Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig 
und/oder unwichtig erklärt.

von Ein T. (ein_typ)


Lesenswert?

udok schrieb:
> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.
> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.

hüstel Äh, bitte entschuldige... mit einem Editor? 8-O

von mh (Gast)


Lesenswert?

Ein T. schrieb:
> udok schrieb:
>> Schon klar, dass der Speichertest nur eines unter vielen Kriterien ist.
>> Wobei ich hier schon halbwegs regelmässig log Dateien > 100 MB aufmache.
>
> hüstel Äh, bitte entschuldige... mit einem Editor? 8-O

räusper Er meint bestimmt einen Hexeditor ;-)

von Zeno (Gast)


Lesenswert?

alex schrieb:
> Da bist du aber bei vi und Derivaten davon absolut falsch ;)

Nö die Fanboys finden das Teil super und geilen sich seit hunderten von 
Beiträgen daran auf. Da müssen dann schon auch mal (Text-) Dateien mit 
100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig 
derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch 
Datendateien mit einem Editor bearbeiten muß, der macht was falsch. Aber 
gut das Lieblingsspielzeug ist ja so geil, da ist das völlig wurscht ob 
man am Ende der Datei noch weis was in der 3. Zeile stand.

Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen 
auch vi, vim oder wie sie alle heißen mögen. Damit wird die Arbeit 
erledigt und gut ist es. Mir würde es im Traum nicht einfallen so ein 
Gewese um dieses Thema zu machen. Ein Editor ist ein Werkzeug, das für 
meine Zwecke funktionieren muß - mehr nicht.

von mh (Gast)


Lesenswert?

Zeno schrieb:
> Da müssen dann schon auch mal (Text-) Dateien mit
> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig
> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch
> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.

Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere 
100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format 
enthält?

Was sind die Alternativen? Die Software, die die Daten erzeugt neu 
entwickeln? Einen anderen Job suchen, der nicht mit solchen Dateien zu 
tun hat?

Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen 
Dateien oder dem Editor meiner Wahl. Meine Kollgen haben keine Probleme 
mit diesen Dateien oder dem Editor meiner Wahl. Mein Chef hat keine 
Probleme mit diesen Dateien und dem Editor meiner Wahl. Unsere Kunden 
haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl. Nur 
du und nano haben Probleme damit. Und ihr wisst nichteinmal was das für 
Dateien sind und was damit gemacht werden muss.

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


Lesenswert?

Zeno schrieb:
> Mir würde es im Traum nicht einfallen so ein Gewese um dieses Thema zu
> machen.

Warum machst du es denn dann?

von Le X. (lex_91)


Lesenswert?

Kiffer schrieb:
> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),
> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die
> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig
> und/oder unwichtig erklärt.

Nein, so war das nicht.
Nano hat eingangs klargestellt für was er welchen Editor verwendet und 
warum.
Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der 
vim zwar unbestreitbar besser performt, die für ihn aber nicht 
relevant seien.

Das ändert freilich nichts daran dass er sich in den darauf folgenden 
technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war, 
überhaupt auf die Beispiele einzugehen.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Le X. schrieb:
> Sein Fehler war, überhaupt auf die Beispiele einzugehen.

Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler 
bezeichnen. ;-) Wofür sollte er überhaupt gut gewesen sein? Irgendein 
ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen, 
scheint er nicht zu haben, was man schon an seinem Abqualifzieren 
derjenigen als "Fanboys" gut erkennen kann.

von Yalu X. (yalu) (Moderator)


Lesenswert?

udok schrieb:
> Schon interessant und frustrierend, das es nach >50 Jahren
> Informatik noch immer keinen Editor gibt, der alle Wünsche erfüllt.

Auch nach über 100 Jahren Automobilbau gibt es noch kein Automobil, das
alle Wünsche nach Fahrleistung, Transportkapazität, Wirtschaftlichkeit,
Umweltfreundlichkeit und Protzigkeit erfüllt.

Immerhin scheint bei den Editoren jeder Diskussionsteilnehmer hier einen
gefunden zu haben, der zumindest seine persönlichen Erwartungen erfüllt.
Somit besteht womöglich gar kein Bedarf an der eierlegenden Wollmilchsau
(falls diese überhaupt realisierbar ist).

von Petr T. (ptr)


Lesenswert?

Nano schrieb:
> Petr T. schrieb:
>> Openbsd schrieb:
>>> Arbeitet von euch noch jemand mit dem vi? Wenn ja, warum? Was sind die
>>> ultimativen Vorzuege dieses Editors?
>>
>> Selbstverständlich!
>>
>> Warum? Weil es am effektivsten ist. In welchem anderen Editor kannst du
>> z.B. "5 Zeilen löschen" mit nur drei Tasten (5dd). Usw.
>
> Mit JEDEM mit Mausbedienung!
>
> Mauscursor an das Zeilenende fahren, 1 mal links Maustaste klicken, dann
> 5 Zeilen runterziehen und die Entfernen Taste drücken. Fertig!
>
> Insgesamt also 2 Tasten, nicht 3.


Ja, und das ganze dauert 10x so lange und die Chance, dass man mit der 
Maus nicht ganz genau ist und evtl. mehr oder weniger löscht, ist 
ziemlich hoch.

Das ist weder effizient noch ergonomisch.

Alleine die Zeit, die ich dazu brauche meine Hand von der Maus auf die 
Tastatur zu wechseln ist mindest doppelt so viel wie "5dd" zu drücken.

>> Ich bin aber im Allgemeinen ein Freund vom Lernen, das es das Gehirn
>> gesund hält...
>
> Klar und erkennst dann nicht einmal die Effizienz und Vorzüge der Maus.

Meine Güte, so ein Schwachsinn!

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


Lesenswert?

Petr T. schrieb:
> Meine Güte, so ein Schwachsinn!

Eine weitere Diskussion auf diesem Niveau erübrigt sich.

von Kiffer (Gast)


Lesenswert?

Le X. schrieb:
> Kiffer schrieb:
>> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),
>> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die
>> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig
>> und/oder unwichtig erklärt.
>
> Nein, so war das nicht.

Aber ja doch, genau so war das. Zu Anfang ist er gleich mal mit einer 
überheblichen Provokation in diesen Thread eingestiegen 
(Beitrag "Re: Vi Editor ausgestorben?") und dann 
hat er das passende Echo nicht vertragen und die Vollmimi gegeben. Und 
im Laufe dieser Entwicklung, die er mit seiner viel zu großen Klappe 
selbst bewußt und gezielt provoziert hat, hat er mehrfach die Contenance 
verloren, die Aufgaben und Wünsche anderer entweder einfach ignoriert 
oder für unwichtig erklärt, wieder andere wurden von ihm herablassend 
behandelt, als Straftäter diffamiert und als drogensüchtig bezeichnet. 
Auf dem Höhepunkt seines Auftritts, der vom ersten Beitrag an nichts als 
eine gezielte, bewußte und gewollte, maximal herablassende, arrogente 
und besserwisserische Peovokation war, hat Mr. Mimimi sich soger 
entblödet, nach den Moderatoren zu rufen, als ob die nicht schon genug 
mit den anderen ungezogenen Kleinkindern zu tun hätten. Chill mal Deine 
Base, LeX.

von Kiffer (Gast)


Lesenswert?

Jörg W. schrieb:
> Irgendein
> ernsthaftes Interesse an denjenigen, die nach wie vor vi(m) benutzen,
> scheint er nicht zu haben, was man schon an seinem Abqualifzieren
> derjenigen als "Fanboys" gut erkennen kann.

Das Wort "Fanboy" hat Nanos (wieder einmal, honi soit qui mal y pense) 
Beschützer LeX in diese Diskussion eingebracht. Sein Schützling hat das 
dann nur übernommen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Kiffer schrieb:
> Chill mal Deine > Base, LeX.

Chillt am besten alle mal eure Base und kommt wieder zum Thema zurück.

von Alf (Gast)


Lesenswert?

Der Kiffer hier sollte mal weniger Drogen nehmen. Na immerhin passt der 
Name.

von timol (Gast)


Lesenswert?

Jörg W. schrieb:
> timol schrieb:
>> Gut, in irgendwelchen 3-Mann-Klitschen ist das sicher etwas anders.
>
> Ich hoffe, es gibt Gebiete, von denen du mehr Ahnung hast als das, was
> du hier gerade heraus hängen lässt.

Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten 
mit nachvollziehbaren Argumenten die Welt erklärt, hier haben. So sind 
die Threads hier im Forum gleich unterhaltsamer. Aber ein Mod kann sich 
hier ja aufführen wie ein A...

von Zeno (Gast)


Lesenswert?

mh schrieb:
> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere
> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format
> enthält?
Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei 
entsteht.

Eine Datei mit Sourcecode, egal welche Programmiersprache wird wohl kaum 
so groß werden. Wenn man wirklich soviel Sourcecode unterbringen muß, 
dann teilt man das Projekt in halbwegs verdauliche Häppchen auf. bei 
meinem größten Projekt hatte eine Sourcecodedatei, die Hauptdatei des 
Projektes (insgesamt ca. 800 Sourcecodefiles), knapp 18000 Textzeilen 
(760kB) und das war eigentlich schon zu viel. Das Teil ist über 20 Jahre 
gewachsen, weil immer wieder neue Anforderungen dazu gekommen sind. 
Heute würde ich das anders machen.

Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß. 
Bei dem erwähnten Programm handelt es sich um eine SW zum Auswerten von 
Messreihen. Die Daten liegen als ASCII Dateien vor sind aber selten 
größer als 10kB. Ausnahme sind Unixdatenfiles die meist als 
Wiederholungsprotokolle vorlagen, also noch zusätzlichen Fülltext 
enthielten. Die von mir entwicklte SW hat die Daten auch wieder im 
ASCII-Format gespeichert - Dateigröße ca. 10kB, davon aber meist so 10 
Stück pro Messreihe, also isgesamt 100kB. Selbst bei sehr umfänglichen 
Messreihen war das Gesamtdatenvolumen nicht größer als 1MB, also 1% von 
Deinen 100MB - aufgeteilt auf mehrere Dateien. Mit anderen Worten wer so 
große Datendateien enstehen läßt macht was falsch. Solche Riesendateien 
kann kein Mensch mehr überblicken, geschweige denn vernünftig auswerten. 
Wenn derartige Datenmengen anfallen dann heißt das Stichwort Datenbank, 
die bringt dann auch die passenden Tools mit um die Daten auszuwerten.

Für Logfiles gilt im Prinzip das Gleiche wie für die Daten. Da sollte 
man als Programmierer dafür sorgen, das die nicht zu groß werden. Ich 
habe deshalb bei meiner Software die Logfiles auf eine Maximalgröße von 
2MB begrenzt. Wenn ein File diese Größe erreicht hat wurde der Name um 
das aktuelle Datum + Uhrzeit egänzt, dann weg gesichert und ein neues 
Logfile begonnen. Selbst dieses 2MB File ließ sich schon schlecht 
auswerten - einfach zu groß und unübersichtlich. Abgesehen davon würde 
ich ein Logfile auch nicht mit einem Editor öffnen, da gibt es in der 
GUI Viewer bzw. im Shellfenster cat, more und bei Bedarf grep.


Und ja ich hatte auch schon größere Textdateien, aber 100MB sind mir in 
30 Berufsjahren nie vor gekommen. Das Beispiel ist einfach nur an den 
Haaren herbei gezogen, um zu zeigen das der vi, vim etc. das Geilste 
ever ist. Um das eigentliche Thema geht es doch schon lang nicht mehr.

von Zeno (Gast)


Lesenswert?

timol schrieb:
> Aber ein Mod kann sich
> hier ja aufführen wie ein A...
Das tut der Jörg eigentlich nicht - auch wenn ich nicht generell seine 
Statements teile.
Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare 
halt ab und an entsprechend aus. Man muß ja auch nicht alle Statements 
von Jörg kommentieren.

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


Lesenswert?

timol schrieb:
> Wie gut, dass wir dich, der immer alles besser weiß und anderen Leuten
> mit nachvollziehbaren Argumenten die Welt erklärt, hier haben.

Argumente bringst du ja auch keine, nur Behauptungen. Warum erwartest du 
dann von anderen Argumente? Du behauptest, dass andere "sich quälen", du 
definierst, wer wo wem was vorschreibt und dass das dann halt so sei.

Möglicherweise habe ich schon ein paar "Klitschen" (das scheint dein 
Begriff für alles das zu sein, was du nicht kennst) mehr gesehen – 
zwischen 5 und 50000+ Mitarbeitern war da vieles dabei.

Zeno schrieb:
> Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei
> entsteht.

Tja, und wenn andere die Datei für ihn in der Form erzeugen? Gehst du zu 
denen hin und erzählst ihnen, dass sie da was falsch machen?

Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien 
herum editieren würde – aber wenn solche Dateien halt irgendwo entstehen 
und man auch mal drin editieren muss (oder sie zumindest ansehen, was 
drin suchen etc.), dann sollte es ein Tool geben, mit dem man das machen 
kann. Das muss ja auch nicht notwendigerweise das gleiche sein wie das, 
mit dem man seine täglichen Programmieraufgaben erledigt – es soll Leute 
geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das 
Gegenteil von "Fanboys".

von Le X. (lex_91)


Lesenswert?

Zeno schrieb:
> Datenfiles, von Datenbanken mal abgesehen, werden auch nicht so groß.

Veto.
Zum Beispiel traces eines beliebigen Bus-Systems sind wesentlich größer.
Die werden zwar meist mit dedizierter SW geöffnet, trotzdem kam es schon 
vor dass ich mit Traces mit einem Editor ansehen musste.

Aber es stimmt schon, von der Fähigkeit, beliebig große Dateien öffnen 
zu können würde ich jetzt nicht die Wahl meines Standard-Editors 
abhängig machen. Dafür kommt dieser usecase (bei mir) zu selten vor.

von Mombert H. (mh_mh)


Lesenswert?

Zeno schrieb:
> mh schrieb:
>> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere
>> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format
>> enthält?
> Du machst genau schon dann was falsch, wenn so eine große (Text-) Datei
> entsteht.
Natürlich hast du den Rest meines Beitrags nicht zitiert ;-)

Du bist also der Meinung, dass ich die XXk€ Software, die mein 
Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du, 
wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der 
Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".

von Kiffer (Gast)


Lesenswert?

Mombert H. schrieb:
> Du bist also der Meinung, dass ich die XXk€ Software, die mein
> Arbeitgeber gekauft hat nochmal komplett neu entwickle? Was glaubst du,
> wird passieren, wenn ich das meinem Arbeitgeber vorschlage, mit der
> Begründung "Nano und Zeno sagen, dass ich etwas falsch mache".

Also wenn ich Dein Arbeitgeber wäre, würde ich sagen "na klar, wenn 
diese ausgewiesenen Experten das sagen, müssen wir das sofort machen! 
Lass uns nochmal XXk€ ausgeben damit die beiden uns eine neue Software 
bauen, die kann nur besser sein!"

von Nano (Gast)


Lesenswert?

Ein T. schrieb:
> rbx schrieb:
>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,
>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so
>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.
>
> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit
> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche
> Gesellschaft. ;-)

Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln 
könnten?

von Nano (Gast)


Lesenswert?

Yalu X. schrieb:
> Jörg W. schrieb:
>> Für simples Editieren braucht man sich auch in Emacs nicht einzuarbeiten
>> ("Speichern" und "Beenden" geht auch über Menüs), in Vim minimal
>> (mindestens die unterschiedliche Modi muss man kennen).
>
> Man kann Vim auch im Easy-Mode (als evim) starten. Dann landet man
> direkt im Insert-Mode, und es können die von Windows bekannten
> Tastenkürzel wie ^C (copy), ^X (cut), ^V (paste), ^F (find) und ^S
> (save) verwendet werden. Zusätzlich stehen natürlich auch die Menüs zur
> Verfügung.
>
> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann
> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.

Das würde ich nicht sagen.
Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über 
das Menü einstellbar.

Mit Vim im Easy-Mode und den von Windows bekannten Tastenkürzel wie ^C 
(copy), ^X (cut), ^V (paste), ^F (find) und ^S (save) hat man noch lange 
keinen Zeilenumbruch das Kodierungsschema eingestellt.

Sollte man hier den Vim im Eays-Mode mit leistungsfähigeren Editoren 
vergleichen, die ihre Einstellungen über Menüs erlauben, dann geht hier 
noch weniger.

Der Easy-Mode ahmt also zwar bekannte Tastaturkürzel nach, aber er macht 
Vim dadurch noch lange nicht zu einem intuitiv benutzbaren Editor.

Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren 
feststellen konnte, kein ESC :q! um vim zu verlassen.
Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt.
Das einzige was ging war ALT+F4, aber das nur, weil das die 
Tastenbelegung für KDE zum Schließen von Anwendungen ist und die Konsole 
daher nachfragte, ob sie mitsamt allem, was darin läuft, geschlossen 
werden soll.

von Nano (Gast)


Lesenswert?

Nano schrieb:
> Auch ein STRG+Q oder ALT+Q oder STRG-

Meinte STRG+C

> brachte hier keinen Erfolgt.


Kiffer schrieb:>
> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),
> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die
> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig
> und/oder unwichtig erklärt.

Ich habe oben geschrieben, dass ich keine großen in der Regel 
Binärdateien mit einem Texteditor bearbeite und dafür einen Hexeditor 
verwende.
Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100 
MiB große Quellcode Datei in einer IDE öffnen will.
Tipp:
Es macht Sinn, solche großen Quellcodedateien in mehrere kleine 
aufzuteilen.
Bei so einer großen Datenmenge kann man sogar überlegen, ob man nicht 
vielleicht auch gleich noch eine Bibliothek baut und die dann einbindet.

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


Lesenswert?

Nano schrieb:
> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über
> das Menü einstellbar.

Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben 
(die berühmte Konfig-Datei).

Selbst im Emacs benutze ich die entsprechende Funktion sehr selten, 
obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als 
auch Menüs).

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


Lesenswert?

Nano schrieb:
> Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100
> MiB große Quellcode Datei in einer IDE öffnen will.

Es ging allerdings nicht um Quellcode, sondern um irgendwelchen Krempel, 
der in Textform vorliegt (daher keinen Hex-Editor braucht) und den 
irgendein Programm außerhalb des Einflussbereichs desjenigen produziert, 
der dann die Daten trotzdem gelegentlich ansehen und anfassen muss. 
Warum, weshalb und wieso die Daten genau so entstehen, muss man nicht 
diskutieren, wenn man darauf eh keinen Einfluss hat. Sie sind dann 
einfach da.

Dass hier keiner 100 MB großen Quellcode in eine einzige Datei stopft, 
bedarf wohl keiner großen Diskussion.

von udok (Gast)


Lesenswert?

Nano schrieb:
> Und ich habe geschrieben, dass man etwas falsch macht, wenn man eine 100
> MiB große Quellcode Datei in einer IDE öffnen will.
> Tipp:
> Es macht Sinn, solche großen Quellcodedateien in mehrere kleine
> aufzuteilen.

Ich schreibe alle relevanten Infos mit printf ins Log,
da sind bei 1000 Messages / Sekunde * 50 Bytes 30 MB in 10 Minuten 
erreicht...
Das ist dank SSD kein Performanceproblem.
Glaub mir, das willst du dir mit keinem Hex Editor anschauen.

von Nano (Gast)


Lesenswert?

Zeno schrieb:
> alex schrieb:
>> Da bist du aber bei vi und Derivaten davon absolut falsch ;)
>
> Nö die Fanboys finden das Teil super und geilen sich seit hunderten von
> Beiträgen daran auf.

Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann 
aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige 
mich sogar persönlich angreifen, wie man oben sehen konnte.

Der Grund ist einfach:
Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also 
weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann 
ist das natürlich besonders übel für die Fanboys, wenn ich deren vim 
nicht nutze.

Bei einem IT Laien wäre das nämlich nicht so wichtig oder irrelevant, 
denn ein Laie kennt sich nicht aus, daher haben dessen Aussagen kein 
Gewicht, da ich keiner bin, ist das in meinem Fall anders. Dafür werde 
ich angegriffen, das ist der Grund.

@vim fanboys

:p


> Da müssen dann schon auch mal (Text-) Dateien mit
> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig
> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch
> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.

++

So sehe ich das auch.


> Jeder normale Nutzer benutzt einfach den Editor seiner Wahl, meinetwegen
> auch vi, vim oder wie sie alle heißen mögen.

Ganz deiner Meinung.

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


Lesenswert?

Nano schrieb:
> warum die Fanboys

Die wissen, dass du dich allein durch die bloße wiederholte Verwendung 
dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen 
abzustempeln ist ein Ausdruck fehlender Argumente.

von Nano (Gast)


Lesenswert?

mh schrieb:
> Zeno schrieb:
>> Da müssen dann schon auch mal (Text-) Dateien mit
>> 100MB und 10Millionen Zeilen her halten. Sorry Leute wer ständig
>> derartige Riesendateien, egal ob Logdateien, Quellcodedateien oder auch
>> Datendateien mit einem Editor bearbeiten muß, der macht was falsch.
>
> Was genau mache ich falsch? Womit öffne ich eine Datei, die mehrere
> 100MB oder sogar GB groß ist und Daten in einem menschenlesbaren Format
> enthält?

Ich versuche es mal:

Ihr habt oben etwas von Messdaten geschrieben.

Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen, 
dann sollte man über ein Binärformat und ein Programm, über das man auf 
diese zugreift und das diese aufbereitet, nachdenken.
Grund:
Ein Binärformat spart viel mehr Platz und ist für einen Computer viel 
besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm 
schreibt, gleich noch daran denken, die Daten noch zu komprimieren.

Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf, 
dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier 
zu großen Verlusten führen.
Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei 
schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust 
mehr Sicherheit und das erlaubt dann auch die alten Dateien zu 
komprimieren und so Speicherplatz zu sparen.

Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei 
anzulegen.

> Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen
> Dateien oder dem Editor meiner Wahl.

Bis mal der Rechner eine Störung hat.

> Mein Chef hat keine
> Probleme mit diesen Dateien und dem Editor meiner Wahl.

Dann weise ihn mal auf die Punkte hin, die ich gerade genannt habe und 
dann beobachte ob sich an seiner Einstellung etwas ändert.

> Unsere Kunden
> haben keine Probleme mit diesen Dateien und dem Editor meiner Wahl.

Gleicher Fall wie beim Chef.


> Nur
> du und nano haben Probleme damit.

Wir haben ja auch Ahnung und würde das so deswegen auch nicht machen. 
Die Begründung warum wir das anders machen würde, habe ich hier gerade 
geschrieben. Es liegt jetzt an dir, daraus zu lernen und die 
Verbesserungen zu übernehmen und umzusetzen und dann brauchst du auch 
diese großen Dateien nicht mehr.

> Und ihr wisst nichteinmal was das für
> Dateien sind und was damit gemacht werden muss.

Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im 
einfachsten Fall ASCII Text.

von udok (Gast)


Lesenswert?

Nano schrieb:
> Der Grund ist einfach:
> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann
> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim
> nicht nutze.

Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du 
dich
aufregst, über was auch immer... dazu gehören aber mindestens 2.

von udok (Gast)


Lesenswert?

Nano schrieb:
> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel
> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm
> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.

Ist alles richtig, aber dann muss ich erst ein Programm schreiben,
das mir die Daten in ASCII umwandelt.  Bringt also nix ausser Arbeit.
Wir leben auch nicht mehr in den 90'ern.  Jedes Handy Spiel installiert
heute 100 MB...

von Nano (Gast)


Lesenswert?

Le X. schrieb:
> Kiffer schrieb:
>> Das sieht man in diesem Thread gut an den Ausführungen von Nano (Gast),
>> für den nur seine eigenen Aufgaben und Bedürfnisse zählen und der die
>> Aufgaben und Bedürfnisse anderer Postender für irrelevant, unnötig
>> und/oder unwichtig erklärt.
>
> Nein, so war das nicht.
> Nano hat eingangs klargestellt für was er welchen Editor verwendet und
> warum.
> Erst daraufhin wurden ihm seitens vim-User Beispiele konstruiert wo der
> vim zwar unbestreitbar besser performt, die für ihn aber nicht
> relevant seien.

So weit okay.


> Das ändert freilich nichts daran dass er sich in den darauf folgenden
> technischen Diskussionen nicht mit Ruhm bekleckert hat. Sein Fehler war,
> überhaupt auf die Beispiele einzugehen.

Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich 
8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht 
aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in 
MB gedacht habe.

von udok (Gast)


Lesenswert?

Nano schrieb:
> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich
> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht
> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in
> MB gedacht habe.

Doch :-)  Du machst den Fehler, auf die Argumente überhaupt einzugehen.
Und solage du (oder ich) das machen, geht der Thread weiter.  Macht aber 
auch nix, im Fernsehen spielts ja nix gescheites.

von Nano (Gast)


Lesenswert?

Jörg W. schrieb:
> Le X. schrieb:
>> Sein Fehler war, überhaupt auf die Beispiele einzugehen.
>
> Naja, man könnte das Eröffnen des ganzen Threads als einen Fehler
> bezeichnen. ;-)

Ich habe diesen Thread nicht eröffnet. Der ist nicht von mir. Er wurde 
von dem Nutzer OpenBSD am  06.01.2020 16:38 erstellt.

Ich habe auf die Frage des TS erstmals am 8.1.2020 geantwortet.

von vim (Gast)


Lesenswert?

Nano schrieb:
> Der Grund ist einfach:
> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
> weitaus mehr Gewicht zu

Du solltest an Deiner Selbstwahrnehmung arbeiten.

Niemand hier dürfte Dich für einen Profi halten. Eher für einen 
Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen 
zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne 
Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.

Nachweise Deiner angeblichen Kompetenz willst Du ja leider nicht 
liefern:

Beitrag "Vielzahl an IDE, Framworks, usw."

von Nano (Gast)


Lesenswert?

udok schrieb:
> Nano schrieb:
>> Ich habe da keinen Fehler gemacht. Bis auf den einen Tippfehler, wo ich
>> 8 GB schreiben wollte und dann 8 MB geschrieben habe, weil ich nicht
>> aufgepasst habe und in den letzten Tagen viel mit DOS gearbeitet und in
>> MB gedacht habe.
>
> Doch :-)  Du machst den Fehler, auf die Argumente überhaupt einzugehen.

Okay, die Zeit hätte ich mir natürlich sparen können, so hast du 
natürlich recht.
Aber einen technischen Fehler habe ich nicht gemacht, außer dem mit den 
8 MB anstatt 8 GB.

> Und solage du (oder ich) das machen, geht der Thread weiter.  Macht aber
> auch nix, im Fernsehen spielts ja nix gescheites.

Das ist wahr.

von Nano (Gast)


Lesenswert?

Kiffer schrieb:
> ...viel Unsinn...

Erstens:
Du hast dich im Thread verirrt.

Zweitens:
Deine Behauptungen und Anschuldigungen hier bezüglich dem anderen Thread 
sind nicht korrekt.

Bist du vielleicht der Straftäter aus dem anderen Thread?
Ein Mod könnte und sollte das mal überprüfen, das würde mich 
interessieren.

von Norbert (Gast)


Lesenswert?

vim schrieb:
> Nano schrieb:
>> Der Grund ist einfach:
>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
>> weitaus mehr Gewicht zu
>
> Du solltest an Deiner Selbstwahrnehmung arbeiten.
>
> Niemand hier dürfte Dich für einen Profi halten. Eher für einen
> Informatik-Erstsemester, der glaubt, die Weisheit mit Löffeln gegessen
> zu haben. Deine Beitragsbewertungen sprechen für sich, -13 ohne
> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.

Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten.
Und was alle anderen außer ihm falsch machen.
Und was er viel besser könnte wenn man ihn nur ließe.
Er erklärt uns wie groß Dateien werden dürfen.
Und das er noch nie Größere gebraucht oder gesehen hat.
Er erklärt uns das Binärformate bei größeren Dateien besser sind.

Wir alle sollten besser auf ihn hören! ;-)

von Nano (Gast)


Lesenswert?

Jörg W. schrieb:
> Nano schrieb:
>> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über
>> das Menü einstellbar.
>
> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben
> (die berühmte Konfig-Datei).

Nicht zwingend. Früher musste man unter Windows die 
Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien, 
die unter Unix mit einem LF Codierung für den Zeilenumbruch 
abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte.

Und README Dateien lesen, das gehört meiner Meinung nach noch zu den 
administrativen Aufgaben.

Heute in Windows 10 kann Notepad glücklicherweise mit diesen 
Zeilenendencodierungen umgehen, aber früher war das nicht so.

Und beim Kodierungsschema ist es nicht viel anderes.
Vieles kam aus DOS Zeiten mit z.B. Codetabelle 430, dann musste man das 
entsprechend umstellen können.


> Selbst im Emacs benutze ich die entsprechende Funktion sehr selten,
> obwohl ich weiß, wie man sie erreicht (geht sowohl über Tastenkürzel als
> auch Menüs).

Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3 
ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte, 
welcher Editor sich für mein DOS Projekt am besten eignet.
Emacs hat beim ersten Start irgendwelche Daten aufbereitet und eine 
Ewigkeit dafür gebraucht. Danach haben die Starts auch sehr lange 
gedauert.
Ich habe ihn daher gelöscht. Aber wenn du willst, dann kannst du dir das 
gerne mal unter FreeDOS ansehen.
Die Emacs Version darauf ist schon ein paar Jahre alt.

von Nano (Gast)


Lesenswert?

Jörg W. schrieb:
> Nano schrieb:
>> warum die Fanboys
>
> Die wissen, dass du dich allein durch die bloße wiederholte Verwendung
> dieses Begriffs hinreichend disqualifizierst. Leute mit Begriffen
> abzustempeln ist ein Ausdruck fehlender Argumente.

Oh, mir ging es da jetzt nicht um die normalen Vim Nutzern, sondern 
tatsächlich um die aggressive Gruppe unter den Vim Nutzern die hier 
ausrastet, wenn man vim nicht nutzt. Der Einfachheit halber übernehme 
ich hier lediglich die Begriffsbezeichnung, die  Le X. anfangs 
einbrachte und nutzte, in dem Fall also "Fanboys".
Siehe dazu:
Beitrag "Re: Vi Editor ausgestorben?"

von Nano (Gast)


Lesenswert?

udok schrieb:
> Nano schrieb:
>> Der Grund ist einfach:
>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
>> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann
>> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim
>> nicht nutze.
>
> Der Grund dürfte eher sein, dass manche es super lustig finden, wenn du
> dich
> aufregst, über was auch immer... dazu gehören aber mindestens 2.

Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin 
da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den 
anderen dann zu korrigieren.

Du kennst ja sicher folgendes Comic:
https://xkcd.com/386/

Ich kann stundenlang diskutieren.

von Nano (Gast)


Lesenswert?

vim schrieb:
> Nano schrieb:
>> Der Grund ist einfach:
>> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
>> weitaus mehr Gewicht zu
>
> Du solltest an Deiner Selbstwahrnehmung arbeiten.
>
> Niemand hier dürfte Dich für einen Profi halten. Eher für einen
> Informatik-Erstsemester, ...

Als vim Fanboy hast du jetzt natürlich keine andere Möglichkeit mich 
wieder persönlich anzugreifen, anstatt in der Sache, nachdem ich 
Personen wie dich durchschaut habe.


> Deine Beitragsbewertungen sprechen für sich, -13 ohne
> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.

Beitragsbewertungen kann man als Gast nicht einsehen, also existieren 
sie nicht.
Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen 
sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an 
dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI 
zu verstehen.

von Nano (Gast)


Lesenswert?

Norbert schrieb:
> Aber dafür erklärt er uns doch so schön die Welt mit all ihren Facetten.
> Und was alle anderen außer ihm falsch machen.
> Und was er viel besser könnte wenn man ihn nur ließe.
> Er erklärt uns wie groß Dateien werden dürfen.
> Und das er noch nie Größere gebraucht oder gesehen hat.
> Er erklärt uns das Binärformate bei größeren Dateien besser sind.
>
> Wir alle sollten besser auf ihn hören! ;-)

Oben habe ich in meinem Beitrag
Beitrag "Re: Vi Editor ausgestorben?"

ja ausführlich und argumentativ begründet, warum man für Messdaten keine 
einzige große Datei nutzen sollte.

Es steht dir jetzt frei, diese ganzen von mir genannten Argumente 
hiermit zu widerlegen, aber warum nutzt du diese Chance nicht und 
greifst mich stattdessen wieder persönlich an,
O Ton:
> Aber dafür erklärt er uns doch so schön die Welt...

anstatt einfach mal in der Sache mich argumentativ zu widerlegen?

Überlege mal!
Letzten Endes könntest du jetzt auch einfach zugeben, dass du die 
genannten Argumente nicht widerlegen kannst.

von Nano (Gast)


Lesenswert?

Nano schrieb:
> vim schrieb:
>> Deine Beitragsbewertungen sprechen für sich, -13 ohne
>> Gegenstimmen (im GDI-Thread) schaffen sonst nur Trolle.
>
> Beitragsbewertungen kann man als Gast nicht einsehen, also existieren
> sie nicht.
> Und in welchem Zusammenhang die -13 stehen sollen und warum sie gefallen
> sein sollen, müsste man sich ganz genau ansehen. Oft liegt es ja auch an
> dem Missverständnis der anderen, den Zweck der Frage bezüglich der GDI
> zu verstehen.

Ups, da fehlte ein Wort. Ich meinte natürlich "nicht zu verstehen".

von Norbert (Gast)


Lesenswert?

Nano schrieb:
> Oben habe ich in meinem Beitrag
> Beitrag "Re: Vi Editor ausgestorben?"
>
> ja ausführlich und argumentativ begründet, warum man für Messdaten keine
> einzige große Datei nutzen sollte.
>
> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente
> hiermit zu widerlegen

Diese Hybris ist unbeschreiblich!
Du meinst tatsächlich anderen erklären zu müssen, was richtig und was 
falsch ist? Wer glaubst du eigentlich wer du bist?

Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes 
vorzustellen:
Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB. 
Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht 
beugen wollen.
Diese Anlagen bestehen darauf Daten im Textformat auszuspucken.
Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert 
tadellos.

Also nimm dich mal ein wenig zurück und rede (und vor allem urteile) 
nicht über Dinge die in deiner Welt nicht vorkommen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nano schrieb:
>> Wer also halbwegs mit den Windows-Editor oder Word umgehen kann, kann
>> sofort auch Vim benutzen, ohne irgendetwas dazulernen zu müssen.
>
> Das würde ich nicht sagen.

Du nicht, ich schon.

> Denn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über
> das Menü einstellbar.

Ich habe nicht behauptet, dass EasyVim ein 1:1-Notepad-Klon ist, aber
die wesentlichen Funktionen, insbesondere die, die man zum Editieren der
berühmten Config-Files braucht, sind gleich oder zumindest leicht in den
Menüs auffindbar. Wer deutlich mehr braucht, nutzt nicht den Easy-Mode
und erst recht nicht Notepad.

Was meinst du mit dem einstellbaren Zeilenumbruch? Die Aktivierung und
Deaktivierung des automatischen Zeilenumbruchs? Oder die maximale
Zeilenlänge als Parameter für den automatischen Zeilenlänge? Beides
lässt sich über das Menü einstellen.

Was meinst du mit Kodierungsschema? Die Zeichenkodierung? Defaultmäßig
wird diese von der zu editierenden Datei oder – wie beim Nano – vom der
Einstellung des aufrufenden Prozesses bzw. des Betriebssystems
übernommen. Kein Anfänger möchte diese Einstellung ändern. Falls er
fortgeschritten genug ist, um dennoch solche exotischen Funktionen zu
brauchen, wird es ihm nicht schwer fallen (auf jeden Fall leichter als
beim Nano ;-)), den entsprechenden Befehl nachzuschlagen.

> Auerdem funktioniert im Easy-Mode, wie ich gerade beim Ausprobieren
> feststellen konnte, kein ESC :q! um vim zu verlassen.

Das soll es auch nicht, denn das wäre ja für den Anfänger nicht easy :)

> Auch ein STRG+Q oder ALT+Q oder STRG-> brachte hier keinen Erfolgt.

Strg+Q sollte gehen und geht bei mir auch. Wenn es bei dir nicht geht,
hast du wieder so eine verkrüppelte Vim-Version installiert, oder dein
Window-Manager nutzt diese Tastenkombination für eigene Zwecke. Dann
bleibt aber immer noch das Menü (File/Exit bzw. Alt+FX) oder eben

> ALT+F4

Nano, mittlerweile weiß doch jeder, der diesen Thread liest, dass du
kein Freund von Vim bist, und jeder (einschließlich mir) akzeptiert
dies, auch ohne dass du ständig neue und immer fadenscheinigere Gründe
gegen Vim an den Haaren herbeiziehst.

von Nano (Gast)


Lesenswert?

Norbert schrieb:
> Nano schrieb:
>> Oben habe ich in meinem Beitrag
>> Beitrag "Re: Vi Editor ausgestorben?"
>>
>> ja ausführlich und argumentativ begründet, warum man für Messdaten keine
>> einzige große Datei nutzen sollte.
>>
>> Es steht dir jetzt frei, diese ganzen von mir genannten Argumente
>> hiermit zu widerlegen
>
> Diese Hybris ist unbeschreiblich!
> Du meinst tatsächlich anderen erklären zu müssen, was richtig und was
> falsch ist? Wer glaubst du eigentlich wer du bist?

Und wieder wiederholst du deinen Angriff auf die Person, anstatt in der 
Sache meine Argumente zu widerlegen.

Lies und lerne:
https://de.wikipedia.org/wiki/Argumentum_ad_hominem


> Wenn es dir überhaupt möglich ist, dann versuche dir mal folgendes
> vorzustellen:
> Es gibt unzählige fertig aufgebaute Anlagen, in diesem Fall zB.
> Messdaten-Erfassungen, die sich einfach deinen Vorstellungen nicht
> beugen wollen.
> Diese Anlagen bestehen darauf Daten im Textformat auszuspucken.
> Sie machen das nicht erst seit ein paar Jahren. Und es funktioniert
> tadellos.

Das widerlegt meine Argumente nicht, es zeigt nur, dass diese Geräte von 
den gleichen Typen programmiert wurde, die alle Messdaten in eine 
einzige große Datei zu schreiben.

Übrigens gibt es das split Kommando, das solltest du dir mal ansehen.

von Rolf M. (rmagnus)


Lesenswert?

Nano schrieb:
> Ihr habt oben etwas von Messdaten geschrieben.
>
> Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen,
> dann sollte man über ein Binärformat und ein Programm, über das man auf
> diese zugreift und das diese aufbereitet, nachdenken.

Du meinst z.B. so wie es systemd tut? Der schreibt seine Logdaten als 
Binärklumpen raus, so dass man sie nicht mehr einfach mit einem normalen 
Texteditor öffnen kann.
Ansonsten: Was bringt es mir, über ein Binärformat nachzudenken? Wenn 
ich ein Programm habe, das die Daten als Text ausgibt, dann ist das eben 
so. Nicht jeder hat die komplette Software, die er benutzt, selbst 
geschrieben oder die Möglichkeit, diese mal kurz umzuprogrammieren, um 
ein völlig anderes Format auszugeben.

> Grund:
> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel
> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm
> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.

Allerdings muss man dann eben auch das Anzeigeprogramm schreiben. Bei 
Text nehme ich einfach den bereits vorhandenen Texteditor.

> Also, ja, es ist und bleibt Unsinn eine einzige große Textdatei
> anzulegen.

Sag das mal dem AUTOSAR-Konsortium. Da können auch mal XML-Dateien 
entstehen, die 2GB groß sind. Das kann ich als Anwender nicht ändern, 
sondern nur hinnehmen und muss halt irgendwie damit klar kommen.

von Ein T. (ein_typ)


Lesenswert?

Nano schrieb:
> Ein T. schrieb:
>> rbx schrieb:
>>> Prinzipiell ja. Mit Programmierern und Bastlern zusammen zu frühstücken,
>>> hat auch was für sich. Suchmaschinen sind da reichlich Sinnlos, so
>>> körperlos,geruchsneutral, so berührungsfrei, so uninspirierend usw.
>>
>> Das ist eine interessante Perspektive, aber wenn es um Körperlichkeit
>> mit Geruch, Berührungen und Inspirationen geht, bevorzuge ich weibliche
>> Gesellschaft. ;-)
>
> Warum unterstellst du Frauen, dass sie nicht programmieren oder basteln
> könnten?

Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und 
ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich 
andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und 
Berührungen geht. ;-)

von Ein T. (ein_typ)


Lesenswert?

Nano schrieb:
> Und ich weiß inzwischen auch, warum die Fanboys sich ganz besonders dann
> aufregen, wenn ich dazu etwas schreibe und in Einzelfällen einige wenige
> mich sogar persönlich angreifen, wie man oben sehen konnte.
>
> Der Grund ist einfach:
> Die wissen, dass ich kein IT Laie bin, sie messen meinen Aussagen also
> weitaus mehr Gewicht zu, als sie das bei einem Laien tun würden und dann
> ist das natürlich besonders übel für die Fanboys, wenn ich deren vim
> nicht nutze.

Bwahahahaha! TY, YMMD... again! ;-)

von Ein T. (ein_typ)


Lesenswert?

Nano schrieb:
> Das ist seltsam, denn ich rege mich bei so etwas gar nicht auf. Ich bin
> da ganz entspannt und ich sehe es eher als sportliche Unterhaltung, den
> anderen dann zu korrigieren.

Davon merke zumindest ich leider wenig.

> Ich kann stundenlang diskutieren.

Das hingegen ist mir schon aufgefallen. Erstaunlich, nicht wahr?

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


Lesenswert?

Nano schrieb:

>> Da bist du aber schon jenseits der üblichen einfachen Editieraufgaben
>> (die berühmte Konfig-Datei).
>
> Nicht zwingend. Früher musste man unter Windows die
> Zeilenumbruchfunktion in Notepad nutzen, damit man die README Dateien,
> die unter Unix mit einem LF Codierung für den Zeilenumbruch
> abgeschlossen wurden, in Notepad überhaupt richtig lesen konnte.

Dafür habe ich nie Notepad genommen, sondern Wordpad. Das konnte das 
sofort.

Da man darin aber nichts editieren muss, interessiert mich nicht, wie 
man da was umstellen würde.

> Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3
> ausprobiert

Das ist ja auch Quatsch, das überhaupt zu versuchen. Du kannst 
vielleicht einen alten GNU Emacs auf einer PDP-11 benutzen, aber einen 
aktuellen Emacs auf so einem kastrierten System zu nehmen, das kann 
nicht gut gehen.

Ein aktueller Emacs startet (im GUI-Modus) auf vergleichbarer Hardware 
unter Unixen zumindest schneller als ein Notepad++ unter Windows.

von Ein T. (ein_typ)


Lesenswert?

Jörg W. schrieb:
> Ein T. schrieb:
>> Die Powershell kann laut deren Aussage an vielen Stellen deutlich mehr.
>
> Sie kann mehr, macht aber alles anders, und vor allem kann sie
> Datenströme bei Ausgabeumlenkungen und Pipes ruinieren – musste ich
> schmerzlich feststellen.

Von einem User im Python-Forum.de werden das "Windows Terminal" [1] und 
der "Cmder" [2] empfohlen, vielleicht könnte eines dieser Programme 
etwas für Dich sein. HF!

[1] 
https://apps.microsoft.com/store/detail/windows-terminal/9N0DX20HK701?hl=de-de&gl=DE
[2] https://cmder.net/

von wasn los (Gast)


Lesenswert?

Nano schrieb:
> Man erkennt sie gut, die Leute, die zur Hass und Pöbelfraktion gehören
> und keinen anständigen Diskurs mit Anstand und Niveau führen könenn.

hihi... ja die erkennt man echt gut ;)

von wasn los (Gast)


Lesenswert?

Le X. schrieb:
> Es ist schon interessant wie fanatisch man sein Tool lieben kann.
> Überkochende Emotionen sind ein Garant für gute Unterhaltung.

Oh ja... bin schon an der zweiten Portion Popcorn...

von rbx (Gast)


Lesenswert?

Nano schrieb:
> Meinte STRG+C

Das ist das klassische Argument. Das ist dann eher so, wie wenn der 
Rechner beim Skyrimspiel hängt bzw. das Bild "einfriert". Konsole geht 
nicht. Alt-F4 auch nicht usw. Aber irgendwas geht. Oft muss man den 
Rechner nicht neustarten.
Bei Windows geht bei solchen Sachen erfahrungsgemäß Strg+Alt+Entf gut.
Das kann man auch ab und zu in Linux benutzen.
Aber prinzipiell nicht mehr sinnvoll, wenn der Bildschirm einfriert.

Im Unterschied zu den Spielstörungen gibt es bei Vi und Vim die ein oder 
andere Einführungshilfe. Die sollte man mitnehmen/Dabeihaben. Aber auch 
dann ist das nicht mehr rauskommen blöd und kann vorkommen - vermutlich 
deswegen, weil es meist nicht in Großbuchstaben im Hilfetest steht.

Nano schrieb:
> enn der Zeilenumbruch oder das Kodierungsschema ist bei Notepad über
> das Menü einstellbar.

Notepad++ kann das. Open Office, also Libre Office aber auch. Auf 
jedenfall muss man das öfter machen, wenn man Texte vom Normalen Desktop 
nach Cygwin überträgt.

Nano schrieb:
> Emacs habe ich gestern übrigens mal in einer VM (QEMU) unter FreeDOS 1.3
> ausprobiert mit ca. 64 MiB für die VM, weil ich da mal schauen wollte,
> welcher Editor sich für mein DOS Projekt am besten eignet.

Da kannst du den Watcom Vi benutzen :)

Und außerdem die 32Bit Debug-Version von Paul Vojta.

Ein T. schrieb:
> Habe ich das? Nein. Warum sollte ich auch? Ich habe viele tolle und
> ausgesprochen fähige Kolleginnen. Aber beim Frühstücken bevorzuge ich
> andere Qualitäten, gerade wenn es dabei um Körperlichkeit, Gerüche und
> Berührungen geht. ;-)

Mir ging es nur darum, den Unterschied zwischen der "Geistform" und der 
normalen körperlichen Anwesenheit verständlich zu machen. Das scheint 
mir ja gut gelungen zu sein, und das reicht mir auch.

https://www.youtube.com/watch?v=ppmEc56nSFk

von timol (Gast)


Lesenswert?

Zeno schrieb:
> timol schrieb:
>> Aber ein Mod kann sich
>> hier ja aufführen wie ein A...
> Das tut der Jörg eigentlich nicht

Aber sicher tut er das - und zwar nicht nur in diesem Thread.


> Da er selbst vorzugsweise unixoid unterwegs ist, fallen seine Kommentare
> halt ab und an entsprechend aus.

Die Benutzung von Unix rechtfertigt noch lange nicht ein solches 
Verhalten. Und es betrifft ja auch viele andere Themen.

> Man muß ja auch nicht alle Statements
> von Jörg kommentieren.

Klar, man muss gar nichts. Gilt für andere aber auch.

von rbx (Gast)


Lesenswert?

timol schrieb:
> Zeno schrieb:
>> timol schrieb:
>>> Aber ein Mod kann sich
>>> hier ja aufführen wie ein A...
>> Das tut der Jörg eigentlich nicht
>
> Aber sicher tut er das - und zwar nicht nur in diesem Thread.

Hm, die Vi Benutzung mit gewissen Formen des Unternehmertums in einen 
Topf, bzw. eine Schublade zu werfen, ist aber schon spannend.

https://de.wikipedia.org/wiki/Generalisierungsgradient

von Zeno (Gast)


Lesenswert?

Jörg W. schrieb:
> Es hat ja auch niemand behauptet, dass er regelmäßig in solchen Dateien
> herum editieren würde
Das liest sich aber in seinem Beitrag anders.
mh schrieb:
> Und warum sollte ich etwas ändern? Ich habe keine Probleme mit diesen
> Dateien ...
Ich lese das so, das er öfter mit solchen Dateien zu tun hat.
Am Ende ist es mir arber auch Rille.
Ich habe mich die letzten 25 Jahren mit Auswertung von Messdaten 
beschäftigt, sowohl von der SW-Seite (Entwickler) her und auch als 
Anwender, also selbst Messdaten erzeugt. Derartig große Textdateien, die 
ich dann noch mit einem Editort bearbeiten müßte, sind mir da nicht 
untergekommen. Lediglich beim CT gab es eine Datendatei mit ca. 2GB. Da 
waren aber nur die ersten 2kB reiner Text der Rest war binär.

Jörg W. schrieb:
> es soll Leute
> geben, die können mit mehr als einem Tool umgehen. Vermutlich dann das
> Gegenteil von "Fanboys".
Schrieb ich ja z.B cat, more, grep und Konsorten.

Mombert H. schrieb:
> Natürlich hast du den Rest meines Beitrags nicht zitiert ;-)
Warum sollte ich das das tun, wenn ich nur Deine Frage beantworte?

von Zeno (Gast)


Lesenswert?

Nano schrieb:
> Ihr habt doch geschrieben Messdaten in Textform. Ich schätze also mal im
> einfachsten Fall ASCII Text.
Naja heute ist ja XML die Wunderwaffe. Das hat zwar durchaus seine 
Berechtigung und die Daten sind sehr gut lesbar, aber es bläht die Datei 
eben auch deutlich auf.
Die Datendateien meines Programmes waren für eine Messung zwischen 7 und 
10kB groß, macht für eine vollständige Messreihe mit 7 Messungen 
70-100kB. Der Typ der meine Software neu programmieren sollte hat da auf 
XML gesetzt, woraufhin sich das Datenaufkommen verzehnfacht hat. Gut 
spielt nunmehr keine Rolle mehr da man die Neuentwicklung nach 6 Jahren 
eingestellt hat und mit meinem Programm weiter arbeitet.
Noch sparsamer im Platzverbrauch war mein Vorgängerprogramm, das hat für 
einen kompletten Datensatz weniger als 10kB gebraucht. Nachteil war 
natürlich, das man sich die Daten nur mit dem Programm selbst anschauen 
konnte, da sie im Binärformat gespeichert waren.

Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit 
einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht.
Zum Beispiel bei meiner Wetterstation werden alle 300s die Daten 
gespeichert (pro Datensatz 52 Werte) und die werden selbstverständlich 
nicht als Text sondern in einer Datenbank gespeichert. Derzeit sind sind 
ca. 7100 Datensätze gespeichert bei einer Datenbankgröße von 1,5MB. Und 
ja man kann sich das mit den passenden Tools, tabellarisch aufbereitet 
ansehen, allerdings ist das eher ein mühsames Geschäft. Ich stelle mir 
gerade vor das als ne Textdatei gespeichert und dann mit dem vi 
angeschaut, dannach wäre man dann reif für die Klappse.

von Zeno (Gast)


Lesenswert?

udok schrieb:
> Wir leben auch nicht mehr in den 90'ern.
Stimmt, Du lebst sogar noch in den 1970'zigern, da wurde der vi 
erfunden, also zu einer Zeit wo Speicherplatz noch knapp war und das 
Datenaufkommen in Byte oder kB gemessen wurde.

Beitrag #7124925 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt, dass es eine ältere Version war.

Aber sicher keine von 1990. :)

Alles danach wurde doch nur noch auf VM-Systemen benutzt.

MS-DOS mit gerade mal 64 KiB linear adressierbarem Adressbereich ist nun 
so ziemlich das letzte, was man irgendwie als Referenz benutzen würde.

von Ein T. (ein_typ)


Lesenswert?

Nano schrieb im Beitrag #7124925:
> Ich habe dir doch gesagt,

Du sagst ziemlich viel, wenn der Tag lang... okay, vergiß das mit dem 
Tag. ;-)

von Kiffer (Gast)


Lesenswert?

Zeno schrieb:
> Bei großen Datenmengen macht eigentlich auch nur ein Binärformat mit
> einem passenden Frontend Sinn, da hat der Nano nicht ganz unrecht.

Das könnte auch gzipped CSV, JSON oder YAML sein. Dafür gäbe es schon 
fertige Frontends, Libraries und Tools. Gerade bei großen Datenmengen 
ist es  aufwändig und daher meistens ziemlich dumm, das Rad neu erfinden 
zu wollen. Meine Güte!

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


Lesenswert?

Kiffer schrieb:
> Meine Güte!

Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie 
sie sich ihre Arbeit organisieren.

von Zeno (Gast)


Lesenswert?

Kiffer schrieb:
> Das könnte auch gzipped CSV, JSON oder YAML sein.
Klar groß, größer, am größten - für sehr große Datenmengen sind 
Textdateien ungeeignet.
JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man 
sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt. 
Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung, 
und da sind die Datenmengen eher überschaubar.

von Kiffer (Gast)


Lesenswert?

Zeno schrieb:
> Klar groß, größer, am größten - für sehr große Datenmengen sind
> Textdateien ungeeignet.
> JSON ist zum Speichern von großen Datenmengen das ungeeigneste was man
> sich vorstellen kann. Dafür wurde das Format auch nicht entwickelt.
> Dieses Format dient vorangig zum Datenaustausch, z.B. Webentwicklung,
> und da sind die Datenmengen eher überschaubar.

Sieh an, Pippi Langstrumpf erklärt uns die Welt.

Selbstverständlich ist JSON für die Speicherung von grossen Datenmengen 
geeignet und wird dafür benutzt.

Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header 
mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel 
mit den Werten kostet kaum Overhead und kann prima als Stream 
verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und 
getestete, stabile und performante Tools und Libraries dafür, die man 
nutzen oder drauf aufbauen kann.

Solche Eigenschaften müsstest Du mit Deinem unprofessionellen Gebastel 
erstmal hinbekommen, kleiner Held.

von Kiffer (Gast)


Lesenswert?

Jörg W. schrieb:
> Kiffer schrieb:
>> Meine Güte!
>
> Behalt deine Güte mal besser für dich, statt anderen vorzuschreiben, wie
> sie sich ihre Arbeit organisieren.

Hab' ich das? Nö. Die einzigen, die hier anderen etwas vorschreiben 
wollen, sind Na-no und Ze-no. Hast Du da vielleicht etwas verwechselt?

von Ein T. (ein_typ)


Lesenswert?

Kiffer schrieb:
> Vor allem im Falle von Meßdaten ist das Format nicht gross. Einen Header
> mit den Spaltennamen und ggf. den Spaltentypen und danach nur noch Tupel
> mit den Werten kostet kaum Overhead und kann prima als Stream
> verarbeitet werden. Und, wie gesagt gibt es fertige, gut abgehangene und
> getestete, stabile und performante Tools und Libraries dafür, die man
> nutzen oder drauf aufbauen kann.

Das ist ja alles nicht durchaus richtig, aber kannst Du nicht bitte 
einfach mal auf die Provokationen verzichten? In diesem Thread ist schon 
genug provoziert worden, simple Besserwisserei sollte fürderhin reichen.

Beitrag #7125414 wurde von einem Moderator gelöscht.
von Kiffer (Gast)


Lesenswert?

Nano schrieb im Beitrag #7125414:
> Lass mich raten, du gehörst zu denen, die sich aus ganz vielen Ecken
> dutzende Bibliotheken für die kleinste Funktion ins Projekt einbinden,
> weil du das alles nicht selber programmieren kannst und dann prahlst du
> hier auch noch damit herum es besonders ineffektiv zu machen. Peinlich!

Erwartbar falsch geraten. Mit ein bisschen Erfahrung lernt man, 
sinnvolle Entscheidungen zu treffen, wann man etwas selbst entwickeln, 
testen und pflegen sollte, und wann das zu etwas führt, das erfahrene 
Entwickler als NIH-Problem kennen. Nur Anfänger glauben, alles besser zu 
können als der Rest der Welt.

Weißt Du, Hybris gehört zwar nach Larry Wall, dem Erfinder der Sprache 
Perl, zu den Kardinaltugenden guter Entwickler. Faulheit aber auch!

> Und JSON IST ineffizient für große Datenmenge, da ist sogar CSV um
> Welten besser!
> JSON ist für kleine Datenmengen gedacht, in erster Linie dafür, wo man
> normalerweise XML einsetzen würde.

Wo steht das? Wer sagt das? Du?

> JSON ist effizienter als XML, aber
> bei mehren hundert MB ist es immer noch höchst ineffizient.

[ ] Du hast den Teil mit der Komprimierung verstanden.

[ ] Du hast den Teil mit dem Datenformat verstanden.

> Also arbeite mal an deinem Umgangston,

Na das sagt der Richtige.

von Max Mustermann (Gast)


Lesenswert?

Endlich!
vim 9 ist in Debian sid angekommen. Jetzt steht der weiteren Verwendung 
nichts mehr im Wege, die Nutzerbasis wird sich erhöhen. Andere 
Distributionen werden nachziehen. Die Bugbereinigung wird anlaufen. Der 
tolle Editor lebt weiter. Aber der Resourcenverbrauch hat ja vom 
einstigen Editor für Minimalisten ordentlich zugelegt. Wer eine 
schlankere Version bevorzugt, kann es mit vim-tiny versuchen.

von Ohoh (Gast)


Lesenswert?

Der Fanboy kriegt gleich einen Orgasmus wegen eines ollen Editors.

von Jack V. (jackv)


Lesenswert?

Max Mustermann schrieb:
> Endlich!
> vim 9 ist in Debian sid angekommen.

Am Mittwoch letzter Woche bereits – du bist zu langsam. Und am Samstag 
wurde die Version in Testing aufgenommen – dessen Userbasis ist ja doch 
ungleich größer, als die von Unstable.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Max Mustermann schrieb:
> Endlich!
> vim 9 ist in Debian sid angekommen.
> ...
> Andere Distributionen werden nachziehen.

Der Nachzügler ist – nach über 5 Wochen – wohl eher Debian selber. Zum
Vergleich: Arch hat dafür 5,7 Stunden gebraucht :)

von 42 (Gast)


Lesenswert?

Arch ist bei Aktualisierungen immer top.

von Siggi (Gast)


Lesenswert?

Wann wird wohl Ubuntu und Linux-Mint nachziehen?

von Jack V. (jackv)


Lesenswert?

42 schrieb:
> Arch ist bei Aktualisierungen immer top.

Nein, nicht immer. Siehe beispielsweise Cura – das ist nun schon drei 
Monate veraltet.

von Nico (Gast)


Lesenswert?

Siggi schrieb:
> Wann wird wohl Ubuntu und Linux-Mint nachziehen?

Die neuste Version von vim ist für Mainstream-Distries einfach 
unwichtig. Standardmäßig haben die ohnehin nur vim-tiny. So als 
Backup-Lösung wenn die GUI nicht funktioniert und man deshalb keinen 
richtigen Editor verwenden kann.

von Roman (Gast)


Lesenswert?

Nico schrieb:
> und man deshalb keinen
> richtigen Editor verwenden kann.

Was ist ein richtiger Editor?

von Gunnar (Gast)


Lesenswert?

Roman schrieb:
> Was ist ein richtiger Editor?

Kate, Bluefish, VScode,
Ultraedit, notepad++(Windows)

Minimalistisch für console: nano, pico, joe

von Ein T. (ein_typ)


Lesenswert?

Nano schrieb:
> Oben habe ich in meinem Beitrag
> Beitrag "Re: Vi Editor ausgestorben?"
>
> ja ausführlich und argumentativ begründet, warum man für Messdaten keine
> einzige große Datei nutzen sollte.

Du schreibst in dem verlinkten Beitrag:

Nano schrieb:
> Wenn es Messdaten sind, die in kurzer Zeit solche großen Daten anhäufen,
> dann sollte man über ein Binärformat und ein Programm, über das man auf
> diese zugreift und das diese aufbereitet, nachdenken.
> Grund:
> Ein Binärformat spart viel mehr Platz und ist für einen Computer viel
> besser verarbeitbar. Außerdem kann man, wenn man ein Anzeigeprogramm
> schreibt, gleich noch daran denken, die Daten noch zu komprimieren.

In dieser Argumentation fehlen mir einige praktische und ökonomische 
Perspektiven.

Ja, Textdat(ei)en sind vielleicht um einen Faktor zwei bis fünf größer, 
dafür aber sofort und ohne weiten Investitionsaufwand für die 
Softwareentwicklung von jedem Menschen lesbar. Es gibt eine riesige 
Vielfalt fertiger, leisungsfähiger und sehr feingranular konfigurier- 
und steuerbarer Programme, um Textdat(ei)en anzeigen und verarbeiten zu 
können, denk nur mal an grep(1), sed(1), awk(1), oder an perl(1), oder 
auch gnuplot(1) oder die Programme aus dem graphviz-Paket. Oder an 
Pandas in Verbindung mit Matplotlib, Seaborn, Plotly oder Bokeh, um nur 
ein paar Beispiele aufzuführen.

Obendrein sind Textdat(ei)en flexibler als Binärdat(ei)en, das heißt: in 
einer Textdatei kann ich ohne Weiteres verschiedene Logformate speichern 
und anschauen (denk nur mal an die Systemlogs unter Linux und UNIX), 
während das bei binären Dateien zwar machbar, aber mit wesentlich mehr 
Aufwand verbunden ist -- welcher obendrein bei jeder Änderung erneut 
anfällt. Wenn der, der die Daten verarbeiten soll, dann vielleicht nicht 
identisch mit dem Softwareentwickler ist, werden Deine Binärdat(ei)en 
sehr schnell zu einem bösartigen ökonomischen Problem.

Meinen Rechner riesige Textdat(ei)en durchsuchen, verarbeiten, anzeigen 
zu lassen, kostet mich wenig. Einen Softwareentwickler an die 
Entwicklung eines Binärformates und dann bei jeder Änderung wieder daran 
zu setzen, kostet mich hingegen erstens Zeit und zweitens Geld. Und wenn 
mal ein Sensor spinnt und kaputte Daten in eine Binärdatei schreibt, ist 
womöglich die ganze Datei mit allen Daten verloren, wenn ich nicht schon 
wieder viel Geld ausgeben und einen Entwickler daran setzen will.

Nano schrieb:
> Sollte die Messzeit mehrere Tage gehen, dann verlasst ihr euch darauf,
> dass euer Messrechner Absturzsicher arbeitet. Große Dateien können hier
> zu großen Verlusten führen.

Dieses Argument zieht nur, wenn die Daten auch dann nützlich sind, wenn 
sie nur in Teilen vorliegen. Bei vielen Messungen haben die Daten aber 
nur dann einen Wert, wenn sie über die gesamte Messung hinweg 
durchgängig vorliegen. Das heißt: wenn die Aufzeichnung wegen eines 
Ausfalls mitten während der Erhebung der Daten endet, ist der gesamte 
Test inklusive aller erhobenen Daten nutz- und wertlos.

> Also sollte man hier zusehen, dass man nach Dauer N, die alte Datei
> schließt und in einer neuen Datei weiterschreibt, das bietet bei Verlust
> mehr Sicherheit und das erlaubt dann auch die alten Dateien zu
> komprimieren und so Speicherplatz zu sparen.

Textdat(ei)en kann man auch komprimieren, wußtest Du das schon? Meistens 
sogar mit ziemlich guten Kompressionsraten...

Mein grundsätzliches Herangehen an solche Datenmengen ist allerdings 
ohnehin ein gänzlich anderes: egal, wie ich die Dat(ei)en bekomme, pumpe 
ich sie sofort in meinen Opensearch-Cluster. Nicht, weil der die Daten 
dann binär speichert, sondern weil der extrem performant und obendrein 
hochverfügbar ist, meine Daten direkt und trotzdem strukturell flexibel 
in revertierten Indizes speichert, die sich wiederum unfaßbar schnell 
durchsuchen, wunderbar mit Opensearch-Dash visualisieren, oder mit allen 
möglichen Programmier- und Skriptsprachen weiterverarbyten lassen. 
Deswegen kann ich bei Eurem Gespräch über Speicherformate von 
Massendaten nur bedauernd mit dem Kopf schütteln -- und dabei vor allem 
darüber, daß Du die inhärenten Vorzüge von Textdat(ei)en entweder nicht 
(an)erkennen willst oder nicht kennst. Dateien, Jungs, echt mal... das 
ist doch total Neunziger. ;-)

Zuletzt sei eine Kleinigkeit angemerkt, die Du anscheinend ebenfalls aus 
Deinen Augen verloren hast. Nämlich, daß man als Profi oft gar keine 
andere Wahl hat, als Daten so zu verarbeiten, wie man sie bekommt.

von rbx (Gast)


Lesenswert?

Ein T. schrieb:
> egal, wie ich die Dat(ei)en bekomme, pumpe
> ich sie sofort in meinen Opensearch-Cluster.

Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht, 
dass Data-Mining generell uninteressant ist. Geht aber auch etwas besser 
mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich 
Kunstprodukte ein.
Das passiert zwar auch bei wichtigen Gutachten - naja, sehr viele Leute 
sind nicht gut in Statistik (trotz der entsprechenden guten Ausbildung), 
und ich eigentlich auch nicht, wenn ich mir keine Mühe gebe - ist 
trotzdem nicht schön, und so wohl eher ein Grund zum schmunzeln trotz 
des düsteren Hintergrundes.

von Ein T. (ein_typ)


Lesenswert?

rbx schrieb:
> Ein T. schrieb:
>> egal, wie ich die Dat(ei)en bekomme, pumpe
>> ich sie sofort in meinen Opensearch-Cluster.
>
> Wow. Passt auch mal wieder sehr gut zu Mikrocontroller und so. Nicht,
> dass Data-Mining generell uninteressant ist.

Verrätst Du mir, wie Du an dieser Stelle auf "Data Mining" kommst? War 
es das Stichwort "Cluster", das Dich getriggert hat, oder wie kam das 
zustande?

Im Kern geht es erst einmal darum, die Daten möglichst schnell und 
möglichst unaufwändig mir und den Kollegen zugänglich zu machen, damit 
wir mit den Daten arbeiten können. Dafür werden wir nämlich bezahlt. 
Vielleicht magst Du Dir die Software mal näher anschauen, um zu 
verstehen, was sie leistet und was nicht.

> Geht aber auch etwas besser
> mit Etwas-Ahnung-Haben-In-Statistik - allenfalls fängt man sich
> Kunstprodukte ein.

Schon der erste Schritt, nämlich die explorative Datenanalyse (EDA), 
kann ohne fundierte Kenntnisse der Statistik nicht funktionieren, und 
für jede Tätigkeit im Bereich des Data Mining gilt dasselbe. Ich bin 
daher äußerst irrigiert, wie man da irgendwelche Widersprüche ausmachen 
kann. Kann es sein, daß Du Dich mit Data Mining nicht wirklich auskennst 
und daher einigen (durchaus populären) Mißverständnissen aufgesessen 
bist? Oder, anders gefragt: was glaubst Du eigentlich, was wir im Data 
Mining so machen, wie das funktioniert und, vor allem, wie das ohne 
fundierteste Kenntnisse in Statistik gehen könnte?

von prust (Gast)


Lesenswert?

Was hat eure Datenpornografie jetzt mit dem Thema zu tun? Hauptsache 
irgendwelche vagen Andeutungen machen, damit keiner weiß worum es geht 
und man dann anderen Ahnungslosigkeit vorwerfen kann? Oder warum 
antwortet man überhaupt darauf, wenn gar nicht klar ist, worum es geht? 
Ein Troll gegen den anderen Troll.

von Ein T. (ein_typ)


Lesenswert?

prust schrieb:
> Was hat eure Datenpornografie jetzt mit dem Thema zu tun?

Thread lesen bildet.

von Le X. (lex_91)


Lesenswert?

prust schrieb:
> Was hat eure Datenpornografie jetzt mit dem Thema zu tun?

Nach 'nem Monat Pause hat sich wieder jemand an einer (längst 
widerlegten) Aussage betreffend der Verwendung von großen Textfiles 
hochgezogen,

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.