[Tustep-Liste] Aenderungen im Editor

[Dr. Gottfried Reeg]

Lieber Michael,

zu 1):  es macht meines Erachtens Sinn, wenn man
vom Modus SPLIT ausgeht. Das Problem sind natürlich
Editormakros.

zu 2): Macht Sinn, aber auch hier das Problem der
Editormakros

zu 3) Das wird gewöhnungsbedürftig sein, vor allem
dann, wenn man wie ich mit dem Kursor über den Bildschirm
wandert. Er ist dann immer wieder an einer Stelle,
wo man in nicht erwartet.

Die Idee mit Strg+N finde ich gut, denn ein Eingriff
bei der Satznummer sollte überlegt erfolgen.

Herzliche Grüße
Gottfried
> (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
> ---------------------------------------------------------------
>
> ------------------------------------------------------------
> Tustep-Liste at itug.de
> https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
>
>