| Summary: | x11-terms/xterm-232 breaks cursor keys in vim | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Petr Pisar <petr.pisar> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | antoine.mechelynck, bugs.gentoo.org, chrjim, coldwind, dickey, enkil, jiri.pittner, juraj.vitko, mmokrejs, vim |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | xterm-232.ebuild --disable-tcap-query | ||
|
Description
Petr Pisar
2008-03-06 23:38:58 UTC
I have also observed this bug on my computer: Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r6 i686) ================================================================= System uname: 2.6.22-gentoo-r6 i686 Genuine Intel(R) CPU T2500 @ 2.00GHz Timestamp of tree: Fri, 07 Mar 2008 10:16:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.4.4-r9, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3, 2.17-r1, 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4m -msse2 -pipe -fno-omit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4m -msse2 -pipe -fno-omit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.sh.cvut.cz/MIRRORS/gentoo ftp://mirror.switch.ch/mirror/gentoo/ http://gentoo.supp.name/ " LANG="C" LINGUAS="sk cs de nl" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/scratch/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/gnuradio /usr/portage/local/layman/erazor /usr/local/portage /usr/local/overlays/erazor-zone.de" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac aalib ac3 acl acpi alsa amr arts berkdb blas bluetooth bonobo bzip2 cairo cddb cdparanoia cdr cli cracklib crypt dbus dri dv dvb dvd dvdnav dvdr dvdread eds emboss encode esd evo exif fam ffmpeg firefox fortran ftp gcj gd gdbm gif gnome gphoto2 gpm gps gstreamer gtk hal http hwac3 icc iconv ieee1394 imagemagick imap ipv6 isdnlog jabber java javascript jpeg jpeg2k kde kerberos lapack ldap lesstif libwww lirc lm_sensors lprng mad mbox midi mikmod mime mmap mmx mozilla mp3 mpeg mpi mudflap mysql nas ncurses nls nptl nptlonly nsplugin obex ogg opengl openmp oss paste64 pcmcia pcre pdf perl plotutils png posix pppd python qt3 qt3support qt4 quicktime readline real reflection samba scanner sdl session sharedmem smartcard sndfile sockets socks5 sox spell spl sse sse2 ssl svg svga tcl tcltk tcpd tetex threads tiff tk truetype unicode usb usrp v4l v4l2 vanilla vcd vorbis wifi win32codecs wxwindows x86 xine xml xorg xpm xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sk cs de nl" USERLAND="GNU" VIDEO_CARDS="radeon fglrx vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS I've found that the regression appeared first time in version 230. Unfortunatelly, its changelog is very long [http://invisible-island.net/xterm/xterm.log.html#xterm_230]. I suspect item "synchronize terminfo with ncurses" which could explain dependency on TERM variable. Created attachment 145772 [details, diff]
xterm-232.ebuild --disable-tcap-query
This patch removes --enable-tcap-query which is responsible for misunderstanding between vim and xterm. With patched ebuild vim works again but it could have strange effects.
Now this xterm-230 changelog line seems much more promising:
* extend configure options --enable-tcap-query and
--enable-tcap-fkeys to send cursor- and editing-keypad keys
modified according to the keyboard (or termcap) selection for
shift, alt, control, meta.
How's it work in 234? Disabling that configure option doesn't sound like a good idea to me. (In reply to comment #4) > How's it work in 234? The same problem. Actually, I don't know if the bug lies in xterm, termcap db or vim. xterm has changed, but that does not prove that the problem is in xterm. On Mon, Apr 07, 2008 at 11:14:47AM +0200, Martin MOKREJŠ wrote:
> > Hi Thomas,
> > once again, would you please spot your comments on this?
> > I can post your answer to the bugzilla, if you do not wish to
> > play with account creation. ;-)
> > http://bugs.gentoo.org/show_bug.cgi?id=212546
The changes in terminfo wouldn't make any difference.
If someone's pressing the shift key while pressing a cursor key,
it'll send something that vim may interpret differently.
I seem to recall comments that some reduced-functionality keyboards
for laptops would require a shift to use common features...
(This doesn't appear to be talking about another recent problem where
vim did not parse some of the extended key sequences properly).
--
Thomas E. Dickey
Vim arrows still do not work in =x11-terms/xterm-232 =x11-terms/xterm-234 =x11-terms/xterm-235 Sticking to version 229. Rereading the initial report - the problem is that vim is not handling the modified cursor keys (which have been a feature of xterm well before #229). As I understood the vim bug-report, it was not parsing the incoming escape sequence - but with this report it seems that having the data from the terminal description also breaks vim. (Since xterm is working as designed, and ncurses works with this too, it's really a problem with vim). Tried recent xterm ~237 and the bug is still there. 229 seems to be the last not affected. If it's vim's responsibility, stil does not work in vim 7.2.021 Jiri As far as I know, we're still discussing modified (e.g., shifted) arrow keys. There's more than one factor: a) vim's mis-parsing of function key strings containing ';' b) vim's use of tcap-query (which will return strings for shifted-arrow keys but not control-arrows, etc - for those terminfo is needed) c) whether the terminal database matches xterm's behavior (or not, possibly confusing vim) d) user's key mappings (a possibility since only a few are reporting the problem). xterm's source has a test-script which can show the information from (b). The 'tack' program can be used to verify (c). At the moment (Debian/testing), I have vim 7.1.314. That uses the tcap-query feature to ask about several keys - but not any of the shifted arrow keys. At the time of the original report, I did run vim w/o seeing a problem. Now, I do see left/right arrow acting as word-movement. On investigation, the problem I see is this: if xterm is started with the vt220 keyboard (not the default), then shifted arrows return the same string as unshifted arrows. Neither vim nor xterm take this into account - xterm returns the string (though it probably should report a failure since only one of the termcap codes should work), and vim does not notice that the unshifted/shifted strings are the same. So vim assigns the function for shifted arrows to be the string returned by unshifted arrows. If xterm is started with the default keyboard, the strings will be different, and this problem is not seen. Should be fixed in 239. Thomas, thanks for referring to it in the change list! (In reply to comment #14) > Should be fixed in 239. > > Thomas, thanks for referring to it in the change list! > Unfortunaly, it's still behaves incorrectly on my system. (In reply to comment #15) > (In reply to comment #14) > > Should be fixed in 239. > > > > Thomas, thanks for referring to it in the change list! > > > Unfortunaly, it's still behaves incorrectly on my system. > Same problem here. If I start (u)xterm with the default keyboardtype, the arrow keys in vim behave like b/w. If I start xterm with -kt vt220 everything is fine. If I understand comment #13 correctly, it should be the other way around? I didn't have this problem until a few days ago when I updated parts of the x server (x11-base/xorg-server-1.5.3-r1, x11-drivers/xf86-input-keyboard-1.3.2). Regarding comment #16 (and indirectly, #13): there are two changes since patch #237 which may be related: a) turn on configure tcap-query feature by default, add resource allowTcapOps to make this runtime enabled/disabled. b) modify tcap-query feature to not return data for shifted cursor-keys when the keyboard type is set to vt220, since returning the same string for shifted/unshifted keys may confuse some applications (GenToo #212546). The latter is supposed to avoid the case where vim sees termcap definitions for shifted/unshifted keys that are really the same. The comment in #16 seems to agree that is working - but goes on to say that starting xterm with a keyboard type which _could_ have different strings isn't working with vim. The former change wasn't motivated by this report (but several other people's request). So that turns on the compiled-in tcap-query feature. But I added a resource allowTcapOps to let this be disabled at runtime. Perhaps disabling that would help here - (In reply to comment #17) I am sorry that I cannot be of more qualified help. I tracked down the change I made: I am using an US keyboard but I need german umlauts. One entry in my ~/.Xmodmap maps keycode 113 (right alt) to Mode_switch. If I use that configuration, the behaviour of vim is as I described earlier and I have to use "uxterm -kt vt220" to make vim behave the way it should. If I skip the part where I map keycode 113 to Mode_switch I do not have to use the -kt vt220 switch (I assume that it is implicitly using -kt default) and vim behaves as it should. You are right that switching XTerm.vt100.allowTcapOps to false or invoking xterm with -kt vt220 makes vim happy. Regarding comment #17 I have AltGr mapped to AltR in us layout and to ISO_Level3_Shift in cz layout. However vim is confused in both layouts. If I understand the problem right, xterm is o.k. and the one who should be fixed is vim. I can submit bug to vim developers however I don't expect any useful feedback (after browsing vim mailing list). I see - then it's probably that the AltGr is one of the modifier keys that xterm adds to the string, while vim isn't working properly with it. I'm considering making the resource allowTcapOps default to false (but leaving the configure script as is). That would allow people who want the feature to use it. must be a vim bug, doing: touch ~/.vimrc fixes the thing! (at least in xterm, didn't try the console) (In reply to comment #19) [...] > If I understand the problem right, xterm is o.k. and the one who should be > fixed is vim. I can submit bug to vim developers however I don't expect any > useful feedback (after browsing vim mailing list). There are several Vim mailing lists. For bug reports, either post on the vim_dev list (mirrored on the vim_dev Google Group) or write directly to Bram Moolenaar. See also ":help bugs" within Vim. As always, it's better to describe in detail when the problem happens and when it doesn't. (In reply to comment #21) > must be a vim bug, doing: > > touch ~/.vimrc > > fixes the thing! (at least in xterm, didn't try the console) > Hm. Does it makes a difference whether you start Vim as vim -C -u NONE or vim -N -u NONE (no vimrc or plugins in both cases, but in 'compatible' mode in the one case, and in 'nocompatible' mode in the other)? > Hm. Does it makes a difference whether you start Vim as
> vim -C -u NONE
> or
> vim -N -u NONE
> (no vimrc or plugins in both cases, but in 'compatible' mode in the one case,
> and in 'nocompatible' mode in the other)?
>
vim -C -u NONE -- same behavior as without .vimrc
vim -N -u NONE -- same behavior as with .vimrc
Also, when it's "fixed" by using an empty .vimrc, the Backspace key doesn't work in the INSERT mode.
(In reply to comment #23) > > Hm. Does it makes a difference whether you start Vim as > > vim -C -u NONE > > or > > vim -N -u NONE > > (no vimrc or plugins in both cases, but in 'compatible' mode in the one case, > > and in 'nocompatible' mode in the other)? > > > > vim -C -u NONE -- same behavior as without .vimrc > vim -N -u NONE -- same behavior as with .vimrc > > Also, when it's "fixed" by using an empty .vimrc, the Backspace key doesn't > work in the INSERT mode. > So we know that setting 'nocompatible' makes the difference. Now this option sets a lot od additional options (see ":help 'compatible'"). You might try to find out which one(s) is/are critical -- 'esckeys' maybe? Note that running in 'compatible' mode, or without vimrc, makes Vim try to mimic the behaviour of legacy vi. If the behaviour of Vim when 'esckeys' is off (see ":help 'esckeys'") describes what you're experiencing, then it's not a bug: it's a feature. (In reply to comment #20) > I see - then it's probably that the AltGr is one of the modifier > keys that xterm adds to the string, while vim isn't working properly > with it. I'm considering making the resource allowTcapOps default > to false (but leaving the configure script as is). That would allow > people who want the feature to use it. > I'm seeing.. Patch #243 - 2009/3/28 * revert change to default for allowTcapOps (request by Bram Moolenaar). Does this change involve this bug.. ? yes - the issue is whether the changes made to prevent xterm from telling vim that both shifted and unshifted cursor keys exists with the same escape sequence was the crux of the original report, or whether there's some confusion on the version at fault, etc. I'm not 100% sure (Bram seems to be). 24 Sep 2009; Samuli Suominen <ssuominen@gentoo.org> xterm-248.ebuild: Remove --enable-tcap-query wrt #212546 by Petr Pisar. *xterm-248 (24 Sep 2009) 24 Sep 2009; Samuli Suominen <ssuominen@gentoo.org> +xterm-248.ebuild: Version bump. I think better approach would be to add "XTerm.vt100.allowTcapOps: false" into /usr/share/X11/app-defaults/*XTerm config files instead of removing the functionality completely. something like that (GenToo is using the toolbar, which would add a level to the resource pattern). If the feature is compiled-in there's more than one way to make it disabled by default (resource-settings, or pre-defining DEF_ALLOW_TCAP same problem here after upgrading my gentoo servers adding : set term=builtin_ansi in /etc/vim/vimrc fixed the arrow keys ( tips found on http://vim.wikia.com/wiki/Fix_broken_arrow_key_navigation_in_insert_mode) ( better than downgrading ;) Changing $TERM does make vim not think it's xterm. However, the corresponding function keys won't match xterm either. iirc, vim's internal table as you suggest will help with cursor keys. |
