[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Of keyboards and terminals
From: |
Stefan Monnier |
Subject: |
Of keyboards and terminals |
Date: |
Sat, 23 Feb 2008 20:30:56 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
We currently have a slightly odd situation:
In 99% of the cases, each keyboard object has a single terminal object
and each terminal has a single keyboard. But in some rare cases,
several terminals can share a single keyboard. See the same_x_server
function in xterm.c.
This can be the case when you have different connections to the same
X server. This can happen if you make a frame on unix:0 and then
another frame on localhost:0 and yet another on <myhostname>:0. This is
not very common, tho.
A more significant situation is when you have a multi-screen setup such
that you can make a frame on :0.0 and another on :0.1 and yet another
on :0.2. These *require* separate terminal objects (and separate
X connections).
So in those particular cases, Emacs shares a single keyboard object
between those different terminal objects. The intent of sharing
a single keyboard has mostly to do with the fact that once a command is
started, Emacs is put into "single-keyboard" mode so that all the input
coming from other keyboards is temporarily delayed.
As far as I can tell, this is the only benefit.
The problem is that variables like function-key-map are not
terminal-local (as people often think) but keyboard-local instead.
OTOH they're initialized per-terminal, and there is generally some
confusion between pr-keyboard and per-terminal objects and actions.
So I'm thinking of eliminating the special case that shares the keyboard
among different X11 connections to the same underlying server: the
sharing does make sense, but its benefit doesn't seem to justify the
resulting complexity.
Stefan
- Of keyboards and terminals,
Stefan Monnier <=