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.
select/remove home/end use different strings than kUP -
# Reconstructed via infocmp from file:
/usr/local/ncurses/share/terminfo/x/xterm+pc+edit
xterm+pc+edit|fragment for pc-style editing keypad,
kend=\E[4~, khome=\E[1~,
# Reconstructed via infocmp from file:
/usr/local/ncurses/share/terminfo/x/xterm+vt+edit
xterm+vt+edit|fragment for vt220-style editing keypad,
kfnd=\E[1~, kslt=\E[4~,
("kslt" is "select", barring renaming by Emacs)
kUP isn't an obsolete key, but rather is one of the set of extended keys:
kUP=\E[1;2A,
That could - hmm - be an issue with Emacs only if Emacs is using
ncurses' wgetch which would attempt to use or not use the definitions.
The last I knew, Emacs was a termcap application (like vim), and
couldn't see the extended keys(*). That is, Emacs sees this as
a termcap application; the presence of extended capabilities doesn't
affect anything in this case:
xterm-new|modern xterm terminal emulator:\
:am:bs:km:mi:ms:xn:\
:co#80:it#8:li#24:\
:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
:K2=\EOE:LE=\E[%dD:RI=\E[%dC:SF=\E[%dS:SR=\E[%dT:\
:UP=\E[%dA:ae=\E(B:al=\E[L:as=\E(0:bl=^G:bt=\E[Z:cd=\E[J:\
:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:\
:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ec=\E[%dX:\
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:\
:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:\
:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:\
:kP=\E[5~:kb=\177:kd=\EOB:ke=\E[?1l\E>:kh=\EOH:kl=\EOD:\
:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:mb=\E[5m:md=\E[1m:\
:me=\E[0m:mm=\E[?1034h:mo=\E[?1034l:mr=\E[7m:nd=\E[C:\
:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:st=\EH:ta=^I:\
:te=\E[?1049l:ti=\E[?1049h:ue=\E[24m:up=\E[A:us=\E[4m:\
:vb=\E[?5h\E[?5l:ve=\E[?12l\E[?25h:vi=\E[?25l:\
:vs=\E[?12;25h:
So I don't see a case where either confusion about the byte-stream or
confusion about the keycode from wgetch would lead to the reported
symptom - none of the data overlaps in the "right" way, and I don't
see any sign of data loss in the descriptions.
(memu/meml are seldom used, are unrelated to the keys, but that is a
different matter).
> > I'm not sure of the best way of fixing this. Either the obsolete keys
> > shouldn't be included in the terminfo file, or the tic call should be
> > done without -x. I'm leaning towards the second, but I don't have
> > enough knowledge of the package to be certain about it.
>
> I'd like to get a comment from Thomas (CC'ed) before doing anything.
> Thanks for the report.
There's always the possibility of finding a malfunction someplace,
but turning off the extended capabilities isn't the way to fix that.
(*) while the extended capabilities are potentially visible to either
termcap/terminfo applications, only those with exactly 2-character
names are visible to termcap.
--
Thomas E. Dickey <[email protected]>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
