GNU bug report logs - #4922
<control>

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4922 in the body.
You can then email your comments to 4922 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Per Starbäck <per.starback <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: <control>
Date: Fri, 13 Nov 2009 21:58:57 +0100

emacs -q
  C-x 8 RET < TAB RET
completes to "<control>" which inserts \237.

I didn't expect "<control>" to be a valid completion there.

The reason is that control characters have "<control>" in the second field in
admin/unidata/UnicodeData.txt (and \237 is the last such character.

Suggestion: Skip the <control> names in unidata-gen-table.

When I looked around for this I noticed a very minor thing in
ucs-names in mule-cmds.el.
It says
	      (dotimes-with-progress-reporter (c #xEFFFF)
but I think the limit ought to be #xF0000, which is where Plane 15
starts, since dotimes-with-progress-reporter
has that as an exclusive limit. (In practice it doesn't matter. At
least not for the time being.)

Message #10 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Per Starbäck <per.starback <at> gmail.com>
Cc: 4922 <at> debbugs.gnu.org, Kenichi Handa <handa <at> m17n.org>
Subject: Re: <control>
Date: Sun, 18 Sep 2011 11:07:34 +0200

Per Starbäck <per.starback <at> gmail.com> writes:

> emacs -q
>   C-x 8 RET < TAB RET
> completes to "<control>" which inserts \237.
>
> I didn't expect "<control>" to be a valid completion there.
>
> The reason is that control characters have "<control>" in the second field in
> admin/unidata/UnicodeData.txt (and \237 is the last such character.
>
> Suggestion: Skip the <control> names in unidata-gen-table.

I can confirm that this problem still exists in Emacs 24.

I looked into fixing it, but the code that converts the UnicodeData.txt
into all the .el files look like black magic to me.  Or rather -- the
code looks straightforward, but it's somewhat unclear how to actually
run the functions.  :-)

For someone who's done it before it's probably a trivial problem to fix.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #13 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: per.starback <at> gmail.com, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Sun, 18 Sep 2011 05:40:53 -0400

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 18 Sep 2011 11:07:34 +0200
> Cc: 4922 <at> debbugs.gnu.org
> 
> Per Starbäck <per.starback <at> gmail.com> writes:
> 
> > emacs -q
> >   C-x 8 RET < TAB RET
> > completes to "<control>" which inserts \237.

What _did_ you expect to see? why would you type `<' to begin with?

Message #16 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: per.starback <at> gmail.com, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Sun, 18 Sep 2011 11:40:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > emacs -q
>> >   C-x 8 RET < TAB RET
>> > completes to "<control>" which inserts \237.
>
> What _did_ you expect to see? why would you type `<' to begin with?

If you just type TAB without the <, you also get <control> first.  Which
doesn't seem very useful, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #19 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: per.starback <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Mon, 19 Sep 2011 15:40:28 -0400

>>> > emacs -q
>>> >   C-x 8 RET < TAB RET
>>> > completes to "<control>" which inserts \237.
>> What _did_ you expect to see? why would you type `<' to begin with?
> If you just type TAB without the <, you also get <control> first.  Which
> doesn't seem very useful, I think.

Maybe it's not very useful (especially since this same name is used for
several characters), but it's what Unicode names characters 0-31 in its
UnicodeData.txt.  Should we really bother to do something special for them?


        Stefan

Message #22 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: per.starback <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Wed, 21 Sep 2011 20:44:41 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Maybe it's not very useful (especially since this same name is used for
> several characters), but it's what Unicode names characters 0-31 in its
> UnicodeData.txt.  Should we really bother to do something special for them?

It obviously not a critical bug.  But presenting the user with a choice,
by default, that will not insert anything usable, should be avoided.

That way people can find the important characters, like AIRPLANE ✈
easier.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #25 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Xue Fuqiao <xfq <at> gnu.org>
To: Per Starbäck <per.starback <at> gmail.com>
Cc: 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Wed, 26 Feb 2014 18:20:26 +0800

Per Starbäck <per.starback <at> gmail.com> writes:

> emacs -q
>   C-x 8 RET < TAB RET
> completes to "<control>" which inserts \237.
>
> I didn't expect "<control>" to be a valid completion there.

I can't reproduce this with current trunk (24.3.50).  "Invalid character"
is displayed in the echo area.

-- 
http://www.gnu.org/software/emacs/

Message #28 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Xue Fuqiao <xfq <at> gnu.org>, Per Starbäck
 <per.starback <at> gmail.com>
Cc: 4922 <at> debbugs.gnu.org
Subject: RE: bug#4922: <control>
Date: Wed, 26 Feb 2014 06:05:55 -0800 (PST)

> > emacs -q
> >   C-x 8 RET < TAB RET
> > completes to "<control>" which inserts \237.
> >
> > I didn't expect "<control>" to be a valid completion there.
> 
> I can't reproduce this with current trunk (24.3.50).  "Invalid character"
> is displayed in the echo area.

I too cannot repro it, with this:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-21 on ODIEONE
Repository revision: 116523 lekktu <at> gmail.com-20140222021049-g04nwe512x430tk5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

Sounds like bug #16216.  The bug is still open, IIUC, but Eli
wrote that:

  starting with trunk revision 115693, all control characters
  will have nil as their 'name' property, and "C-x 8 RET < TAB"
  will say "No match".  (Some of the control characters have
  'old-name' property, so they still can be called out by name.)

And AFAICT it does seem to be fixed.  Should it be closed?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216

Message #31 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Per Starbäck <per.starback <at> gmail.com>
Cc: Xue Fuqiao <xfq <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: RE: bug#4922: <control>
Date: Wed, 26 Feb 2014 06:46:01 -0800 (PST)

> > And AFAICT it does seem to be fixed.  Should it be closed?
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216
> 
> That 16216 is a duplicate of this bug, isn't it? Since it is fixed the
> original is also fixed.

Yes, except it is the other way around.  AFAICT, that bug (and
so this one) has already been fixed.

But perhaps Fuqiao is seeing something different and there is
still a bug somewhere.

Message #34 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Per Starbäck <per.starback <at> gmail.com>
Cc: Xue Fuqiao <xfq <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: RE: bug#4922: <control>
Date: Wed, 26 Feb 2014 07:53:17 -0800 (PST)

> >> > And AFAICT it does seem to be fixed.  Should it be closed?
> >> >
> >> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216
> >>
> >> That 16216 is a duplicate of this bug, isn't it? Since it is fixed the
> >> original is also fixed.
> >
> > Yes, except it is the other way around.  AFAICT, that bug (and
> > so this one) has already been fixed.
> >
> > But perhaps Fuqiao is seeing something different and there is
> > still a bug somewhere.
>
> As the original reporter from 2011 I maintain that that is the
> original, and not the one from last December. What I meant with "since
> it is fixed the original is also fixed" was that it was the copy that
> finally triggered the fix.

I see what you are saying.  AFAICT:

1. Yes, 16216 is a duplicate of 4922 (I had it backward; sorry).

2. Yes, it was the duplicate, 16216 that triggered fixing (by Eli).

3. Yes, it seems to be fixed.

4. But we should perhaps wait to hear from Fuqiao wrt whether
he can repro it with the latest code.

If he can confirm that this is fixed, 4922 and 16216 can be
closed (no?).

Message #37 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Per Starbäck <per.starback <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Xue Fuqiao <xfq <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Wed, 26 Feb 2014 15:14:49 +0100

> And AFAICT it does seem to be fixed.  Should it be closed?
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216

That 16216 is a duplicate of this bug, isn't it? Since it is fixed the
original is also fixed.

Message #40 received at 4922 <at> debbugs.gnu.org (full text, mbox):

From: Per Starbäck <per.starback <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Xue Fuqiao <xfq <at> gnu.org>, 4922 <at> debbugs.gnu.org
Subject: Re: bug#4922: <control>
Date: Wed, 26 Feb 2014 16:10:05 +0100

As the original reporter from 2011 I maintain that that is the
original, and not the one from last December. What I meant with "since
it is fixed the original is also fixed" was that it was the copy that
finally triggered the fix.

2014-02-26 15:46 GMT+01:00 Drew Adams <drew.adams <at> oracle.com>:
>> > And AFAICT it does seem to be fixed.  Should it be closed?
>> >
>> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216
>>
>> That 16216 is a duplicate of this bug, isn't it? Since it is fixed the
>> original is also fixed.
>
> Yes, except it is the other way around.  AFAICT, that bug (and
> so this one) has already been fixed.
>
> But perhaps Fuqiao is seeing something different and there is
> still a bug somewhere.

Message #45 received at 4922-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Per Starbäck <per.starback <at> gmail.com>
Cc: xfq <at> gnu.org, 4922-done <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#4922: <control>
Date: Wed, 26 Feb 2014 18:55:18 +0200

> Date: Wed, 26 Feb 2014 15:14:49 +0100
> From: Per Starbäck <per.starback <at> gmail.com>
> Cc: Xue Fuqiao <xfq <at> gnu.org>, 4922 <at> debbugs.gnu.org
> 
> > And AFAICT it does seem to be fixed.  Should it be closed?
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16216
> 
> That 16216 is a duplicate of this bug, isn't it? Since it is fixed the
> original is also fixed.

Yes, closing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.