For quite a long time I've been dealing with a crippled terminal behavior when emacs -nw runs under screen on xterm. I found this link that solved it: http://alioth.debian.org/~twb-guest/Preferences/.screen.el I also added these to the xterm section which solves the problem for a few more key combinations. ("\e[1;5H" . [C-home]) ("\e[1;5F" . [C-end])) Reproducible: Always Steps to Reproduce: 1.run xterm 2.run screen 3.run emacs -nw 4.press Alt-left or other similar keys Actual Results: some garbage is printed Expected Results: alt left tells emacs to move one word backwards It'd be nice if this translation was implemented as default behavior in emacs considering how slightly annoying it has been for such a long time and it's so easy to solve. Not sure why this wasn't fixed upstream or if it affects upstream too, but I won't have time to investigate further. I just happened to run into the solution so I point it to you (in addition of adding it to my .emacs) in the hope it'd be useful and to be sure it doesn't get lost. I load it with something like: (load-library "screen") (before this I also tried to load the vcs-emacs but it didn't help, not the -9999 version though) emacs now running is version 23.3-r2 but it should be trivial to reproduce so I'm not attaching too much version info.
This is an 'xterm' problem for me, rather than a 'screen' one. Does emacs -nw work for you in a bare xterm?
Yes works perfectly on bare xterm. In fact if it didn't work then this translation in the linked file wouldn't work I guess, because those same codes are the ones visualized by C-v Alt-left in vim insert mode or bash. I've no real clue why this is needed in emacs, but it looks an emacs issue. bash receives alt/ctrl-left/right perfectly while inside screen. Only emacs inside screen needs this further translation... Really an annoyance for people using emacsclient -nw or emacs -nw -l ... like I do to edit stuff quicker than vim and flyspell and stuff like that. It's especially annoying on x11vnc where the repetition are turned off so missing alt-left/right is even more annoying than normal.
Hmm, well, I can't even get it to work in a bare xterm, so I can't really try to fix it within screen. I don't suppose "use another terminal" is a good solution for you =)
Actually, in case this is an alt/meta issue and you've got something in your profile to fix it, try adding this to your ~/.screenrc: shell -$SHELL The dash preceding the name of the shell makes it a login shell, and should load whatever normally gets loaded for xterm.
(In reply to comment #3) > Hmm, well, I can't even get it to work in a bare xterm, so I can't really try > to fix it within screen. Hilarius! We're in 2011 and we still can't even get those keybindings right out of the box... I guess everybody who needs patches their own .emacs, .Xresources and the upstream never gets consistent across the board. It can't be that you press CTRL-end CTRL-home and it won't work. Same with forward-word backward-word. They all work correct when you run emacs with X, M-< M-> too, and they also work correct for me now in both xterm + emacs -nw, and xterm + screen + emacs -nw (or emacsclient -nw) after that code has been loaded into emacs. I use stock gentoo with KDE, I didn't use xmodmap or anything. You however have to add some bits to .Xresources and then run xrdb .Xresources (which also should be the default IMHO) but these are well known and documented, if you search for eightBitInput you'll find zillon of stuff, anybody using xterm probably sets it by default to make it fully usable with bash. While the screen.el thing is a very new discovery to me, I never hoped things would actually work, so when I incidentally run into it I thought it was good idea to advertise it... XTerm.backarrowKeyIsErase: true XTerm.ptyInitialErase: true XTerm.vt100.metaSendsEscape: true XTerm.vt100.cursorBlink: false XTerm.vt100.eightBitInput: false > > I don't suppose "use another terminal" is a good solution for you =) Using another terminal didn't help too much, things didn't work out of the box with konsole and if you check the url this is a translation for rxvt too (which I didn't test) I tested urxvt too, and that had alt-left working out of the box with urxvt+screen+emacs-nw but then ctrl-end didn't work (but it worked without screen in the middle). So it didn't look a vast improvement and I still had no clue how to fix it. While with xterm now I also fixed the ctrl-home/end easily by just adding to intuitive lines... plus xterm + emacs -nw works perfect out of the box which sounds good. The solution I found at that url is pretty easy to add, maybe it should only be done upstream, I'm unsure how much these term things are distro specific or not, and I'm ok if nothing gets done on it, and we may hope someday it will be merged upstream (maybe already it already is, I didn't actually checkout and built emacs from their development branches). But hopefully thing will keep improving and if not there's this bugreport to document how to fix it :). BTW, the reason I use xterm (or urxvt) is those gui terminals wastes a few line of screen real estate on the bottom and top (top is easy to remove) and I don't need any tab considering I use screen... And this "screen" issue is the only problem I had left with standard gentoo xterm/emacs frankly.
(In reply to comment #4) > Actually, in case this is an alt/meta issue and you've got something in your > profile to fix it, try adding this to your ~/.screenrc: > > shell -$SHELL > > The dash preceding the name of the shell makes it a login shell, and should > load whatever normally gets loaded for xterm. my /etc/screenrc already has that. The stuff loaded by login shell is relevant for bash only. All the readline stuff always worked perfectly in bash under screen (well after disabling the 8 bit input in xterm through xrdb but hey that's so ancient I can't even tell when I added it, so I practically assume it as a default :). The only bindings not working were for emacs -nw under screen, I must have used it without that for years (and I guess at some point you just get used enough to it that you assume it's right to be broken), and I exclude login/non login shell can matter for that.
I tried with urxvt and Xfce's Terminal and I see some of the stuff you're talking about. I guess I never noticed it because I use C-a, C-e, M-b, and M-f in lieu of home, end, M-left-arrow and M-right-arrow respectively. It would definitely be nice if they worked by default, but it seems like fixing one breaks the other for me. Rather, a terminal where one works will have the other not. C-a has its own issues, being the default escape key for screen, but I've given up my ability to suspend a job and now use ^z for that.
(In reply to comment #7) > I tried with urxvt and Xfce's Terminal and I see some of the stuff you're > talking about. I guess I never noticed it because I use C-a, C-e, M-b, and M-f > in lieu of home, end, M-left-arrow and M-right-arrow respectively. > > It would definitely be nice if they worked by default, but it seems like fixing > one breaks the other for me. Rather, a terminal where one works will have the > other not. > > C-a has its own issues, being the default escape key for screen, but I've given > up my ability to suspend a job and now use ^z for that. I also got used to use C-a a for home, and C-e for end. Not so for alt-b/f because I use Alt-left/right all the time in bash and emacs under X. In fact I also got used to esc < and esc > before alt < alt > worked, I guess I still type esc < instead of ctrl-end but this is not good excuse not to make ctrl-end work too IMHO. In fact esc-left also work under screen, it's only alt-left who doesn't :). And in rxvt ctrl-end doesn't. The escape key being ctrl-a I don't mind I just press "a" twice, I've the same issue to deal with with screen under screen which I often run (first screen local, second screen remote). It's not a big deal as the /etc/screenrc talks about, I don't think emacs users would have any real benefit from changing the scape to be ^z or something, if you then end up in a different system using teh default escape, you won't feel ok. I don't think it's a big deal, especially considering home-end must work right, and sometime I use those... I'm just amazed right now probably for the first time all keys works as they should with xterm+screen+emacs -nw, and that requires this emacs code to be loaded to do a double translation or something... I don't understand fully what it does and who exactly is to blame for the failure before :)
Can you please try if it works in emacs-vcs-24.0.90? For Emacs 24, a terminal init file lisp/term/screen.el has been added (see upstream bug at <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2650>). This bug looks like a problem that should be addressed upstream. I'd rather not add any workarounds for it at the distro level.
Another question, do the keys work if you start screen with "screen -T xterm"?
No reply. Closing.
