Re: emacs in a terminal : problems with control

[Willard Rafnsson]

On Jun 24, 12:45 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Willard Rafnsson <willardt...@gmail.com> writes:
> > I am one of those weirdos that likes running emacs from a terminal.
>
> What is a "terminal"?
> How does it communicate with the "host"?
> What protocols does it use?
>
> You may compare your answers with those you would give for a
> "console", or a "X11 server".

What is a "console"?
How does it communicate with the "host"?
What protocols does it use?

:-P

A "terminal" may refer to a "system console". Which is what I am
referring to.

Just like the word "terminal", the word "console" can refer to many
different things. I have seen both words used for the concept "system
console". It is tortuous to write unambiguously in the English
language, which is why I sometimes allow vaguery to creep in, and
leave it as an exercise to the reader to interpret my statements
correctly (this is common practise in day-to-day speech and writing,
and people are usually pretty good at interpreting ambiguities
correctly from context).

If there are other statements you want me to clarify, then feel free
to point them out.

Anyways, to answer your three questions:

1. By "terminal", I mean "system console".

I am running

$ emacs -nw

from the prompt of a bash shell, (usually) running in the terminal
emulator called gnome-terminal.

2. and 3. are less important at the moment (I think it is wise to
solve my problem first locally, and then see what problems arise when
I start editing on remote servers).

Sometimes I run

$ emacs -nw

on a remote server through SSH. Sometimes in a gnu-screen, which in
turn is run on a remote server through SSH.

>
>
>
> > I
> > always do this because I sometimes must (when editing remotely through
> > SSH), so I won't have to switch between a graphical editor and a
> > terminal editor.
>
> > Usually, things work just fine. However, problems arise when I must
> > send a "control-something" (like "C-RET" and "C-,") command to my
> > editor. In graphical mode, this works fine. In a terminal, it does
> > not.
>
> > In the current terminal that I am using (gnome-terminal), typing "C-
> > RET" will send "C-j" to my editor. Furthermore, typing "C-," will send
> > "," to my editor.
>
> > A non-solution would be to "not use these commands". However, I am
> > using some major emacs modes (proofgeneral/coq-mode and agda2-mode),
> > which have keyboard shortcuts like this:
>
> >   "C-c C-RET"
>
> >   "C-c C-,"
>
> > These are very useful shortcuts, and I am crippled without them.
>
> The problem comes from the fact that there is no such control
> character as C-RET.
>
> A X11 server may detect the pressing of a Control key and the pressing
> of a RETurn key, and synthesize an event such as Control+RETurn, but a
> terminal is limited by the ASCII encoding where there are only control
> codes from 0 to 31.
>
> One theorical solution would be to use a terminal emulator that would
> be able to detect the pressing of a Control key and of a RETurn key,
> and to encode using a specific protocol this key combination to
> forward it to the application.  Then you would need to implement this
> protocol and decode it in the application (emacs).

