[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which key combos are not possible in remote Emacs session because te

From: Bob Proulx
Subject: Re: Which key combos are not possible in remote Emacs session because terminal interferes?
Date: Sat, 7 Feb 2015 19:16:25 -0700
User-agent: Mutt/1.5.23 (2014-03-12)

Chris Seberino wrote:
> When using Emacs on a remote server by SSH-ing, not all key combos
> can be used as shortcuts like locally.

What key combinations are you wanting to use that are not available?

When using a local graphical interface every key press and release is
individually available for use.  Therefore any combination is

When operating over an ssh connection your terminal emulator is the
graphical interface.  Your terminal emulator reads your keys and sends
characters down the 8-bit serial interface over the network to the
remote emacs.  The remote emacs will operate as if it were on a serial
terminal using the terminfo/termcap specifications for $TERM and the
associated terminal database of terminal display capabilities.

The standard ASCII characters are self-explaining (and self-inserting,
haha) but only a small set.  Control characters are the character with
the 7th bit cleared, same as subtracting 0x40 hex from it.  For
example character 'H' is 0x48 hex.  Control-H is 0x8 hex.  Which
explains why Control-G is 0x7 the bell character.  The bell interrupts
something and rings the bell and so does Control-G in emacs.  Control
characters are fairly consistently implemented up through C-z but are
inconsistently implemented for the last few {, |, }, ~, DEL.  Those
control combinations tend not to work depending upon the emulator.

At one time the meta key set the "high" bit.  ASCII is a 7-bit
encoding leaving the 8th bit available to be set.  This now conflicts
with use of UTF-8 unicode and AFAIK this is no longer used anywhere by
anyone who cares about UTF-8 due to this.  I do not miss it.

Most terminals now encode the meta key as an escape sequence sending
the ESC character followed by the desired character.  M-w for example
(holding down Alt on a US-PC keyboard and pressing w) will be encoded
as an ESC w two character sequence.  This often needs explicit
configuration.  XTerm for example needs this resource set explicitly
or it will instend send the 8-bit value yielding different results.


Some people undoubtedly like the 8-bit Alt key behavior.  For example
it allows typing in many glyphs using the Alt key instead of the
Compose or AltGr keys using the international input methods.  It is a
personal preference but I prefer to have a working meta key for emacs
and I can enter the non-ascii characters using the Compose key.

Without a working meta key they would send all M- sequences by sending
ESC explicitly first.  ESC w is the same to emacs as M-w.  Any C-M-
something or M-C- something sequences will be ESC followed by the C-
something character.  For example C-M-r would be ESC C-r.

Also C-[ is the same as ESC.  A quick touch typist learns C-[ as way
to enter ESC without removing fingers from the home row.  C-[ w is the
same as C-w for example.  C-[ C-r would be the same as ESC C-r and the
same as C-M-r.

Some terminal emulators also interface with the mouse.  An abomination
as I am sure you realize but some terminal emulators will encode mouse
activity into the serial data stream.  This is again terminal emulator
dependent depending upon many things.

Hopefully the above gives some explanation and insight into working
with emacs.  Understanding that should explain why any particular key
combination is possible or not over an ssh connection.  The biggest
lever is not ssh but the terminal emulator you are using at the time.
Different terminal emulators have different capabilities and

> Which key combos are not possible in remote Emacs session because
> terminal interferes?
> Is there a table or list somewhere?

Every terminal emulator is different.  A similar question would be
could we generate a list of colors that are used by artists when they
paint.  It is similarly open-ended.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]