[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 18 May 2007 22:07:21 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)
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
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
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
David Kastrup <=