How come emacs modes define behaviour for "C-RET" when pretty much all
terminal emulators, when you press "control+return" in emacs running
within it, by default do not send a signal to emacs which emacs
interprets as "C-RET"? Is it assumed by the emacs community that
everyone using emacs is running the graphical X emacs?
>
> I heard some work have been done in this direction in some version of
> xterm, but I don't have any URL at hand.
>
> > So far, I am getting around this issue by adding to my .emacs
> > configuration file an entry which makes emacs behave as expected when
> > emacs receives this incorrect command:
>
> >   (global-set-key (kbd "C-c C-j") 'proof-goto-point)
>
> > I would, however, prefer not to have to do this for every major mode I
> > use. Furthermore, if a mode happens to use "C-c C-j", then this re-set
> > keybinding will override it.
>
> Another solution would be to use the X11 protocol instead of the ASCII
> terminal protocol.
>
> export DISPLAY=:0.0 ; ssh -Y -X user@remote emacs
>
> For this, you need a sshd on the remote that allows X11 forwarding,
> and a network fast enough to make it usable.  (Anything faster than a
> POTS modem will do, for emacs, since it's basically only text).
>
> > My question is the following:
>
> >  PROBLEM: How do I ensure that emacs correctly interprets a "C-X"
> > command, where X is *any* character?
>
> This is not your problem.  Your problem is how to encode C-X where X
> is any character.  For example, How do you encode C-龍?
> You may also want to be able to encode C-M-s-ζ.
>
> > A noteworthy detail here is that when I run emacs in an xterm, typing
> > "C-," will in fact send "C-," to emacs. However, typing "C-RET" will
> > send "C-<return>" to emacs. So the problem seems to be how the
> > terminal translates a CTRL-something to a key, and sends it to emacs.
> > So one solution could be to
>
> >  SOL.1: Make sure your terminal sends the right signals to emacs.
>
> > However, this may not be possible (I am not about to dig into the
> > belly of a terminal implementation, or to implement my own terminal
> > emulator).
>
> Unfortunately this is the only solution.  And also, you would have to
> make it so good that it is adopted by everybody!

I'll just put it on my unending list of things to do then ;-)
>
> > Alternatively, we could accept that a terminal sends CTRL-
> > something incorrectly to emacs / emacs interprets CTRL-something
> > incorrectly. Accepting this, the solution to this problem would be to
>
> >  SOL.2: Make sure emacs interprets the incorrect signals correctly.
>
> There is no incorrect signals.

Replace "the incorrect signals correctly" with "the signals
appropriately", then.
>
> Here are the ONLY control code that will ever exist in (7-bit) ASCII
> (on the left columns):
>
>        
> ------------------------------------------------------------------------
>        000   0     00    NUL '\0'                    100   64    40    @
>        001   1     01    SOH (start of heading)      101   65    41    A
>        002   2     02    STX (start of text)         102   66    42    B
>        003   3     03    ETX (end of text)           103   67    43    C
>        004   4     04    EOT (end of transmission)   104   68    44    D
>        005   5     05    ENQ (enquiry)               105   69    45    E
>        006   6     06    ACK (acknowledge)           106   70    46    F
>        007   7     07    BEL '\a' (bell)             107   71    47    G
>        010   8     08    BS  '\b' (backspace)        110   72    48    H
>        011   9     09    HT  '\t' (horizontal tab)   111   73    49    I
>        012   10    0A    LF  '\n' (new line)         112   74    4A    J
>        013   11    0B    VT  '\v' (vertical tab)     113   75    4B    K
>        014   12    0C    FF  '\f' (form feed)        114   76    4C    L
>        015   13    0D    CR  '\r' (carriage ret)     115   77    4D    M
>        016   14    0E    SO  (shift out)             116   78    4E    N
>        017   15    0F    SI  (shift in)              117   79    4F    O
>        020   16    10    DLE (data link escape)      120   80    50    P
>        021   17    11    DC1 (device control 1)      121   81    51    Q
>        022   18    12    DC2 (device control 2)      122   82    52    R
>        023   19    13    DC3 (device control 3)      123   83    53    S
>        024   20    14    DC4 (device control 4)      124   84    54    T
>        025   21    15    NAK (negative ack.)         125   85    55    U
>        026   22    16    SYN (synchronous idle)      126   86    56    V
>        027   23    17    ETB (end of trans. blk)     127   87    57    W
>        030   24    18    CAN (cancel)                130   88    58    X
>        031   25    19    EM  (end of medium)         131   89    59    Y
>        032   26    1A    SUB (substitute)            132   90    5A    Z
>        033   27    1B    ESC (escape)                133   91    5B    [
>        034   28    1C    FS  (file separator)        134   92    5C    \  '\\'
>        035   29    1D    GS  (group separator)       135   93    5D    ]
>        036   30    1E    RS  (record separator)      136   94    5E    ^
>        037   31    1F    US  (unit separator)        137   95    5F    _
>
> As you can see from the characters on the right columns, the trick is
> to reset the sixth bit from the code of the key when you type Control
> at the same time.

Thanks alot! This will prove useful if/when I decide to solve this
issue properly.
>
> > A third option, which is probably the easiest one, is to realize that
> > this is too challenging, and
>
> >  SOL.3: Make sure that emacs reacts correctly when seeing "C-
> > <return>", when emacs is run in an xterm.
>
> Emacs cannot see C-<return> in a terminal, because there is no code to
> encode this key combination.

At one point, pressing "control+return" would yield an error saying
that "C-<return>" was undefined. However, to emacs, "C-<return>" and
"C-RET" were apparently two different things. For some reason I cannot
reproduce this scenario now.

>
> > T(this seems to be the only problem with running emacs in an xterm.
>
> > I am writing this here because I do not know how to proceed with any
> > of these solutions, and am hoping someone here does.
>
> > Kind regards,
> > Willard.
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/

Thanks for your advice,

/Willard