Eighth Edition and job control (was Re: UNIX Futures)

[Mike Wexler]

In article <3493 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>> I think that a window should have both a logical and a physical size.
>> When the user resizes a window, that would only change the physical
>> size - the logical size would stay the same.  If the physical size is
>> smaller than the logical size, the windowing system should put in
>> scroll bars.
I agree to some extent.
>
>OK, imagine a text editor.  Assume that the logical size is the maximum size
>of a window.  You use the scroll bars to slide the physical window over the
>logical window.  Now what if you want to scroll the *editor's* window into
>the *file*?  Can you use the same scroll bars?  I suspect it can be done,
>but make sure your whizzo window system can do this.
Yes. So much for transparency.  I guess you could just send the generic
scroll key.  What?  You say there is no such thing.  Uh oh.
>
>So much for vertical scrolling.  What about horizontal scrolling?  I happen
>to prefer an editor which truncates lines at the margin, rather than
>wrapping them, but some people may prefer wrapping.  Such an editor has to
>know about the physical size of the screen - wrapping at the boundary of the
>logical screen seems a bit silly.
How about windows having attributes such as whether the physical window
size and logical window size are bound together.  The window system good
have a list of programs and what default attributes they override.
>
>What about a system which displays a fixed amount of data - say N rows by M
>columns of text, or a drawing of a certain size?  Such a system might very
>well want to scale this display to the size of its window, so that you can
>blow the display up by stretching the window.  (The Andrew system's terminal
>emulator, which emulates a 24x80 Heath H19 terminal, does exactly that.)
Yet another attrbiute(YAA).
>
>What about a program which has a display consisting of a main display
>subwindow, a command line, and a messages line, or something similar?  (For
>two obscure little-used programs which use the screen in this way, let's
>pick "vi" and EMACS.)  If I start up EMACS (or "vi") in a full-height
>window, and then shut that window down to the Sun standard 34x80, your
>scheme might very well put EMACS' status line and command/messages line
>(mode line and minibuffer) outside the window.  This seems silly.  It would
>make more sense to have the main display window be resized by EMACS, which
>is exactly what does happen on a Sun.
How about multiple windows?  Transparency? Whats that?
>
>I'm afraid this sounds like the putative benefits of not having something
>like SIGTSTP - you might say that you "don't have to" modify programs to
>know about being suspended, or having their window size changed, but what
>this really means is that you *can't* modify programs to know about this,
>even if doing so would give them a better user interface.  Sorry, but any
>system that buys "conceptual elegance" at the expense of making the person
>who uses the system had better be a LOT more conceptually elegant than a
>system which is more pleasant to use if it's to interest me - especially if
>I'm the person who has to use it.
Such a system could actually be pleasant to use, if it was designed and
implemented well.  Wouldn't it be nice if the same scroll commands worked
in Emacs(vi/fnorkel 2) and Suntools?  Wouldn't it be nice if Emacs(or others)
had overlapping and closable windows?  Have you ever wanted to scroll
backwards in a line oriented program(to see what did 45 seconds ago)?
Have you ever had a program that needed 132 characters?  Wouldn't it
be nice to be able to resize the window *AFTER* you run it and see the input
spread across the screen.  My point is that the proposed system, although
it would be very difficult to implement might be quite a bit more pleasant
to use then what is currently available. 
-- 
Mike Wexler
(trwrb|scgvaxd)!felix!peregrine!mike 		(714)855-3923