* Re: Terminal-local/client-local
2007-05-18 20:07 Terminal-local/client-local David Kastrup
@ 2007-05-20 14:21 ` Karoly Lorentey
0 siblings, 0 replies; 2+ messages in thread
From: Karoly Lorentey @ 2007-05-20 14:21 UTC (permalink / raw)
To: emacs-devel
David Kastrup wrote:
> 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.
I agree. We should have a finite, small set of variables with terminal-local
bindings, and that should be it.
> 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.
The full list of such variables on the multi-tty branch is as follows (new
variables are marked with an asterisk):
prefix-arg
last-prefix-arg
default-minibuffer-frame
last-command
real-last-command
* keyboard-translate-table
overriding-terminal-local-map
system-key-alist
* local-function-key-map
* local-key-translation-map
defining-kbd-macro
last-kbd-macro
Note that 'keyboard-local' would be a more precise term for these variables.
Terminals on separate screens of the same X server share their struct kboard,
and therefore the above variables share their bindings on them.
A few years ago there was a thread here on emacs-devel where we decided not to
make random variables such as `window-system' terminal-local, but to use
frame-local bindings wherever possible. I think that's a good idea and we
should keep it.
I went even further, and tried not to introduce new local bindings, but instead
made do with simple frame parameters ('environment, 'client) and terminal
parameters ('normal-erase-is-backspace) wherever possible. I believe that
(frame-parameter nil 'client) or a new `server-client' *function* is much
clearer than something like a frame-local `server-client' variable.
> 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.
Don't forget that Emacs supports use-cases where multiple users interact with
the same Emacs session at the same time. We even have packages in CVS for this
(see talk.el, for example). In multi-user sessions, it makes more sense to have
a terminal-local minibuffer frame, and things like `prefix-arg' clearly must not
be shared between users.
Personally I don't care for this use-case very much, but when I last brought up
the issue of struct kboard and single_kboard on emacs-devel, it was important
for others. I don't believe we should break it.
> 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.
Well, at least `default-minibuffer-frame' could be equally well implemented as a
frame-local variable. I would argue that the rest better remain terminal-local,
but we should think twice before introducing any new such bindings. Adding a
terminal or frame parameter (with possibly a few helpful accessor functions) is
usually a better solution.
> 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.
When there are multiple tty clients on the same tty device, Emacs creates a
separate struct terminal for each of them. (This lets each client have a
different set of frame configurations, and makes them individually suspendable.)
Struct kboard is not currently shared between these terminals, so these clients
have different bindings for terminal-local variables. This is more of an
accident than a feature, but it doesn't really affect anything, and would be
easy to change if necessary.
On the other hand, multiple clients on the same X display share struct terminal.
If desired, it wouldn't be hard to change this either.
In the world of local _parameters_ (not necessarily variable bindings), we have
- Frame parameters accessible with `frame-parameter'.
These are stored as a list in struct frame. Some of these parameters
have a corresponding frame-local Lisp variable, and Lisp code
can easily define more.
- Terminal parameters accessible with `terminal-parameter'.
These are stored as a list in struct terminal. We can not make
Lisp bindings for these parameters, but otherwise they have a
similar API as frame parameters.
- Keyboard-related stuff in struct kboard. Some terminals
may share their keyboard. There are special Lisp variables
for most struct kboard members. These are called
"terminal-local" in the existing documentation. Lisp code can not
define new terminal-local variables.
- Client parameters stored in `server-clients'.
There is no Lisp binding or public API for accessing these.
`server-client-get' and `server-client-set' is for internal
use inside server.el.
Each frame is on exactly one terminal, and each terminal has exactly one
keyboard. A terminal may have multiple frames and a keyboard may have multiple
terminals.
There is no C-level concept of clients; it is up to server.el to implement
something sensible. Currently there is a one-to-one mapping between tty clients
and tty terminals. However, X clients on the same display share both their
struct terminal and struct kboard.
> 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 see why we wouldn't be able to continue supporting "-c".
> 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.
I agree, and I would even go so far as to object against introducing
client-local Elisp bindings, or any new local binding flavour. I think we have
quite enough of these now.
--
Karoly
^ permalink raw reply [flat|nested] 2+ messages in thread