On Wed, Jan 16, 2013 at 01:56:05PM -0500, Thomas Dickey wrote: > On Wed, Jan 16, 2013 at 01:34:26PM -0500, Thomas Dickey wrote: > > On Wed, Jan 16, 2013 at 07:04:11PM +0100, Sven Joachim wrote: > > > The relevant capability here is kUP; removing it fixes the Emacs problem > > > for me. > > > > "select" could have been an issue with the home/end (pc-style) > > versus select/remove (vt220-style). xterm's used pc-style (again, > > for quite a while). changing the default isn't recommended. We > > use "home" and "end" because that's what most users expect. > > To remind you of the issue: curses applications will only see the > first key in a list which matches a given string. While terminfo > and termcap can store the same string using different names, curses > only uses one. So... xterm-vt220 has "select" while xterm has "home". > > It's understandable why Emacs would say that "select" is undefined. > But how that is related to kUP, I don't know - the answer would be > in Emacs.
...for instance vim had a relevant bug report a year or two ago.
It was not checking for the complete string, and was confused by
the semicolon delimiting the parameters in a string.
xterm+pc+edit|fragment for pc-style editing keypad,
kend=\E[4~, khome=\E[1~,
xterm+vt+edit|fragment for vt220-style editing keypad,
kfnd=\E[1~, kslt=\E[4~,
Recalling that some people may have relabeled the "kfnd" as "select",
kUP=\E[1;2A,
--------^
An application which looked at an incomplete string could confuse kUP
with kfnd. Conceivably Emacs could be retrieving the kUP value into
a table (via tigetstr for instance), but failing to check for the
complete string match. In that case, it would be a bug in Emacs.
--
Thomas E. Dickey <[email protected]>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
