emacs in a terminal : problems with control
Willard Rafnsson
I am one of those weirdos that likes running emacs from a terminal. 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.
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.
My question is the following:
PROBLEM: How do I ensure that emacs correctly interprets a "C-X"
command, where X is *any* character?
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). 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.
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.
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.
Ista Zahn
another look at whether you can go the other way and use the graphical
editor for everything. You can edit remotely through ssh (using tramp,
its all quite transparent and amazing).
-Ista
Willard Rafnsson
This looks promising. Thanks for the tip; I'll take a look at this.
Currently, I am using xterm with some small configurations, and have
eliminated almost all the problems I had ("C-SPC" translates to "C-@",
which is the only issue I have noticed so far). Details can be found
here (where I asked the same question) :
http://www.linuxquestions.org/questions/showthread.php?p=4013210
Olive
For transparent access to remote file; I would suggest sshfs. Once
installed:
sshfs <remotemachine>:/path/to/directory /mnt/remote
And you see in /mnt/remote the files on the remote machine. It is
completely transparent for the OS and there is nothing to configure.
Olive
Pascal J. Bourguignon
> 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".
> 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).
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!
> 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.
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.
> 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.
> 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/
David Kastrup
> Greetings.
>
> I am one of those weirdos that likes running emacs from a terminal. 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.
Hm?
C-x C-f /username@host:localfile RET
What do you gain by letting the editor run remotely, when all you
actually want is the file access?
--
David Kastrup
Pascal J. Bourguignon
If the file is big, it's better to edit it remotely than to download it,
modify it and upload it. Of course, if you have a 10,000 Mb/s network
link between the two computers, it may not make a difference.
--
__Pascal Bourguignon__
http://www.informatimago.com
Ilya Zakharevich
>>> I am one of those weirdos that likes running emacs from a terminal. 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.
>>
>> Hm?
>>
>> C-x C-f /username@host:localfile RET
>>
>> What do you gain by letting the editor run remotely, when all you
>> actually want is the file access?
>
> If the file is big, it's better to edit it remotely than to download it,
> modify it and upload it. Of course, if you have a 10,000 Mb/s network
> link between the two computers, it may not make a difference.
I can see many other advantages too. Like positions of backup file,
and interrupted-edit files; behaviour when a connection is
interrupted; no need to retype usernames and hosts (which, in tcsh,
might be auto-completed) etc.
Yours,
Ilya
(who never uses remote C-x C-f, but remote emacs-through-ssh- I just
use xterm, which allows passing all the control chars)
Javier
holding the session in a remote computer, while I switch off the
computer at home.
In order to pass some key combinations I have to use an extended
version of /usr/share/keymaps/i386/qwerty/us.kmap.gz
I think xterm lets pass most of the control sequences (better than
gnome-terminal). If some key combination is not passed you will have
to modify ~/.Xmodmap
What it would be good is that the linux distributions would provide
extended versions of *.kmap.gz .Xmodmap files for passing more key
combinations.
Willard Rafnsson
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.
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'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.
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
Ilya Zakharevich
> I think xterm lets pass most of the control sequences (better than
> gnome-terminal). If some key combination is not passed you will have
> to modify ~/.Xmodmap
I think this may be confusing. You mean, probably
if some KEYS are not visible to X applications [check with xev],
one may need to set some stuff via xmodmap (on many distributions,
this can be done by creating/editing ~/.Xmodmap). If a KEY
COMBINATION is not treated by xterm in a way you want to be treated,
set resources via xrdb, as in
*.VT100.Translations: #override \
~Ctrl ~Meta <Btn2Up>: insert-selection(PRIMARY, CUT_BUFFER0, CLIPBOARD) \n\
<BtnUp>: select-end(PRIMARY, CUT_BUFFER0, CLIPBOARD) \n\
~Shift ~Meta Ctrl <Key>UP: string(0x1B) string("p") \n\
...
On many distributions, it can be made by putting text like this into
~/.Xresources.
> What it would be good is that the linux distributions would provide
> extended versions of *.kmap.gz .Xmodmap files for passing more key
> combinations.
Hmm, I know that on recent systems kbd in a console and in X are
controlled by the same mechanism (I even have it written somewhere
;-]; AHA: .Xcompose). Yes, it can be made to send strings on some
chords. Never tried to use it (it does not help that one needs to go
through extra hoops with GTK and QT, and that to get docs for this I
needed to read the C source code of X...).
Yours,
Ilya