[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#189764: marked as forwarded (Inconsistent doc for shifted keypad in xterm's terminfo entry)



Your message dated Mon, 21 Apr 2003 18:34:38 +0200
with message-id <20030421163438.GB1251@diku.dk>
has caused the Debian Bug report #189764,
regarding Inconsistent doc for shifted keypad in xterm's terminfo entry
to be marked as having been forwarded to the upstream software
author(s) Thomas Dickey <dickey@herndon4.his.com>.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

---------------------------------------
Received: (at 189764-forwarded) by bugs.debian.org; 21 Apr 2003 16:34:44 +0000
>From makholm@diku.dk Mon Apr 21 11:34:41 2003
Return-path: <makholm@diku.dk>
Received: from hugin.diku.dk [130.225.96.144] (qmailr)
	by master.debian.org with smtp (Exim 3.12 1 (Debian))
	id 197eFb-0004Yh-00; Mon, 21 Apr 2003 11:34:39 -0500
Received: (qmail 21349 invoked from network); 21 Apr 2003 16:34:38 -0000
Received: from pc-043.diku.dk (130.225.97.43)
  by hugin.diku.dk with QMQP; 21 Apr 2003 16:34:38 -0000
Date: Mon, 21 Apr 2003 18:34:38 +0200
From: Henning Makholm <henning@makholm.net>
To: Thomas Dickey <dickey@herndon4.his.com>
Cc: 189764-forwarded@bugs.debian.org
Subject: Re: http://groups.google.com/groups?q=+ncurses+OR+xterm+OR+vttest+OR+cpro
Message-ID: <20030421163438.GB1251@diku.dk>
References: <200304201401.h3KE1mD00665@invisible-island.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200304201401.h3KE1mD00665@invisible-island.net>
User-Agent: Mutt/1.4i
Delivered-To: 189764-forwarded@bugs.debian.org
X-Spam-Status: No, hits=-2.8 required=4.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT,
	      USER_AGENT_MUTT
	version=2.44
X-Spam-Level: 

[Comment for the Debian package maintainer: The upstream author
emailed me directly, bypassing the BTS; I'm quoting all of his new
text below. I hope it is not bad form for me to set the "forwarded
upstream" flag myself. Thomas, please keep the Cc to
189764-forwarded@bugs.debian.org on further correspondence.]

> actually, the documentation is correct - you need more context.
> See the discussion of PC-Style function keys in ctlseqs.ms
> 
> 	ftp://invisible-island.net/xterm/ctlseqs.txt.gz

I don't see how your link implies that I am wrong. Note that my
observation is that the xterm documentation is *internally*
inconsistent:

 1. The comment in the terminfo description says, paraphrased:
    "We define kDC to match control+XK_Delete".

 2. The code following that in the terminfo description defines kDC to
    "\E[3;2~".

 3. "\E[3;2~" is actually the escape sequence that xterm generates
    for shift+XK_Delete.

(3) follows indirectly from ctlseqs.ms - it says that Delete ought
to send \EO3~, which must be a typo because it is the only place where
SS3 is ever followed by a digit other than the modifier code; and
xterm.faq.gz does document \E[3~ for VT220 remove. However, ctlseqs.ms
does unambigously state that ";2" means shift and ";5" means control.

This can also be verified by direct experiment, assuming that you
have a key xmodmapped to XK_Delete (and a shell with GNU-like echo(1)
semantics):
   a. Start xterm
   b. Run echo -e '\e[?1h' ; cat > /dev/null
      (\e[?1h selects application cursor keys, though this should not
      be necessary for Remove)
   c. Press control+delete
   d. "^[[3;5~" gets echoed
   e. Press shift+delete
   f. "^[[3;2~" gets echoed

I believe that xterm *behaves* correctly, but I maintain that there is
a typo in the terminfo description that ships within the tarball. The
typo may either be in the comment or in the code; as I noted, the
compiled terminfo file that Debian actually ships with its terminfo
database chose to fix it in the code.


Here's a - completely unrelated - genuine bug that I discovered while
trying to figure out the code: XK_KP_Equal does not work. This is
because the second 'b' is missing from the hex-ruler comments above
the definition of kypd_num and kypd in input.c, so the '=' and 'X'
intended to be hit by XK_KP_Equal come one character too early.

By the way, the link you gave,
ftp://invisible-island.net/xterm/ctlseqs.txt.gz, seems to have been
troffed withough passing it through tbl(1) first - that makes the
tables in the function-key sections rather hard to read.

-- 
Henning Makholm  "Det er jo svært at vide noget når man ikke ved det, ikke?"



Reply to: