Screen mistakingly catches Control-PgUp Control-PgDown

[Evan Carroll]

Binary package hint: screen

Tested on xterm, and gnome-terminal. (any terminal using TERM=xterm should work) (gnome-terminal will require you to un-map these keys from the gnome-terminal tabs)

Run in xterm to eliminate the chance of deficiency in gnome-terminal's implementation of xterm.

Test case (requires edgy; or vim7):
1) run xterm
2) run screen
3) run `vim -p 1 2`
4) Test Control-PageUp, Control-PageDown (:he <Control-PageUp>)

try to use the Control-PageUp, Control-PageDown to alternate tabs. This will not work, because screen is capturing and mutating C-PgUp. On my machine they get translated into ';~5' and '~5'.

Run outside of screen and you will get expected behavior.

[Evan Carroll (evancarroll)]

While this is a bug in my eyes, some people have told me the ctrl codes for Ctrl+PgUp aren't standardized in VT-100 anyway. This wasn't minor for me, as I use vim all the time, and like to be able to change tabs in the edit mode. I've also supplied a fix, this should work for the majority, if not all, of the installs.

put this in .vimrc
:nmap <ESC>[5;5~ <C-PageUp>
:nmap <ESC>[6;5~ <C-PageDown>

[Micah Cowan (micahcowan)]

Note: rxvt does not seem to work at all with control-page-up/down in vim, and sends \E[[5^ and \E[[6^ for them.

If you look at :he xterm-modifier-keys, you'll see that screen can only know that control-pgup/down are supported if it can detect that it is running under xterm (TERM is xterm or similar). I verified this by digging around in the vim source code. Vim uses special internal codes, when it detects that its terminal is fully xterm-compatible, to tell itself that the terminal supports modifiers on things like pgup/down.

The trouble is, that if vim detects that it's running under screen, there is absolutely no way for it to tell whether screen is running under an xterm or not, and so no way it can determine control-key support. So there is no way to make control-pgup/down work automagically under vim.

If you know that your own screen sessions will always only be under an xterm-compatible terminal, then your nmap commands will work; a little better might be:

:set t_kN=<ESC>[6;*~
:set t_kP=<ESC>[5;*~

This will enable your vim to recognize not only xterm's Control-pgup/down, but also pgup/down with other modifiers such as alt.

Closing this bug out, due to a lack of fixability. Perhaps if the terminfo database can someday be updated to include capabilities for such things, we can revisit this.

[Micah Cowan (micahcowan)]

The above suggestion won't work; use ^[ instead of <ESC> (since this isn't a mapping), by typing ^V ^[. I don't currently know of a way to do this without putting literal <Esc> characters into your vimrc.

[Evan Carroll (evancarroll)]

Excellent description. I wonder why vim assumes to have anything other than an a vt100 compat term if it has a non-specified TERM var; but, on a philosophical note, should a bug ever be rejected just because no one can think of a fix?

[Evan Carroll (evancarroll)]

non-specified/unknown

[Micah Cowan (micahcowan)]

:execute "set t_kP=\<Esc>[5;*~"

etc, may be used in lieu of my versions, to avoid literal escapes in the vimrc.

> I wonder why vim assumes to have anything other than an a vt100 compat term if it has a non-specified TERM var

Not sure what you mean: "screen" isn't a non-specified term, and it has terminfo capabilities. And, vim does in fact assume vt100 (ansi) if TERM isn't set. But, as you've already said, vt100 has no notion of Control-PageUp. The real problem is that there's just no way to specify, using terminfo or termcap, what Control-PageUp will look like in terms of control sequences.

The above isn't /precisely/ true: AFAICT, vim would recognize its special "*" notation even if it came from terminfo; it's just that using that syntax would then break pretty much any other terminal program's ability to recognize (regular) PageUps.

> on a philosophical note, should a bug ever be rejected just because no one can think of a fix?

*sheepish grin*

I'm not sure about that. You are certainly welcome to reopen this bug, if you'd like. I mostly closed it because I figured you'd be okay with doing that, given my explanation. I do think that, in a case where a fix is truly impossible in every sense of the word, closing the bug is entirely appropriate.

But in this case, a fix is, technically, not completely impossible; just very involved. The right (and AFAICT, only) fix for this would be to (1) enhance ncurses/terminfo to provide a way to specify how various special keys should look if they have modifiers; (2) enhance screen to support this mechanism and process/translate modifier/special-key combos; and (3) enhance vim to understand and support this mechanism. So, rather than open this general bug, perhaps opening these three bugs (consecutively, not simultaneously) would be preferable.

This really needs to happen at some point—or, if not this, I would love to see terminfo at least provide support for xterm-style or gpm-style mouse tracking (I just dealt with a similar bug involving vim's inability to detect mouse support in screen: fortunately, that one was fixable, but the ideal solution would still have been in terminfo).

I'll tell you what: let's leave this bug closed, and I'll file a bug against ncurses, and get some discussion going upstream. If I don't leave a comment on this bug pointing to the new bug within a reasonable amount of time, reopen it. :)

[Evan Carroll (evancarroll)]

You rock.

You don't have to reopen the bug, I just don't understand *enough* to completely grasp the problem to submit a bug against ncruses (something that I'd typically want to do.) Knowing that you do, and are, helps me sleep easy at night. =D All that I know about terms is from the gentoo discussion about getting gnome-terminal to report a non-xterm term type. From my limited understanding of terminfo, it seems the whole the thing is one big mess, from terminals faking xterm compliance, xterm compliant terminals report they *are* xterm, to a lack of functionality in terminfo for said terminals. It seems as if this is mega-problematic for developers, and the lack of design hits the users.

I do think I understand a bit from your description of the problem. I suppose terminfo must have something of a table of chords and corresponding intterupts (how it gets "notion") and maybe Contrl+PgUp/PgDown isn't one of them currently? Then screen, which knows it is attached to a xterm/vt100 term, doesn't translate Contrl+PgUp because that isn't specified in a ?terminfo vt100 spec.? Vim, using terminfo, sees it is attached to a "screen" term type, which says nothing of how to handle Control+PgUp and the problem propagates all the way to the application.

For an interesting discussion @ gentoo on terms - http://<email address hidden>/msg03804.html

If you have any other links that would help clairfy how applications interact with terminfo please do send them.

[Evan Carroll (evancarroll)]

>I'll tell you what: let's leave this bug closed, and I'll file a bug against ncurses, and get some discussion going upstream. If I don't leave a comment on this bug pointing to the new bug within a reasonable amount of time, reopen it. :)
Is it time to reopen this bug?

[Micah Cowan (micahcowan)]

Heh. Since the time this bug was filed, I've become an upstream co-maintainer for GNU screen ^_^

Thanks for your patience. I've only recently discovered the full truth of this issue.

As previously mentioned, there are three parts to this: (1) ncurses, (2) screen, and (3) vim. As it turns out, (1) was somewhat wrong, because terminfo has _long_ supported, via extension features, specification of various modified keys; however, the stock terminfo definitions from ncurses don't include control-pageup/pagedown, though they _do_ support control-left, control-right... Debian/Ubuntu's terminfo definitions don't include any of the extended features. So there would still be a terminfo enhancement to include those definitions (probably named kPRV5 and kNXT5).

(2) is more-or-less this bug, tracked upstream at savannah: https://savannah.gnu.org/bugs/?24076

(3) requires modifying vim to use terminfo entries, whereas it currently uses termcap entries. You'll probably have to convince Bram Moolenaar of that. A good start would be to file a bug (upstream, ideally, or at least reported to the mailing list; I don't think they have a bugtracker) to support terminfo's kLFT5, etc, names, to indicate (in that example) control-left-arrow. This is a fairly involved change in vim, so it might take some effort to get that going. I suspect folks may have already broached the subject of terminfo support for vim: it's possible that Bram nixed it. You might snoop around the mailing list archives to see if there's anything to dig up.

Note that none of these things are bugs, they're enhancements. It may be that Blueprints is a more appropriate place to track this, but I'm not really sure. If the bug-tracker's appropriate for these issues, then this should probably be split apart for the three different issues. If this one is reopened against screen, the title should be changed, as screen isn't actually catching or transforming anything: it's passing the escape sequence through as-is, without modification.

Hope that helps.