Terminal-local/client-local

[David Kastrup]

I have been giving some more thought to the business of client-local
settings.  I remain of the opinion that we should not have both
client-local and terminal-local variables.

However, what is the state with regard to terminal-local variables?
Here we have the following information in uni-tty Emacs:

(info "(elisp) Multiple displays")

       Emacs treats each X server as a separate terminal, giving each one
    its own selected frame and its own minibuffer windows.  However, only
    one of those frames is "_the_ selected frame" at any given moment, see
    *Note Input Focus::.

       A few Lisp variables are "terminal-local"; that is, they have a
    separate binding for each terminal.  The binding in effect at any time
    is the one for the terminal that the currently selected frame belongs
    to.  These variables include `default-minibuffer-frame',
    `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'.  They
    are always terminal-local, and can never be buffer-local (*note
    Buffer-Local Variables::) or frame-local.

[...]

Now _if_ we are willing to entertain the idea of having several
"clients" that are supposed to be treated as semiindependent (whether
or not this is supposed to include process-environment) even if they
are on the same tty, what does this imply for things like
"default-minibuffer-frame"?  On the same text tty, there will never be
more than one frame active at the same time, so whichever frame is
active can make use of a minibuffer of its own.  What about frames
from different clients on the same X server and the other things?
Different personality, same personality?

I have to admit I am somewhat at a loss here.  For some of these
variables, the motivation to have them terminal-local appears somewhat
weak since, after all, even on a single X server, only one frame will
ever have focus.

I am not sure I understand the motivation for all of these variables
to be terminal-local, and how strong this motivation will be in every
case.

But _if_ we have some client-frame relationship exceeding that
necessary for C-x #, then maybe the concept of terminal-local should
apply to it: terminal-local variables should maybe be unique to the
combination of a tty AND a client: different clients imply different
terminal-local bindings, and different ttys (or active DISPLAY
variables) _also_ imply different terminal-local bindings.

_If_ someone can work out nice connected semantics for all those
variables that are already terminal-local in trunk that work even in
the case of multiple clients on the same tty, we could possibly just
let my objections to client-local behavior as an added complication
drop.  However, I would in this case quite wish that emacsclient
retained as an option "open in existing client/terminal" like the
default in unitty is, and that still is available as an option in
multitty.

I don't believe that we have room for _both_ terminal-local and
client-local variable spaces, but maybe the latter can be subsumed
into the former.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum