bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries?


From: Drew Adams
Subject: bug#9653: 24.0.50; `ucs-names' - Why all of the ("" . XXX) entries?
Date: Fri, 17 Feb 2012 07:55:32 -0800

Forwarding to 9653@debbugs.gnu.org.

Otherwise, it is never sent to that bug list (so I, for one, do not receive it).
That is a deficiency in the bug-system design, IMO, and should be fixed.

It is not enough that mail to ####-done@debbugs.gnu.org gets added to the bug
thread indirectly, so you can see it using HTTP at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=####.

Mail sent to ####-done@debbugs.gnu.org should also continue to go to the bug
mailing list (####@debbugs.gnu.org), so subscribers following the thread there
receive such messages as well.

Just because someone closes a bug does not mean that subsequent correspondence
about it should be excluded from the bug mailing list by default.

When you hit `Reply All' to reply to the bug thread, you expect your reply to be
added to that bug thread, i.e., the bug mailing list.  Users should not have to
think about editing the recipients list to add the bug-thread list
(####@debbugs.gnu.org).  That address should be present by default.


-----Original Message-----
Sent: Friday, February 17, 2012 7:40 AM
To: 'Stefan Monnier'; 'Kenichi Handa' Cc: '9653-done@debbugs.gnu.org'

> >> Could you take a look at this problem and replace the "" 
> >> with nil for the name of unassigned chars?
> > Done.
> 
> Thank you,

Thank you for trying to fix this.
But I still see the same problem:

>> such entries interfere with the possibility of simply
>> using `rassq' to look up a char code.  Especially since
>> the empty entries seem to come _first_, before the non-empty 
>> entries (why?).
>> 
>> E.g., try to look up (rassq 11967 (ucs-names)).
>> 
>> There is a perfectly good entry for this char code: ("CJK 
>> RADICAL GRASS TWO" . 11967).  But it is _preceded_ by this
>> empty-name entry: ("" . 11967), which is of course what
>> `rassq' returns.  (And those are the only entries for 11967.)

IOW, replacing "" by nil _only for unassigned chars_ does not solve the problem,
AFAICT.  The problem is that there are ("" . <some#>) entries that precede
perfectly legitimate, assigned chars.  Can you please remove those empty entries
as well?

emacs -Q
M-: (rassq 11967 (ucs-names))

That returns ("" . 11967), which is useless (for me, at least).  I expect it to
return ("CJK RADICAL GRASS TWO" . 11967), which is usable.

If this was fixed after the build I'm testing (the latest Windows binary
available, from 2 days ago), then ignore what I just said.  But that is anyway
what I see in this build:

In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-02-15 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'






reply via email to

[Prev in Thread] Current Thread [Next in Thread]