GNU bug report logs - #25641
25.1; insert-char function inconsistency

Previous Next

Package: emacs;

Reported by: Pablo Mercader Alcántara <programingfrik <at> gmail.com>

Date: Tue, 7 Feb 2017 13:05:01 UTC

Severity: minor

Found in version 25.1

Done: Stephen Berman <stephen.berman <at> gmx.net>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: programingfrik <at> gmail.com, 25641 <at> debbugs.gnu.org
Subject: bug#25641: 25.1; insert-char function inconsistency
Date: Wed, 08 Feb 2017 22:43:50 +0100

On Wed, 08 Feb 2017 19:54:12 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Wed, 08 Feb 2017 14:15:00 +0100
>> Cc: 25641 <at> debbugs.gnu.org
>> 
>> I agree.  The following patch does that (the special-casing here has a
>> precedent in ucs-names in mule-cmds.el, from which the comment is
>> copied):
>> 
>> diff --git a/lisp/descr-text.el b/lisp/descr-text.el
>> index 3971dbb..a1efb67 100644
>> --- a/lisp/descr-text.el
>> +++ b/lisp/descr-text.el
>> @@ -617,7 +617,14 @@ describe-char
>>  				 "input method")
>>  			 (list
>>                            (let ((name
>> -                                 (or (get-char-code-property char 'name)
>> +                                 (or (when (= char 7)
>> +				       ;; Special case for "BELL" which is
>> +				       ;; apparently the only char which
>> +				       ;; doesn't have a new name and whose
>> +				       ;; old-name is shadowed by a newer char
>> +				       ;; with that name.
>> +				       (car (rassoc char ucs-names)))
>> +				     (get-char-code-property char 'name)
>>                                       (get-char-code-property char 'old-name))))
>>                              (if (and name (assoc-string name (ucs-names)))
>>                                  (format
>> 
>> Eli, what do you say?
>
> I don't mind, but ucs-names might be nil if the function by the same
> name was not yet called, so I think we should call it first.

Oh yes, I should have noticed that.

> Also, I think it would be good to mention this bug report in the
> comment.

Done and pushed to master as 90f76eb.

Steve Berman
This bug report was last modified 8 years and 105 days ago.

Previous Next

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