Re: Terminology in multi-tty primitives

["Stephen J. Turnbull" <stephen@xemacs.org>]

Richard M Stallman writes:

 >     I think you are wrong about suspend making no sense on GUI terminals:
 >     we have (in Emacs 23) suspend-frame that does work on GUI.
 > 
 > It does this by lumping together various different operations.
 > Really it is just a way of trying to make C-z do something meaningful
 > on window systems where suspending Emacs is not useful.
 > It is a useful command, but sheds no light on how to conceptualize the
 > interfaces at the Lisp level.

I used to agree with you, but The Kids These Days (ie, those who have
grown up with WIMPy interfaces) think of a window as a (foreground)
process.  If the window goes away, the process stops.  I think that is
well-based in psychology.  If Eli (the MS-DOS Ambassador to Emacs!) 
finds commonality there, there's *something* in common there.

In particular, on a GUI the difference between a kill -STOP'ed emacs
and one with no visible windows is hardly important to the user, who
must do something unusual to resurrect it.  So the "withdraw frame"
function (which happens to be called `suspend-frame') just keeps
withdrawing frames, and when the last one is withdrawn, emacs goes to
sleep.  On a X11-style GUI, this requires no additional work: no
window, no events, no Maya == Nirvana.  On a TTY, you need to suspend
Emacs to achieve enlightenment.  No big difference from the user's POV.

 >     Anyway, the examples I gave were just that: examples.  Here's another
 >     example: we have make-frame-on-display, make-frame-on-tty, and
 >     make-terminal-frame; and then we have make-frame that can do all of
 >     the above.  IMO, it's terribly confusing.
 > 
 > Would you like to propose a change for these, which people could consider?

The semantics are a bit delicate, but if you have/create a notion of
"current-terminal", which is the terminal from which input was last
received, then in practice most frames are created on that terminal,
and most of the rest have an implicit notion of "my terminal" (eg, an
emacsclient -nw process will use its controlling tty).  So give
make-frame a terminal parameter, and (make-frame) will use the current
terminal as default.  The general form will be

    (make-frame '((terminal DESCRIPTOR)
                  (terminal-type TYPE)))

where if 'terminal-type is absent, `make-frame' uses an heuristic to
guess it.  In particular, there should be a way to discriminate
between a human-oriented descriptor and an unambiguous internal one.

It seems to me that humans who know what they want will invariably use
a string descriptor, such as ":0" or "CON:" or "/dev/tty3".  So make
the internal type of terminals something else (the small integer
indexing a table of connections would do fine).  This internal type is
what `frame-terminal' (takes a frame argument), `get-terminal' (takes
a string and optional type argument, implements the guessing algorithm
used above, and calls `make-terminal' if an appropriate terminal
connection doesn't exist yet), and `make-terminal' (the more-or-less
internal function that does the heavy lifting) return.  Then the
general `make-frame' call above would be precisely equivalent to

    (make-frame '((terminal (get-terminal DESCRIPTOR TYPE))))

when DESCRIPTOR is a string.  Use of the internal type for DESCRIPTOR
in `get-terminal' should be an error.

Personally, I see no need whatsoever for `make-frame-on-...'
variants.  If they can't be removed for hysterical raisins, then at
least they can be deprecated in the documentation.