> >Vor Jahren hatte ich eine IDE, die sich wie angedeutet verhielt.
> >Seitdem seither trauer ich dem nach. stdout/stderr blieb einfach in
> >der Anzeige unber�cksichtigt, dadurch wurde das Arbeiten mit make,
> >grep ar, "run program", cd, pushwd, run_my_own.sh etc. herrlich
> >unkompliziert komfortabel (auf Benutzerwunsch k�nnte ja ein
> >Protokollfenster ge�ffnet werden). Also: f�r den beschriebenen
> >Effekt darf die Befehlssammlungsdatei oder das, was daf�r gerade
> >getippt wurde, weder inhaltlich noch visuell durch das Aufrufen einer
> >Zeile mit kommandos ver�ndert werden.
>
> Das w�rde ich mit einem Macro machen. Dann kannst Du noch je nach
> R�ckgabewert entscheiden, ob Du die Ausgabe verwirfst oder nicht.
Beim Programmieren habe ich unter Linux in die Quelltexte Kommandos in
Kommentaren eingetippt, um so schnell das Passende in die daneben
ge�ffnete Shell kopieren zu k�nnen. Es gibt so viele verschiedene
Befehlskombinationen, da� f�r die einzelnen nie Makros definiert werden,
geschweige denn alle behalten werden k�nnten (nicht zuletzt weil sich
die st�ndig �ndern).
Der Erfolg von Microsoft h�ngt nicht zuletzt damit zusammen, da� dort
Bewegungs- und Bedienabl�ufe genauestens und aufwendig simuliert und
daraus Konsequenzen gezogen werden. Daraus will ich lernen und beobachte
mich selbst bei meiner Arbeit.; daraus entsteht der Wunsch nach dem
beschreibenen Verhalten. Zusammenfassend:
En strukturierter Text von m�glicherweise hunderten Zeilen mit
Befehlskombinationen, von denen jede mit maximal drei Handbewegungen
ausgel�st werden kann (Scroll Klick Enter), hat nichts mehr mit einer
Sammlung von Makros zu tun. F�r die Umsetzung in z: B. Nedit fehlt nur
ein Schritt: die Ausgabe eines ausgel�sten Kommandos geh�rt in ein
separates stdio-Fenster. Beim Studieren der Arbeitsabl�ufe scheint mir
das in jedem Fall w�nschenswert. Als Zweites und Unwichtigeres k�nnte
noch �berlegt werden, ob dieses Fenster optional unsichtbar ist.
Gerhard
