Re: emacs in a terminal : problems with control

Re: emacs in a terminal : problems with control

[Willard Rafnsson]

On Jun 23, 4:18 pm, Ista Zahn <iz...@gmail.com> wrote:
> I don't know the solution to your specific problem, but I suggest taking
> 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

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

Re: emacs in a terminal : problems with control

[Olive]

On Wed, 23 Jun 2010 19:18:24 -0400
Ista Zahn <izahn@gmail.com> wrote:

> I don't know the solution to your specific problem, but I suggest
> taking 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).

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

Re: emacs in a terminal : problems with control

[Pascal J. Bourguignon]

Willard Rafnsson <willardthor@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".


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

Re: emacs in a terminal : problems with control

[Pascal J. Bourguignon]

David Kastrup <dak@gnu.org> writes:

> Willard Rafnsson <willardthor@gmail.com> writes:
>
>> 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?

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

Re: emacs in a terminal : problems with control

[Javier]

I use mainly emacs in the linux console.  I can use gnu/screen for
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.


Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>>> 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.