GNU bug report logs - #52240
29.0.50; Build failure after 35075267a6

Previous Next

Package: emacs;

Reported by: Arash Esbati <arash <at> gnu.org>

Date: Thu, 2 Dec 2021 10:14:01 UTC

Severity: normal

Found in version 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Arash Esbati <arash <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 52240 <at> debbugs.gnu.org
Subject: bug#52240: 29.0.50; Build failure after 35075267a6
Date: Thu, 02 Dec 2021 12:47:36 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arash Esbati <arash <at> gnu.org>
>> Date: Thu, 02 Dec 2021 12:29:00 +0100
>> Cc: 52240 <at> debbugs.gnu.org
>> 
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> 
>> > What about what it's actually complaining about, then?  I.e., 
>> >
>> > (insert ?\N{left-to-right embedding})
>> 
>> Sorry, I thought I had tried that already but didn't look carefully at
>> the result.  When I do 'C-u C-x =' at the insertion, I get:
>> 
>> --8<---------------cut here---------------start------------->8---
>>              position: 308 of 308 (100%), column: 37
>>             character: ‪‬ (displayed as ‪‬) (codepoint 8234, #o20052, #x202a)
>>               charset: unicode (Unicode (ISO10646))
>> code point in charset: 0x202A
>>                script: symbol
>>                syntax: w 	which means: word
>>              category: L:Strong L2R
>>              to input: type "C-x 8 RET 202a" or "C-x 8 RET LEFT-TO-RIGHT EMBEDDING"
>>           buffer code: #xE2 #x80 #xAA
>>             file code: #xE2 #x80 #xAA (encoded by coding system utf-8-dos)
>>               display: by this font (glyph code):
>>     harfbuzz:-outline-Symbola-regular-normal-normal-serif-12-*-*-*-p-*-iso10646-1 (#x875)
>> 
>> Character code properties: customize what to show
>>   name: LEFT-TO-RIGHT EMBEDDING
>>   general-category: Cf (Other, Format)
>>   decomposition: (8234) ('‪')
>
> Which is correct, right?  or did you spot something problematic?

This is correct.  So I eval'ed (C-x C-e) the example and the entries
in `glyphless--bidi-control-characters' :

--8<---------------cut here---------------start------------->8---
?\N{latin small letter a with grave}
224 (#o340, #xe0)

?\N{right-to-left embedding}
Debugger entered--Lisp error: (void-variable embedding})
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

?\N{left-to-right override}
Debugger entered--Lisp error: (void-variable override})
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

?\N{right-to-left override}
Debugger entered--Lisp error: (void-variable override})
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

?\N{left-to-right isolate}
Debugger entered--Lisp error: (void-variable isolate})
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

?\N{right-to-left isolate}
Debugger entered--Lisp error: (void-variable isolate})
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

?\N{first strong isolate}
8296 (#o20150, #x2068)

?\N{pop directional formatting}
8236 (#o20054, #x202c)

?\N{pop directional isolate}
8297 (#o20151, #x2069)
--8<---------------cut here---------------end--------------->8---

It seems to me that something goes wrong when the unicode name contains
a hyphen?  As a random example,

?\N{LEFT-POINTING DOUBLE ANGLE QUOTATION MARK}

also complains about (void-variable MARK}).




This bug report was last modified 3 years and 172 days ago.

Previous Next


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