From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!not-for-mail
From: Thomas Dickey <dickey@his.com>
Newsgroups: gmane.emacs.bugs
Subject: bug#13471: 24.3.50; S-up does not work in xterm: <select> is undefined
Date: Thu, 17 Jan 2013 19:02:21 -0500
Message-ID: <20130118000221.GA9212@aerie.jexium-island.net>
References: <mailman.17669.1358412868.855.bug-gnu-emacs@gnu.org>
	<b5ec319a-c4b9-45b6-b9da-209b5e9e4137@googlegroups.com>
	<jwvlibrbtn2.fsf-monnier+bug#13471@gnu.org>
Reply-To: dickey@his.com
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
X-Trace: ger.gmane.org 1358467487 16288 80.91.229.3 (18 Jan 2013 00:04:47 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Fri, 18 Jan 2013 00:04:47 +0000 (UTC)
Cc: gnu.emacs.bug@googlegroups.com, Sven Joachim <svenjoac@gmx.de>,
	dickey@his.com, 13471@debbugs.gnu.org
To: Stefan Monnier <monnier@iro.umontreal.ca>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 18 01:05:02 2013
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1TvzSA-0001Sk-3z
	for geb-bug-gnu-emacs@m.gmane.org; Fri, 18 Jan 2013 01:05:02 +0100
Original-Received: from localhost ([::1]:56963 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1TvzRt-00078Y-AK
	for geb-bug-gnu-emacs@m.gmane.org; Thu, 17 Jan 2013 19:04:45 -0500
Original-Received: from eggs.gnu.org ([208.118.235.92]:54897)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1TvzRE-00075l-GH
	for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2013 19:04:43 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1TvzQU-00055P-Sc
	for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2013 19:04:04 -0500
Original-Received: from debbugs.gnu.org ([140.186.70.43]:60257)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1TvzQU-00055E-Ou
	for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2013 19:03:18 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1TvzRB-0007cL-QU
	for bug-gnu-emacs@gnu.org; Thu, 17 Jan 2013 19:04:01 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Thomas Dickey <dickey@his.com>
Original-Sender: debbugs-submit-bounces@debbugs.gnu.org
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Fri, 18 Jan 2013 00:04:01 +0000
Resent-Message-ID: <handler.13471.B13471.135846741529238@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 13471
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
Original-Received: via spool by 13471-submit@debbugs.gnu.org id=B13471.135846741529238
	(code B ref 13471); Fri, 18 Jan 2013 00:04:01 +0000
Original-Received: (at 13471) by debbugs.gnu.org; 18 Jan 2013 00:03:35 +0000
Original-Received: from localhost ([127.0.0.1]:37488 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1TvzQh-0007bT-8a
	for submit@debbugs.gnu.org; Thu, 17 Jan 2013 19:03:34 -0500
Original-Received: from vms173003pub.verizon.net ([206.46.173.3]:53232)
	by debbugs.gnu.org with esmtp (Exim 4.72)
	(envelope-from <tom@invisible-island.net>) id 1TvzQc-0007bG-6a
	for 13471@debbugs.gnu.org; Thu, 17 Jan 2013 19:03:29 -0500
Original-Received: from localhost.localdomain ([unknown] [96.255.10.145])
	by vms173003.mailsrvcs.net
	(Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16
	2009)) with ESMTPA id <0MGS0055DO3Y8LI3@vms173003.mailsrvcs.net> for
	13471@debbugs.gnu.org; Thu, 17 Jan 2013 18:02:27 -0600 (CST)
Original-Received: from localhost.localdomain (aerie [127.0.0.1])
	by localhost.localdomain (8.14.3/8.14.3/Debian-9.4)
	with ESMTP id r0I02LVj010340
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 17 Jan 2013 19:02:21 -0500
Original-Received: (from tom@localhost)	by localhost.localdomain (8.14.3/8.14.3/Submit)
	id r0I02LSK010338; Thu, 17 Jan 2013 19:02:21 -0500
Content-disposition: inline
In-reply-to: <jwvlibrbtn2.fsf-monnier+bug#13471@gnu.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.13
Precedence: list
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 140.186.70.43
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
	the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org
Xref: news.gmane.org gmane.emacs.bugs:69949
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/69949>


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 17, 2013 at 12:37:19PM -0500, Stefan Monnier wrote:
> Hi Thomas,
>=20
> I'm not familiar enough to follow your argument and/or suggestion and
> I'm especially unable to relate your email's body with its subject.
> Could you try to help me understand?

There are several things to discuss:

	+ this thread started in Debian #698299
	  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D698299

	+ the original report cited a few urls, including a previous
	  thread for Emacs:

	  http://stackoverflow.com/questions/10871745/shift-up-arrow-doesnt-highli=
ght-text-emacs-iterm2
	  http://lists.gnu.org/archive/html/help-gnu-emacs/2011-05/msg00211.html
	  http://forums.vandyke.com/showpost.php?p=3D26580&postcount=3D25

	+ Sven commented that removing the line with "kU" fixed the
	  reported problem.

	+ I commented that the mailing-list thread discussing this had
	  quoted a comment from the Emacs source code indicating that
	  the chunk of code had been written for a "non-standard dialect
	  of terminfo".

	  I'd read that thread before, noting (to myself) only that
	  the comment was incorrect since the mnemonics in quotes
	  are all termcap.  The first parameter (F1, F2, %1) is
	  a conventional termcap name (there are no standards for
	  termcap - it owes its existing convention to documentation
	  in the terminfo manual), while the others were unfamiliar
	  to me.

	  You can see the names in terminfo(5).

	+ however, as a bug report against ncurses I pay more attention.
	  The problem is to infer where the problem is, and possible
	  causes.

	+ Emacs uses the termcap interface provided by ncurses, which
	  means that Emacs calls tgetstr, tgetnum, tgetflag to obtain
	  string, numeric, boolean values.  The termcap interface
	  matches only the first 2 characters of capability names.

	  (The reason for not requiring that the names have a trailing
	  null, I seem to recall being for compatibility with termcap
	  libraries which do this, leading to applications that rely
	  upon the behavior).

	+ this behavior was commented on in a different thread:
	  http://lists.gnu.org/archive/html/emacs-devel/2012-10/msg00012.html

	+ tgetstr looks for each name, starting with the predefined
	  termcap names, and then the extended names - unless one calls
	  the ncurses function
	  	use_extended_names(FALSE);

	  That's been the behavior since 1999.  The current data for the
	  extended keys for xterm dates from April 2005.

	+ uses for the above features (and quirks) are long established.
	  That leads to considering how the problem arises in Emacs,
	  and whether Emacs needs the problematic code.

	+ The thread from October suggests that the problem is that Emacs
	  is calling tgetstr with "kU" as a parameter.   That will return
	  data for kUP (an extended key).  Schwab comments that kR is
	  the same as kri - though there's a pitfall there.  Quoting from
	  terminfo(5):

       key_sf                        kind       kF        scroll-forward key
       key_sr                        kri        kR        scroll-backward k=
ey
       key_sleft                     kLFT       #4        shifted left-arrow
                                                          key
       key_sright                    kRIT       %i        shifted right-arr=
ow
                                                          key

	  You may notice that terminfo(5) does not define a shifted up or
	  down-arrow.  (Whether kind and kri should fill that role is arguable
	  - I decided they would, and in October 2005 modified xterm-new to
	  provided that connection but have found no prior art to establish
	  that connection in usage by others).
	 =20
	  I retained kUP because it fits a pattern of names for extended keys.

	  So... if Emacs looks for "kU" and gets "kUP" data, and then sees
	  that it is the same string as an existing key kR, then it could
	  conclude that the assignment for "kU" was ineffective and that
	  "select" is not defined.

	+ Emacs could of course solve the problem by calling
		use_extended_names(FALSE);

	  I recall making that suggestion to someone working on Emacs a
	  few years ago - that's apparently not been done.

	+ Alternatively (as suggested in the threads mentioned), one could
	  remove the problematic call from Emacs.  That could be done if
	  it serves no useful purpose.  From discussion and examining the
	  source code, it appears that the "non-standard terminfo" cited
	  in the comment is unlikely to be in use by anyone some 18
	  years later - it dates from 1994-10-14.  AIX 4 was released in
	  1994; the code was for AIX 4 (early) or AIX 3 (late).
	  In either case it's old.  AIX 5 is more than ten years old.
	 =20
	  The entire chunk relating to that comment could be removed.

	  There is other obsolete code in term.c, e.g., the Teleray code,
	  the Hazeltine code, not to mention Emacs insistence on using
	  termcap names on a terminfo system :-)

	+ Schwab's comments this morning seemed to be focused on retaining
	  the code because (a) it was related to terminfo and (b) ncurses
	  uses terminfo.  My viewpoint on it is that the code is useful
	  only if there is a system whose users rely upon it, that a tie
	  to ncurses is pointless.  The data in ncurses exposes some code
	  which is no longer useful.

> >>>>> "dickey" =3D=3D dickey  <dickey@his.com> writes:
>=20
> > On Thursday, January 17, 2013 3:53:15 AM UTC-5, Sven Joachim wrote:
> >> --8<---------------cut here---------------start------------->8---
> >> =3D=3D=3D modified file 'src/term.c'
> >> --- src/term.c	2013-01-11 02:40:58 +0000
> >> +++ src/term.c	2013-01-17 08:49:20 +0000
> >> @@ -1415,7 +1415,6 @@ term_get_fkeys_1 (void)
> >> CONDITIONAL_REASSIGN ("F1", "k<", "f11");
> >> CONDITIONAL_REASSIGN ("F2", "k>", "f12");
> >> CONDITIONAL_REASSIGN ("%1", "kq", "help");
> >> -      CONDITIONAL_REASSIGN ("*6", "kU", "select");
> >>=20
> >> #undef CONDITIONAL_REASSIGN
> >>=20
> >> }
>=20
> > A follow message says that there is a comment
>=20
> >       /* IBM has their own non-standard dialect of terminfo.
> >          If the standard name isn't found, try the IBM name.  */
>=20
> > which is interesting: the code fragment is dealing with termcap
> > names (the first parameter is conventional termcap names, the
> > second is not).  It is not dealing with terminfo (there is a
> > difference...).  AIX has been terminfo-only for a long time
> > (I don't have access to a machine old enough to provide an
> > example of termcap in use - that would have to be from the
> > early 1990s.
>=20
> > I would suggest researching the history of this fragment,
> > and probably discarding the entire chunk as obsolete,
> > e.g., if it referred to AIX 3 or 4.
>=20
>=20
>=20

--=20
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlD4kQ0ACgkQcCNT4PfkjtvA3wCeMWDO83n7GOZ7ZL1qOuZgWayd
r7gAn0L4nQDDwU/0Si3YVn5O4h5QtLyQ
=ba9e
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--