[Tustep-Liste] Aenderungen im Editor

[Michael Trauth]

Liebe Tustepler,

es geht um kleine Aenderungen im Editor und um die
Frage, wie sinnvoll und erwuenscht diese sind. Zur
Gewinnung eines Meinungsbildes waere es schoen,
wenn moeglichst viele von Ihnen zumindest ein
kurzes Statement in der Form 
:  ad 1: bin dafuer/dagegen/ist mir egal"
abgeben koennten.

========================================================

(1)

Die Editorfunktion JOIN hat derzeit folgende Funktion:
Sie haengt
- die nachfolgende Zeile an die aktuelle an, wenn
  die nachfolgende Zeile eine Fortsetzungszeile ist;
- den nachfolgenden Satz an den aktuellen an, wenn
  die nachfolgende Zeile einen neuen Satz enthaelt;
- sie tut nichts, wenn die nachfolgende Zeile eine
  Fortsetzungszeile ist, aber die aktuelle Zeile
  voll ist.

Daran habe ich mich gewoehnt, und ich finde es auch
nicht schlecht so, aber das bedeutet ja nicht, dass
man es nicht auch *noch* besser machen kann. So
faende ich es etwa sinnvoller und praktischer, den
aktuellen *Datensatz* (nicht wie derzeit *Zeile*!)
mit dem voran(!)gehenden Datensatz zu vereinigen.

Der Hintergrund dafuer ist, dass ich mich im Editor
vor einiger Zeit auf das Arbeiten im Modus SPLIT
umgestellt habe: RETURN legt jeweils einen neuen
Datensatz an (wie man es von Windows-Editoren her
kennt), und das 'Wegschicken' geaenderter Daten
wird mit der ENTER-Taste besorgt - ich kann das
empfehlen, die Arbeit geht damit nach kurzer Um-
gewoehnungszeit deutlich schneller von der Hand.
Dabei passiert's aber immer mal wieder, dass man
ungewollt ein RETURN an einer Stelle eingibt, wo
*kein* neuer Satz angelegt werden soll. Das daran
gekoppelte SPLIT teilt evtl. sogar einen Text an
der Cursorposition in zwei Saetze auf - und diese
dann wieder zusammenzufuegen, ist mit einiger
laestiger manueller Muehe verbunden.

Die von mir vorgeschlagene Aenderung von JOIN
hatte gegenueber dem aktuellen JOIN zwei Vorteile:
- Es waere keine Fallunterscheidung mehr noetig;
- ein versehentliches SPLIT koennte problemlos
  sofort wieder aufgehoben werden.

Wer sieht demgegenueber gewichtige Gruende, den
Status quo beizubehalten?

==================================================

(2)

Eine andere Editorfunktion ist CUR_POS, mit deren
Hilfe der Cursor in Editormakros an eine gewuenschte
Stelle positioniert werden kann. Das geschieht aber
bildschirm(!)bezogen und nicht text(!)bezogen. So
setzt etwa die Anweisung CUR_POS:0;10 den Cursor
- im Editormodus T mitten in die Satznummer,
- im Editormodus P auf das zweite Zeichen des
  Textes,
- im Editormodus '-' und bei Dateneingabe auf das
  10. Zeichen des Textes.

Ich faende es es demgegenueber sinnvoller und prak-
tischer, wenn das Positionieren nur text(!)bezogen
*innerhalb* eines Datensatzes geschaehe (denn wer
will schon in den Raum fuer die Datensatznummer
hineinspringen, um an dieser etwas zu aendern???).
Ich plaediere deshalb dafuer, die Positionierung
kuenftig nur noch auf das soundsovielte Zeichen
des Textes vorzunehmen, dass also beispielsweise
CUR_POS=0;10 den Cursor in allen Faellen auf das
10. Zeichen des Textes setzt.

Wer sieht demgegenueber gewichtige Gruende, den
Status quo beizubehalten?

=================================================

(3)

In allen Windowseditoren ist das Cursorverhalten
in einem wichtigen Punkt ein anderes als im
TUSTEP-Editor:
a) Wenn bei jenen der Cursor hinter dem letzten
Zeichen in einer Zeile angekommen ist und dann
noch einmal weiter nach rechts bewegt wird,
springt der Cursor an den Beginn(!) der folgenden
Zeile - waehrend der Cursor im TUSTEP-Editor ohne
weiteres in den leeren Raum hinter dem Text
weiterbewegt werden kann.
b) Wenn bei jenen der Cursor auf dem ersten Zeichen
einer Zeile steht und weiter nach links bewegt wird,
springt der Cursor ans Ende der davorstehenden Zeile
- waehrend der Cursor im TUSTEP-Editor ohne weiteres
in das fuer die Seitennummer reservierte Feld hinein-
bewegt werden kann. Das ist in den weitaus meisten
Faellen so nicht gewollt, und loest bes. bei TUSTEP-
Novizen nicht selten Irritationen und evtl. sogar,
wenn sie versehentlich versuchen, ins Satznummerfeld
Text hineinzuschreiben, Fehler aus.

Spricht etwas dagegen, das Cursorverhalten des
TUSTEP-Editors an das der anderen Editoren anzu-
gleichen? (Wer in die Satznummer hineinspringen
oder in den Raum hinter dem letzten Zeichen einer
Zeile etwas positionieren moechte, koennte das
dann ja immer noch z.B. mit der Maus tun. Man
koennte ferner - beispielsweise - eine Anweisung
STRG+n - n fuer 'N'ummer - vorsehen, um in das
Satznummerfeld hineinzuspringen usw.

Das ist ganz schoen revolutionaer, ich weiss,
aber denken wir doch einfach mal drueber nach.
Ich muss gestehen, dass ich's praktisch faende...

===================================================


Ueber viele Wortmeldungen wuerde ich mich freuen.


Herzlich gruesst reihum

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