unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#4922: <control>
@ 2009-11-13 20:58 Per Starbäck
  2011-09-18  9:07 ` Lars Magne Ingebrigtsen
  2014-02-26 10:20 ` Xue Fuqiao
  0 siblings, 2 replies; 13+ messages in thread
From: Per Starbäck @ 2009-11-13 20:58 UTC (permalink / raw)
  To: bug-gnu-emacs

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.)






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2009-11-13 20:58 bug#4922: <control> Per Starbäck
@ 2011-09-18  9:07 ` Lars Magne Ingebrigtsen
  2011-09-18  9:40   ` Eli Zaretskii
  2014-02-26 10:20 ` Xue Fuqiao
  1 sibling, 1 reply; 13+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18  9:07 UTC (permalink / raw)
  To: Per Starbäck; +Cc: 4922

Per Starbäck <per.starback@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/





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2011-09-18  9:40   ` Eli Zaretskii
@ 2011-09-18  9:40     ` Lars Magne Ingebrigtsen
  2011-09-19 19:40       ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-18  9:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: per.starback, 4922

Eli Zaretskii <eliz@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/





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2011-09-18  9:07 ` Lars Magne Ingebrigtsen
@ 2011-09-18  9:40   ` Eli Zaretskii
  2011-09-18  9:40     ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2011-09-18  9:40 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: per.starback, 4922

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 18 Sep 2011 11:07:34 +0200
> Cc: 4922@debbugs.gnu.org
> 
> Per Starbäck <per.starback@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?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2011-09-18  9:40     ` Lars Magne Ingebrigtsen
@ 2011-09-19 19:40       ` Stefan Monnier
  2011-09-21 18:44         ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2011-09-19 19:40 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen; +Cc: per.starback, 4922

>>> > 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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2011-09-19 19:40       ` Stefan Monnier
@ 2011-09-21 18:44         ` Lars Magne Ingebrigtsen
  0 siblings, 0 replies; 13+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-21 18:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: per.starback, 4922

Stefan Monnier <monnier@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/





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2009-11-13 20:58 bug#4922: <control> Per Starbäck
  2011-09-18  9:07 ` Lars Magne Ingebrigtsen
@ 2014-02-26 10:20 ` Xue Fuqiao
  2014-02-26 14:05   ` Drew Adams
  1 sibling, 1 reply; 13+ messages in thread
From: Xue Fuqiao @ 2014-02-26 10:20 UTC (permalink / raw)
  To: Per Starbäck; +Cc: 4922

Per Starbäck <per.starback@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/





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 10:20 ` Xue Fuqiao
@ 2014-02-26 14:05   ` Drew Adams
  2014-02-26 14:14     ` Per Starbäck
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2014-02-26 14:05 UTC (permalink / raw)
  To: Xue Fuqiao, Per Starbäck; +Cc: 4922

> > 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@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






^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 14:05   ` Drew Adams
@ 2014-02-26 14:14     ` Per Starbäck
  2014-02-26 14:46       ` Drew Adams
  2014-02-26 16:55       ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Per Starbäck @ 2014-02-26 14:14 UTC (permalink / raw)
  To: Drew Adams; +Cc: Xue Fuqiao, 4922

> 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 14:14     ` Per Starbäck
@ 2014-02-26 14:46       ` Drew Adams
  2014-02-26 15:10         ` Per Starbäck
  2014-02-26 16:55       ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: Drew Adams @ 2014-02-26 14:46 UTC (permalink / raw)
  To: Per Starbäck; +Cc: Xue Fuqiao, 4922

> > 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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 14:46       ` Drew Adams
@ 2014-02-26 15:10         ` Per Starbäck
  2014-02-26 15:53           ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Per Starbäck @ 2014-02-26 15:10 UTC (permalink / raw)
  To: Drew Adams; +Cc: Xue Fuqiao, 4922

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@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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 15:10         ` Per Starbäck
@ 2014-02-26 15:53           ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2014-02-26 15:53 UTC (permalink / raw)
  To: Per Starbäck; +Cc: Xue Fuqiao, 4922

> >> > 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?).





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#4922: <control>
  2014-02-26 14:14     ` Per Starbäck
  2014-02-26 14:46       ` Drew Adams
@ 2014-02-26 16:55       ` Eli Zaretskii
  1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2014-02-26 16:55 UTC (permalink / raw)
  To: Per Starbäck; +Cc: xfq, 4922-done

> Date: Wed, 26 Feb 2014 15:14:49 +0100
> From: Per Starbäck <per.starback@gmail.com>
> Cc: Xue Fuqiao <xfq@gnu.org>, 4922@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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2014-02-26 16:55 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-13 20:58 bug#4922: <control> Per Starbäck
2011-09-18  9:07 ` Lars Magne Ingebrigtsen
2011-09-18  9:40   ` Eli Zaretskii
2011-09-18  9:40     ` Lars Magne Ingebrigtsen
2011-09-19 19:40       ` Stefan Monnier
2011-09-21 18:44         ` Lars Magne Ingebrigtsen
2014-02-26 10:20 ` Xue Fuqiao
2014-02-26 14:05   ` Drew Adams
2014-02-26 14:14     ` Per Starbäck
2014-02-26 14:46       ` Drew Adams
2014-02-26 15:10         ` Per Starbäck
2014-02-26 15:53           ` Drew Adams
2014-02-26 16:55       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).