[Tustep-Liste] Neuerungen im Editor

Mi Apr 23 21:34:50 CEST 2008

Lieber Herr Trauth,

ich hoffe, dass die Änderungen im Editor für die Mehrzahl der Anwender
nützlich und sinnvoll sind. Ich werde mich auch sicher an sie gewöhnen - und
tue das schon jetzt, indem ich nämlich bei jedem Wechsel in eine andere
Datei fast schon automatisch 
	Gib Anweisung > za [= F1] 
oder 
	Gib Anweisung > d 
taste. Ich benutze den Editor nahezu ausschließlich zur Erstellung von
Programmen und Makros. Ein Fall aus meiner Praxis: Ich halte in 3 Dateien
ein Makro, das ich aus der Makrodatei "geholt" habe, in zwei oder drei
Dateien in unterschiedlichen Bearbeitungszuständen zum Testen bereit. Mich
interessiert es nicht, dass ich in datei xyz zuletzt offenbar die zeile 2345
bearbeitet habe. Mich interessiert, welches Makro in dieser Datei steht und
ob die Daten gerettet sind oder nicht. Für mich waren die jetzt abgeklemmten
Informationen, die man nach dem Wechsel in eine neue Datei zu sehen bekam,
nützlich und wichtig.

Aber, wie gesagt: Wenn die jetzigen Änderungen für die Mehrzahl der Anwender
nützlich und sinnvoll sind, dann werde ich mich auch daran gewöhnen.

Herzliche Grüße
Matthias Osthof

-----Ursprüngliche Nachricht-----
Von: tustep-liste-bounces at lists.uni-wuerzburg.de
[mailto:tustep-liste-bounces at lists.uni-wuerzburg.de] Im Auftrag von Michael
Trauth
Gesendet: Dienstag, 22. April 2008 19:38
An: Tustep-liste at itug.de
Betreff: [Tustep-Liste] Neuerungen im Editor

Diskussionsforum Tustep-Liste
Weitere Informationen: www.itug.de
------------------------------------------------------------

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

------------------------------------------------------------
Tustep-Liste at itug.de
https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste