GNU bug report logs -
#52240
29.0.50; Build failure after 35075267a6
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52240 in the body.
You can then email your comments to 52240 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:14:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Arash Esbati <arash <at> gnu.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 02 Dec 2021 10:14:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
I can't build Emacs (Win10, Msys2) after the commit 35075267a6. The
error is:
Loading z:/pathto/emacs/lisp/international/characters.el (source)...
Loading z:/pathto/emacs/lisp/international/charscript.el (source)...
Loading z:/pathto/emacs/lisp/international/emoji-zwj.el (source)...
Invalid read syntax: "\\N{left-to-right embedding}", 1, 0
make[1]: *** [Makefile:908: bootstrap-emacs.pdmp] Error 127
Building with aaf0e62048 works. This is with a fresh repo
(git clean -fdx).
Best, Arash
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash <at> gnu.org> writes:
> Invalid read syntax: "\\N{left-to-right embedding}", 1, 0
Hm -- this works fine on Debian. Does this mean that we can't use the
\N{...} things in source code, or does the w32 Emacs have to be set up
in a different way?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:38:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Arash Esbati <arash <at> gnu.org> writes:
>
>> Invalid read syntax: "\\N{left-to-right embedding}", 1, 0
>
> Hm -- this works fine on Debian. Does this mean that we can't use the
> \N{...} things in source code, or does the w32 Emacs have to be set up
> in a different way?
Hm, can't really tell, I'm not familiar the code in characters.el, but
this
(insert ?\N{LATIN SMALL LETTER A WITH GRAVE})
inserts à. Does this help?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:38:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52240 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 02 Dec 2021 11:21:08 +0100
> Cc: 52240 <at> debbugs.gnu.org
>
> Arash Esbati <arash <at> gnu.org> writes:
>
> > Invalid read syntax: "\\N{left-to-right embedding}", 1, 0
>
> Hm -- this works fine on Debian. Does this mean that we can't use the
> \N{...} things in source code, or does the w32 Emacs have to be set up
> in a different way?
It builds fine here, but I didn't try bootstrapping.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:46:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash <at> gnu.org> writes:
> Hm, can't really tell, I'm not familiar the code in characters.el, but
> this
>
> (insert ?\N{LATIN SMALL LETTER A WITH GRAVE})
>
> inserts à. Does this help?
What about
(insert ?\N{latin small letter a with grave})
? (Perhaps the identifier is case-sensitive on some systems...)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 10:58:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> What about
>
> (insert ?\N{latin small letter a with grave})
>
> ? (Perhaps the identifier is case-sensitive on some systems...)
Works, inserts à. Would be the first time where Windows is
case-sensitive 😉
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:20:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash <at> gnu.org> writes:
> Works, inserts à. Would be the first time where Windows is
> case-sensitive 😉
What about what it's actually complaining about, then? I.e.,
(insert ?\N{left-to-right embedding})
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:30:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 52240 <at> debbugs.gnu.org (full text, mbox):
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) ('')
There are text properties here:
fontified t
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:33:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 52240 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:34:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash <at> gnu.org> writes:
> 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:
So that works too? Then... that build error is really odd. Could it
be Emacs not loading the definitions of these things early enough on
some systems?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:49:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 52240 <at> debbugs.gnu.org (full text, mbox):
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}).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 11:58:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Arash Esbati <arash <at> gnu.org> writes:
> This is correct. So I eval'ed (C-x C-e) the example and the entries
> in `glyphless--bidi-control-characters' :
You can't `C-x C-e' these things -- it doesn't understand the syntax.
(There's a bug report for that.) So you have to M-: and enter them
there (or put them inside a bigger sexp).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 12:15:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Arash Esbati <arash <at> gnu.org> writes:
>
>> This is correct. So I eval'ed (C-x C-e) the example and the entries
>> in `glyphless--bidi-control-characters' :
>
> You can't `C-x C-e' these things -- it doesn't understand the syntax.
> (There's a bug report for that.) So you have to M-: and enter them
> there (or put them inside a bigger sexp).
Ah, thanks, didn't know that. They all work with M-: Now I'm out of
ideas ☹️
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 12:17:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Hm -- this works fine on Debian. Does this mean that we can't use the
>> \N{...} things in source code, or does the w32 Emacs have to be set up
>> in a different way?
> It builds fine here, but I didn't try bootstrapping.
FWIW, I saw two people experience this issue, but bootstrapping made it
work for one of them. One was running Arch "Linux", and the other was
running macOS.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 12:44:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> It builds fine here, but I didn't try bootstrapping.
>
> FWIW, I saw two people experience this issue, but bootstrapping made it
> work for one of them. One was running Arch "Linux", and the other was
> running macOS.
As a last resort, I tried:
git clone --depth=1 https://git.savannah.gnu.org/git/emacs.git
cd emacs
./autogen.sh
./configure
make
And the issue remains.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 16:24:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen wrote:
> Hm -- this works fine on Debian.
Fails for me as described, on Debian testing, RHEL 8.5, and also on
https://hydra.nixos.org/build/160128632
I note that international/emoji-zwj.el may not be fully regenerated in
some builds. Once again, I strongly recommend that in admin/unidata (and
similar), bootstrap-clean should run gen-clean. There was opposition
to this change previously.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 16:29:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> I note that international/emoji-zwj.el may not be fully regenerated in
> some builds. Once again, I strongly recommend that in admin/unidata (and
> similar), bootstrap-clean should run gen-clean. There was opposition
> to this change previously.
Ah! Thanks; after doing an "extraclean", this fails for me, too.
Yes, I'm also in favour of having "make bootstrap" cleaning a bit more.
The added time to build stuff (which isn't massive) will probably save
us time in the long run (because we'd avoid these errors).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Thu, 02 Dec 2021 16:35:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Fails for me as described, on Debian testing, RHEL 8.5, and also on
> https://hydra.nixos.org/build/160128632
This should now be fixed -- I made it use digits instead.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
52240 <at> debbugs.gnu.org and Arash Esbati <arash <at> gnu.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 02 Dec 2021 16:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52240
; Package
emacs
.
(Fri, 03 Dec 2021 08:57:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 52240 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Glenn Morris <rgm <at> gnu.org> writes:
>
>> Fails for me as described, on Debian testing, RHEL 8.5, and also on
>> https://hydra.nixos.org/build/160128632
>
> This should now be fixed -- I made it use digits instead.
Confirmed, Emacs builds again. Thanks for fixing this.
Best, Arash
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 31 Dec 2021 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 78 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.