[Tustep-Liste] Neuerungen im Editor

[Paul Sappler]

Lieber Herr Trauth, sehr verehrte Runde,

mit Herrn Osthof gehe ich, mit Ausnahme eines Punktes, völlig einig.  
Ich konnte zwar - Linux - die neue Fassung noch nicht testen, kann sie  
mir aber vorstellen. Auch für mich ist "d" (und manchmal "n") wichtig,  
ich schätze die Angaben über "woher geholt", "ob und wohin gerettet"  
und auch den "Titel", Metadaten zu Segment oder Datei, ferner den  
Zeitpunkt der letzten Veränderungen. Auch beißt sich "d" nicht mit der  
Bewahrung der aktuellen Satzposition (*), die oft nützlich ist; die  
Wiederherstellung des Fensterzustandes vom Verlassen des Editors  
(sozusagen das höhere zu*/za*) scheint mir zu aufwendig, besonders  
unter dem Gesichtspunkt letzter Korrekturen vor "b", wo das  
Editorfenster, besonders nach dem Löschen von Sätzen und dem  
Überschreiben von gefärbten Partien, ja seltsam aussehen kann. M.E.  
genügt die Bewahrung von * (von mir aus auch das Merken der ersten  
Bildschirmzeile, Vorschlag Wildensee).

Nicht ganz zusammen gehe ich mit Herrn Osthof darin, daß ich die  
Umgewöhnung ohne größere Schwierigkeiten schaffe.

Sollte nicht der Tustep-Editor ein paar Besonderheiten gegenüber  
anderen Editoren aufweisen dürfen? Es ist ein Vorteil, daß man in der  
Originaldatei arbeiten kann - sonst geht es oft nur in Scratch-Kopien  
mit umständlicher Sicherungsverwaltung; in der Regel nur mit globalen  
Einstellungen ohne Spezifika für die einzelne Datei usw.  
Gewöhnungsbedürftig, aber sinnvoll auch die Funktion, die Änderungen  
in einem Tustep-Editorfenster "abzuschicken".

Vieles hat Herr Schälkle ja schon für eine gute Initiierung beim  
Editoraufruf getan: Selbstverständlich sollte man beim Editor-Aufruf  
die Spezifikation makro benutzen, vor allem bei Aufruf aus einer  
Kommandofolge und bei spezifischer Sicht auf den Text im Editor. Sehr  
wertvoll auch die Makros fn_# ft_# fc_#. Was mir fehlt, habe ich in  
meinem Listenbeitrag vom 11.4. angedeutet: bei jedem Hineingehen in  
den Editor nicht nur Definitionen, sondern die Ausführung eines  
Makros. Ich habe eine Reaktion darauf vermißt (dabei dachte ich den  
Stein der Weisen angepriesen zu haben): Ist der Vorschlag technisch  
nicht ausführbar? Will man einen Benutzer davor bewahren, etwas Dummes  
einzustellen, z.B. die Erzeugung von "cancel", so daß er bei einer  
bestimmten Datei immer aus dem Editor fliegt? Ist die Idee sinnlos?  
Fürchten Benutzer, für die vorgeschlagene Verwaltung des Makro-Pools  
in die Pflicht genommen zu werden? Ist es die Abneigung gegen einen  
komplizierten, wenig durchschaubaren Hintergrund? Gibt es irgendwo  
einen Haken? Fürchtet man Folgewünsche wie etwa Ausführung eines  
Makros beim Verlassen des Editors (was man zum Merken der ersten  
Bildschirmzeile nutzen könnte)?

Wenn Veränderung als solche gescheut wird, Erweiterung aber  
akzeptiert, variiere ich meinen Vorschlag, meinen Wunsch: Nicht die  
Spezifikation makro des Editoraufrufs, eines Makros, das ja nur bei  
jedem eben mit dieser Spezifikation getätigten Aufruf in Gang kommt,  
sondern eine neue Spezifikation IMAKRO (oder wie sie sonst heißen mag)  
soll definieren, was bei jedem Hineingehen in den Editor  
dateispezifisch ausgeführt werden soll.

Die Diskussion über feste Voreinstellungen ist natürlich nützlich,  
weil bewußtseinsbildend, aber die Enge, die durch diese  
Voreinstellungen entsteht, ist nicht tustep-angemessen. Es schadet  
doch niemandem, wenn Herr Osthof, Frau Söhnen-Thieme und ich bei "d"  
als erster Editoranweisung bleiben, andere können "za*" oder "zu*" für  
sich voreinstellen oder auch etwas Sinnvolleres.

Schluß. Vielleicht werden ja lange Mails nicht gelesen.
Nachtrag zum Brunschönproblem "Register: mehrfaches Vorkommen in einer  
Zeile auswerten": aha, HF war die Lösung. Tut mir leid, daß ich  
vorgeprescht bin. Schade, daß nur zwei Leute RA wirklich beherrschen.
Bitte bei Antworten an die Liste die auslösende Mail nicht wiederholen.
Freundliche Grüße in die Runde
Ihr Paul Sappler