Terminal-local/client-local

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

Re: Terminal-local/client-local

[Karoly Lorentey]

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