[Tustep-Liste] Neuerungen im Editor

[Michael Trauth]

Liebe Tustepler,

da in der vergangenen Woche eine neue Testversion
u.a. des Editors versehentlich auf der Liste landete,
bringe ich einige der Neuerungen und damit verbundene
Fragen hier zur Sprache.

Die meisten Neuerungen gehen auf Vorschlaege zurueck,
die vor ein paar Wochen auf diesem Forum gemacht wurden:
- Zusaetzliche Kolorierungen wurden eingefuehrt, unter
  anderem kann jetzt auch der Bereich der Satznummer
  optisch vom Textbereich unterschieden werden;
- das Gravis-Zeichen am linken Rand vor der Satznummer
  wurde - Deo sint laudes! - ad acta gelegt;
- der beim Aufruf des Editors frueher voreingestellte
  Statistikbildschirm erscheint jetzt nicht mehr, statt
  dessen wird der Dateiinhalt angezeigt; hierfuer wurde
  die neue Funktion SHW_CUR (= zu,* = zeige die Umgebung
  des Satzes, auf den der Pointer * zeigt) eingerichtet;
  bei einer erstmals geoeffneten Datei ist dies gleich-
  bedeutend mit 'zu,+1'.
Ich halte bes. die letztere Neuerung fuer einen grossen
Gewinn, weil ein Benutzer, der eine Datei oeffnet, na-
tuerlich zuallererst den Inhalt dieser Datei zu sehen
erwartet; daneben geht ein Dateiwechsel bes. im Split-
screen, bei zweigeteiltem Editorfenster, sehr viel
schneller vonstatten als frueher.

Als ein wenig gewoehnungsbeduerftig wird allerdings
von einigen Seiten das beschriebene SHW_CUR betrachtet:
Der zuletzt bearbeitete Satz wird damit in die *Mitte*
des Editorfensters gestellt, auch wenn er zuvor z.B.
am Anfang oder am Ende des Fensters stand (der Bild-
schirm ist also nicht mehr derselbe wie zuvor); auch
wer zum ersten Mal in eine Datei geht, wird zunaechst
wohl ein 'za' erwarten, nicht aber das aktuelle 'zu,+1,'
womit der erste Satz der Datei in die Mitte des Editor-
fensters gestellt wird.

Dieser Verfremdungseffekt ist unbestritten, die Frage
ist nur, was der Programmautor denn statt dessen tun
soll: So koennte er - beispielsweise - den ersten
Aufruf einer Datei (*=0.0) ohne weiteres abfangen
und in diesem Fall ein 'za' greifen lassen. Dann
steht aber *ab* diesem Zeitpunkt der Pointer * auf 1.1,
d.h. wenn der Benutzer danach raus- und wieder in den
Editor reingeht, hat er ab dem zweiten Mal *nicht*
mehr *=0.0, sondern *=1.1, und dann soll sich der
Editor anders verhalten als beim ersten Mal? Das waere
gewiss nicht weniger irritierend als der Status quo.
NB: Wir sprechen hier nur ueber den Sonderfall
'erster Aufruf'; nicht viel besser ist es, wenn die
Datei bereits einmal aufgerufen wurde und der Pointer
etwa auf 1.2 oder 1.3 steht, denn dann fuehrt 'zu,*'
zu einem aehnlich stoerenden Effekt.

Eine Primitvloesung bestuende im Standardverhalten
von anderen Windows-Editoren: *Jede* Datei wuerde beim
Aufruf von Anfang an gezeigt. Aber *das* hielte ich
fuer einen klaren Rueckschritt; dass ich bei #e,<datei>
sofort an die Stelle gefuehrt werde, an der ich
zuletzt gearbeitet habe, wuerde ich nicht mehr missen
wollen - vermutlich spreche ich damit im Namen aller.

Dem Programmautor zufolge laesst sich Abhilfe nur
dadurch schaffen, dass TUSTEP sich den Bildschirminhalt
von *jeder* Datei merkt, die aufgerufen wurde. Das
wuerde die TUSTEP.MEM bei ueber 1000 aufrufbaren
Dateien ganz schoen aufblaehen. Und selbst bei
*dieser* Koenigsloesung gibt's gleichwohl noch
ein Tertiaerproblem: Nehmen wir an, der Editor
merkt sich tatsaechlich den Inhalt des letzten
Bildschirms *jeder* Datei, die verlassen wird. Was
soll er denn beim naechsten Aufruf anzeigen, wenn
unterdessen die Desktopaufloesung oder der Font und/
oder die Groesse der Schrift fuers TUSTEP-Fenster
verstellt wurde und damit die darstellbare Textmenge
eine andere waere als zuvor? Was waere in diesem Fall
besser: za*, zu*, zb*? Nicht ganz einfach, oder? Wer
einen guten Vorschlag hat, moege bitte sich bitte zu
Wort melden.

Eine weitere Schwierigkeit ist mit dem Arbeiten im
zweigeteilten Editorfenster verbunden: Der Benutzer,
der aus dem Splitscreen-Editor rausgeht (oder viel-
leicht auch nur ein 'x #t,<programm>' absetzt) er-
wartet selbstverstaendlich, dass er nach der Rueck-
kehr in den Editor *dieselben* beiden Textfenster
zu sehen bekommt wie zuvor. Dem steht aber entgegen,
dass beim Aufruf einer Datei (vom Benutzer so ein-
gerichtet) evtl. zuerst ein Makro ausgefuehrt werden
soll, das womoeglich mit dem neuen SHW_CUR in Konflikt
geraten koennte. Der Programmautor hat deshalb bisher
darauf verzichtet, automatisch auch im nicht-aktiven
Fenster ein SHW_CUR aufzurufen.

Darf ich hier fuers erste einmal fragen, wie die
allgemeine Meinung dazu ist? Dass im Splitscreen-
Modus *beide* Textfenster angezeigt werden, duerfte
wohl *immer* wuenschenswert sein; die Frage ist nur,
ob es eine Kompromissloesung fuer den oben
skizzierten moeglichen Konflikt gibt. Ins Blaue
hinein: Die *-Position merkt sich der Editor ja
ohnehin schon, er koennte vielleicht zusaetzlich
pruefen, ob durch ein allenfallsiges Editormakro
die *-Position geaendert wurde und/oder eine Bild-
schirmausgabe erfolgte - und nur in *diesem* Fall
unterbliebe dann das SHW_CUR. Waere das akzeptabel?

Ueber Wortmeldung wuerde sich freuen

Michael Trauth


---------------------------------------------------------------
Dr. Michael Trauth                  e-mail: trauth at uni-trier.de
Rechenzentrum                       office: Tel. 0651-201-3413
der Universitaet                            Fax  0651-201-3921
Universitaetsring                secretary: Tel. 0651-201-3417
D-54286 Trier
---------------------------------------------------------------