skh@spice.cs.cmu.edu (Steve Handerson) (06/19/87)
[Are these things really necessary?]
This is an opinion/suggestion post
concerning adding graphical windowing to gnu emacs.
I am not familiar with the kind of system I'm advocating,
but am familiar with one I wish to avoid.
Sorry I missed the original discussion, but I only started using gnu...
My suggestion is that each graphical window actually look like a
normal gnu display (which I'll call a screen, with screen-windows)
each with its own echo-area
and at least vertically-splittable.
They would still share the emacs-lisp environment and buffer lists, etc.
["Windows" now means graphical or X windows.
Pretty obviously I'm talking about overlapping window systems, not
tiled ones.
Tiled ones might be better for automatic management, but users
almost invariably prefer overlapping ones.
]
Basically, the only other thing that makes sense is one window per
editor window.
This leaves you with too many windows and no good ways of grouping them.
Also, you can't effectively automatically-manage windows via code.
If you try this with graphical windows, you generally end up using
something that looks like a screen anyway.
Screens work. People are familiar with them.
My suggestion is (I think) the best of both worlds, not a confusing mixture.
It leaves graphical windows to the user.
Hopefully internally this would be fairly simple;
so long as the lisp can handle the modelessness of N different
windows in different states (different prompts, etc.),
then all you do is multiplex input and its handling.
As for using the mouse inside screens,
I see no reason why something like
"window-top-to-here" or "window-bottom-to-here" couldn't be defined.
Basically, you'd use vertical splitting to just refer to something else,
like help output or info or another file quickly.
If you wanted to keep something, you'd put it in another graphical window.
Another way of looking at it is that each graphical window could
represent a different task.
Splitting horizontally could go away, but it is cute, and you might want
it if you were using a terminal.
Lastly, perhaps the notion of the echo area might be improved.
It would be nice if minibuffers could "pop up" when needed,
thus not sitting around wasting space otherwise.
[Probably only important on small displays, but still...]
The remaining windows and text would remain as much the same as
possible, and you could just redraw the popped-over area when done.
Multiple mini-buffers would become almost natural.
No more "you can't make a minibuffer cause you're already in one".
When a buffer that the minibuffer was referring to goes away,
then the minibuffer quietly disappears too. Or something.
--
Steve Handerson
Carnegie-Mellon University Computer Science Dept.
ARPA: skh@spice.cs.cmu.edu
UUCP: {harvard | seismo | ucbvax | decwrl}!spice.cs.cmu.edu!skh
Scientology is a trademark of the Religious Technology Center and is used
with its permission.