Hi,

I run Emacs in text mode, inside GNUScreen, running in a
gnome-terminal. As a result, many key combinations don't get sent to
Emacs properly. For example, M-SPC gets to Emacs as C-M-j. Since I run
Emacs always like this, and basically I live inside Emacs, I would be
willing to spend some time trying to find a way out of this
problem. Searching the web has not really helped much...

Any help on where I should be looking?

Thanks,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Since the problem you described is with the terminal emulator that you
described the place to fix it would seem to be in the terminal
emulator.  It would seem that gnome-terminal is the deficient code in
the path between your keyboard and emacs.

For what it is worth I live inside emacs inside an xterm and M-SPC is
propagated correctly by xterm.  I do have "Meta Sends Escape"
(XTerm*metaSendsEscape:true) configured in my Xresources for xterm.

Perhaps using xterm would be a solution for you?

Bob

I am using xterm-extras.el
http://www.dur.ac.uk/p.j.heslin/Software/Emacs/Download/xterm-extras.el

And there are other mapping to simplify your works.

fwiw, here's the section of my key-config dealing with terminal
emulators, cascaded screen etc.

#+begin_src elisp
;; {{{2 input quirks

;; gnome-terminal 3.0.1 + screen 4.01.00devel (GNU8cf5efc) 2-May-06 on nzebook
(define-key input-decode-map (kbd "M-[ 1 ; 3 A") [M-up])
(define-key input-decode-map (kbd "M-[ 1 ; 3 B") [M-down])
(define-key input-decode-map (kbd "M-[ 1 ; 3 C") [M-right])
(define-key input-decode-map (kbd "M-[ 1 ; 3 D") [M-left])
(define-key input-decode-map (kbd "M-[ 1 ; 7 A") [C-M-up])
(define-key input-decode-map (kbd "M-[ 1 ; 7 B") [C-M-down])
(define-key input-decode-map (kbd "M-[ 1 ; 7 C") [C-M-right])
(define-key input-decode-map (kbd "M-[ 1 ; 7 D") [C-M-left])
;; terminal 0.4.7 (Xfce 4.8.0) +
;; screen 4.01.00devel (GNU8cf5efc) 2-May-06 on nzebook
(define-key input-decode-map (kbd "M-O a") (kbd "C-<up>"))
(define-key input-decode-map (kbd "M-O b") (kbd "C-<down>"))
(define-key input-decode-map (kbd "M-O c") (kbd "C-<right>"))
(define-key input-decode-map (kbd "M-O d") (kbd "C-<left>"))
(define-key input-decode-map (kbd "M-[ 1 ; 5 A") [C-up])
(define-key input-decode-map (kbd "M-[ 1 ; 5 B") [C-down])
(define-key input-decode-map (kbd "M-[ 1 ; 5 C") [C-right])
(define-key input-decode-map (kbd "M-[ 1 ; 5 D") [C-left])
(define-key input-decode-map (kbd "M-[ a") [S-up])
(define-key input-decode-map (kbd "M-[ b") [S-down])
(define-key input-decode-map (kbd "M-[ c") [S-right])
(define-key input-decode-map (kbd "M-[ d") [S-left])
;; urxvt v9.11 - released: 2011-05-02 +
;; screen 4.01.00devel (GNU8cf5efc) 2-May-06 on nzebook
(define-key input-decode-map (kbd "ESC M-O A") [M-up])
(define-key input-decode-map (kbd "ESC M-O B") [M-down])
(define-key input-decode-map (kbd "ESC M-O C") [M-right])
(define-key input-decode-map (kbd "ESC M-O D") [M-left])
;; urxvt v9.11 - released: 2011-05-02
(define-key input-decode-map (kbd "ESC M-[ A") [M-up])
(define-key input-decode-map (kbd "ESC M-[ B") [M-down])
(define-key input-decode-map (kbd "ESC M-[ C") [M-right])
(define-key input-decode-map (kbd "ESC M-[ D") [M-left])
(define-key input-decode-map (kbd "ESC M-O a") [C-M-up])
(define-key input-decode-map (kbd "ESC M-O b") [C-M-down])
(define-key input-decode-map (kbd "ESC M-O c") [C-M-right])
(define-key input-decode-map (kbd "ESC M-O d") [C-M-left])

;; urxvt v9.12 - released: 2011-06-29, ssh
(define-key input-decode-map (kbd "M-[ a") [S-up])
(define-key input-decode-map (kbd "M-[ b") [S-down])
(define-key input-decode-map (kbd "M-[ c") [S-right])
(define-key input-decode-map (kbd "M-[ d") [S-left])

;; (define-key input-decode-map (kbd "M-O 3 A") [M-up])
;; (define-key input-decode-map (kbd "M-O 3 B") [M-down])
;; (define-key input-decode-map (kbd "M-O 3 C") [M-right])
;; (define-key input-decode-map (kbd "M-O 3 D") [M-left])
#+end_src

It feels a bit kludgy, but well, it works…

--
Philipp Haselwarter

Angel de Vicente <ang...@iac.es> writes:

Hi Angel,

I use GNOME terminal (3.2.1), too, and M-SPC works just fine.
Basically, mostly all keybindings work just fine, except some that
contain non-alphanumeric characters, e.g., C-< is interpreted as just <,
C-? is interpreted as DEL (!)...

Bye,
Tassilo

Why not use a GUI based emacs?

Hi,

I tried, and it certainly was more promising (out-of-the-box) than
gnome-terminal, but not all combinations were propagated correctly, and
when I added gnu screen, then things got pretty bad again, so I was
hoping for a way to correct all the keymappings in some other way.

Thanks,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Hi,

thanks, I will give it a try. Do you find that all key combinations work
this way? Did you ever try inside a gnu screen session?

Thanks,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Hi,

I didn't realize I was using such an outdated gnome-terminal version
(2.32.1). I guess it is time to upgrade...

Thanks,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Hi,

[...]

Great. If I don't find any other way, I think this should do it. I guess
I can just incrementally build the list of sequences as the need
arises, and soon I will have all the correct keymappings for my
environment.

Cheers,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Am 3.2.2012 um 08:48 schrieb Tassilo Horn:

That's correct behaviour. C-? is used as DEL since decades in GNU Emacs. At least when run in real terminals...

--
Mit friedvollen Grüßen

  Pete

If all else fails read the instructions.
                                - Donald Knuth

I used tmux, it works. But you need to makes sure your terminal
forward the keybinding as you want. For double checking about this,
you can install "libncurses", and write some code like in my post
(http://setter.blogspot.com/2012/01/macremote-emacs.html) to make
sure.

Good luck

Best Regards,
Xiaofeng

On Fri, Feb 3, 2012 at 1:42 AM, Angel de Vicente <ang...@iac.es> wrote:

Oh well.  Nothing ventured, nothing gained.

I use screen a lot too but haven't run into key issues.

Out of curiosity, what cases did you encounter that were problematic?

Of course!  Good luck in your search.  I will be interested to hear
of your results.

Bob

One reason is because logging in over a high latency connection to a
server on the other side of the world and trying to throw the X11
display back over the very slow global Internet is a test of patience.
Not to mention other issues such as those of security.  Using a text
terminal is much more efficient of bandwidth making the interactive
response fast and just the right solution.

Bob

That's possible and one major reason I seldomly use emacs(client) in a
terminal for anything more than a quick edit.  I've bound frequently
used commands to C-<non-alnum-key> bindings, because those are mostly
undefined by default.  But then it's a pain for me to have them not
available in terminal emacsen.

Bye,
Tassilo

I can attest that for remote editing -- even across town in one of the
most technologically enabled areas of the US -- X emacs is less
satisfactory than emacs in a text terminal.

Silvio

Yes, X11 forwarding is clearly not the way to go.  But why not open
files on the remote server using TRAMP which comes with emacs?
Similarly, you can have many remote shell buffers as well.  That works
very good for me.  Hey, I even read PDF files and view images on remote
machines using TRAMPed dired, doc-view, and image-mode.

Bye,
Tassilo

I don't even install X11 libraries on server machines.

And I use text consoles for the machine near my elbow too.  The
overhead of starting up X is significant.  Text mode with a
conservative startup customization will be almost instantaneous.

First because that would require a second window and I would need to
switch back and forth between my remote logged in terminal window and
my local emacs editing window.  Sure if you want to keep switching
windows all of the time then many people keep an emacs server running
continuously.  That is common.  That's fine.  But if you just need to
log into a system and do some light weight administration then you
don't want to have to set up a continuously running emacs server on
your desktop first.  In that case you just want to edit a file.  Sure
I could [n]vi the file for a quick edit but I want to use emacs to
edit the file not vi or nano or other editor.  Therefore I will log
in, do what I need to do, use emacs to edit files, and then log out.

Secondly for reasons of speed.  Even on fast machines and fast
connections using tramp to edit a file can take many seconds while it
is setting up the connection.  And if this was a quick one-off task
then I may not have set up my ssh-agent for ssh rsa keys yet.  That
will require an additional pause while I enter my ssh rsa passphrase
again.  In the time it takes to do this I may have already finished
using emacs to edit the file in text mode, done whatever else I needed
to do, logged out and moved on.  But if I am going to sit for hours
working on a task then the overhead of starting tramp is insignificant
and the benefits you mention of multiple buffers and so forth work out
in favor of doing that instead.

That is all perfectly understandable and reasonable for the types of
tasks that you are doing.  But not everyone has the same work to do.
Other tasks require other work flows.  For example I can't recall a
time that I have ever looked at a pdf document on a remote machine
that I had logged into remotely to do some system administration work.
That case of having pdf documentation to which I would need to refer
to would just would never occur.  I would always be looking at those
types of documents locally on my desktop.  And would also have the web
available for better documentation.

In a different venue some people would suggest using sshfs to mount a
remote system in a local userland filesystem.  Then all remote files
appear to be local.  At the end of the task the filesystem can be
unmounted.  That is yet another different way of working that works
quite well.

Bob

In my case, the answer is that editing files is only part of what I do
remotely. I keep an ssh window open on the remote host anyway; it
makes little sense to then use a *local* invocation of emacs to open a
remote file (with the corresponding overhead of transfer protocols,
mimencode and all that jazz).

Conceptually, too, it's cleaner if each of my (color-coded) text
windows is acting on a single host.

TRAMP sounds terrific, but it seems to be meant for a different sort
of workflow.

Silvio

Yes, I frequently keep a TRAMP dired or shell buffer open on remote
hosts.  In such a buffer, even completion after C-x C-f defaults to the
remote directory of the dired current buffer or the shell buffers cwd.

You could use one frame per host, and also have the frames colored
differently.  But I don't want to evangelize anyone.  I was just curious
why many experienced emacs users don't use TRAMP.  In my experience, it
enormously matured over the last years from a slow and flaky
implementation of a good idea to a highly usable and convenient tool.

Bye,
Tassilo

Am 3.2.2012 um 21:03 schrieb Tassilo Horn:

Because the ASCII "protocol" is so limited. Would 8-bit controls give you more? (Well, another 32...) You would then need to press the Esc key many times...

--
Mit friedvollen Grüßen

  Pete

Wer nichts zu verbergen hat, hat schon alles verloren.
                                (Juli Zeh)

Hi,

In my case, more than a matter of speed is a matter of convenience
(though speed also counts). At work I fire up a gnu screen session, and
inside it I have 5-6 'terminals', all running emacsclients giving me
different aspects of my work (mail, agenda, documentation, programming,
other, etc.). When I go to another office, home, etc. I just connect
through ssh to my workstation, reattach to gnu screen, and I have
*exactly* the same environment I was using at my office. I can do some
work, and next day at my office I'm exactly where I left it at home. For
me this is invaluable... (I have tried doing the same with xpra and
Emacs in X, but then the speed was the problem...).

Cheers,
--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

Hi,

Right now I'm using a lot org-mode, so I would like to be able to send
M-SPC and C-M-SPC to Emacs.

With my versions of gnome-terminal and screen M-SPC and C-M-SPC get to Emacs as
C-M-j (for the fist one I can use ESC-SPC, but ideally I want to get all
keybindings working, so I don't have to take it into consideration when
reading Emacs/org-mode, etc. documentation.

Will share if I get somewhere...
--
Ángel de Vicente
http://www.iac.es/galeria/angelv/          
--------------------------------------------------------------------------- ------------------
ADVERTENCIA: Sobre la privacidad y cumplimiento de la Ley de Protección de Datos, acceda a http://www.iac.es/disclaimer.php
WARNING: For more information on privacy and fulfilment of the Law concerning the Protection of Data, consult http://www.iac.es/disclaimer.php?lang=en

Angel de Vicente <ang...@iac.es> writes:

As someone else pointed out, and I concur with the thought, xterm
out-of-the-box is better for keys than gnome-terminal out-of-the-box,
at least in the version of Ubuntu I'm using.  With xterm a small
amount of attention to X11 resources can make it even better.

                                    -- Bill

On 2012 February 3 Tassilo Horn wrote:

  [brevitized]

  ----->> *snip* <<-----

I also live in emacs (no X) on 2 small networks of computers connected via an
in-house meta-network.  My housemate and I regularly transfer files from
machine to machine, subnet to subnet wherever there is disk space or specific
capability.

Recently he acquired some new machines and installed the latest Debian
distributions with emacs21 and/or 22.  Since I've been running emacs 19.34 for
decades (its practically perfect) I was horrified when my usual method of file
transfer - ange-ftp - was replaced by tramp on the new machines (which do nice
things like display video files on a previously-vacant TV channel).

Transfer times between 2 machines in the same room (on the same subnet) now
take eons and for large file transfers, Tramp demands repeated re-logins.

        This is an insanely complex nonsolution to a simple nonproblem.

How do I use just ange-ftp for these in-house transfers without disabling the
ability to use tramp if I ever  need it?

Is tramp actually good for anything useful?  If not, how do I disable it
permanently for myself when using his machines?

If it is useful, can it be sped up?  I've had faster FTP transfers between MIT
and Finland when the 2 countries were connected by one shared 56k line across
an ocean!  The 2 computers I refer to are 4 feet apart!

My housemate is learning emacs, but his default is vi (shudder), netcat, and
packet radio (which takes longer than tramp but lets one sleep through
overnight transfers).

He didn't install the .el files.

Thanks

.Tami
 .signature: syntax error at line 1: `(' unexpected