Which key combos are not possible in remote Emacs session because terminal interferes?

Which key combos are not possible in remote Emacs session because terminal interferes?

[Chris Seberino]

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

Which key combos are not possible in remote Emacs session because terminal interferes?

Is there a table or list somewhere?

cs

Re: Which key combos are not possible in remote Emacs session because terminal interferes?

[Eli Zaretskii]

> Date: Fri, 6 Feb 2015 23:48:22 -0800 (PST)
> From: Chris Seberino <cseberino@gmail.com>
> 
> When using Emacs on a remote server by SSH-ing, not all key combos
> can be used as shortcuts like locally.
> 
> Which key combos are not possible in remote Emacs session because terminal interferes?

Only characters are possible on a TTY.

> Is there a table or list somewhere?

No, because it depends on the terminal software.  Look under
lisp/term/ for the Lisp module that supports your terminal emulator
(likely, xterm.el), where you will find additional non-character keys
that are supported via escape sequences.

Re: Which key combos are not possible in remote Emacs session because terminal interferes?

[Bob Proulx]

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
possible.

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.

  XTerm*metaSendsEscape:true

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
limitations.

> 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.

Bob

Re: Which key combos are not possible in remote Emacs session because terminal interferes?

[Philipp Stephani]

For reference, the full list of the escape sequences supported by xterm and
compatible emulators is at
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html. Unfortunately
besides Ctrl and Meta no modifier keys can be encoded, though in theory it
shouldn't be too hard to define additional escape sequences for Super,
Hyper and Alt.

Bob Proulx <bob@proulx.com> schrieb am Sun Feb 08 2015 at 03:16:44:

> 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
> possible.
>
> 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.
>
>   XTerm*metaSendsEscape:true
>
> 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
> limitations.
>
> > 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.
>
> Bob
>
>

Re: Which key combos are not possible in remote Emacs session because terminal interferes?

[Hikaru Ichijyo]

Bob Proulx <bob@proulx.com> writes:

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

Yes, true.  On Linux/X11/x86, I'm able to get "Super" from the Windows
key.  This seems to be already preconfigured, as I didn't have to do
anything to get that behavior.  My convenience key bindings that I've
setup with the Super key are only available when I'm in X though because
of the behavior your describing.

[...]
> 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.
>
>   XTerm*metaSendsEscape:true
>
> 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.

I've found that on Linux, (unlike the Super/Windows key), use of
Alt/Meta over SSH works transparently and as expected both in xterm
windows and on the VTY console.  I don't know which mechanism they're
using to achieve that, "high-bit" or sending an ESC first, but it works,
and I like it.  I didn't have to do anything myself to configure it to
act this way.

> 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.

I remember the bad old days of having to do that in a terminal program
while connected by dialup modem to a machine that had Emacs on the
site end.  Escape-this, Escape-that...Escape play a D-minor seventh
diminished guitar chord while holding down the right pedal and humming a
traditional Nepalese song and waving your arms.  Having a real Meta key
that works over remote session is nicer.  :)

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
					--Thomas Paine

Re: Which key combos are not possible in remote Emacs session because terminal interferes?

[Chris Seberino]

Wow.  Thanks for the thorough reply.

I have several shortcut keys for numerous commands.

I guess I'll just have to go one by one and see which are working still.

Then go one by one and test alternates to see if *those* work.

cs