Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#63651 closed defect (fixed)

emacs-app-devel @20210928: recursively loading file

Reported by: telotortium (Robert Irelan) Owned by: catap (Kirill A. Korinsky)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: Cc: catap (Kirill A. Korinsky), drkp (Dan Ports)
Port: emacs-app-devel

Description

https://github.com/hlissner/doom-emacs/issues/5657 describes an instance of recursively loading a file buffers.el in Doom Emacs. No one has been able to reproduce it except on MacPorts emacs-app-devel @20210928 (with Nativecomp enabled). I was able to avoid this issue by switching my port back to the previous build @20210727_0.

Specifically, I now have this port active:

emacs-app-devel @20210727_0+imagemagick+nativecomp+rsvg

This port is broken:

emacs-app-devel @20210928_0+imagemagick+nativecomp+rsvg

Change History (8)

comment:1 Changed 3 years ago by catap (Kirill A. Korinsky)

@telotortium do you run doom clenaup or something like this to remove old native compiled files? I'm asking because I'm user of doom-emacs :)

Anyway, at least once I had discovered a good bug inside emacs with this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50534 => I'll deep into this issue deeply in few days.

comment:2 Changed 3 years ago by telotortium (Robert Irelan)

I'll take a look tomorrow and try to run doom cleanup

comment:3 Changed 3 years ago by catap (Kirill A. Korinsky)

I was wrong, you need doom purge

comment:4 Changed 3 years ago by catap (Kirill A. Korinsky)

I'd like to take care of it, but I can't assign it to me.

comment:5 Changed 3 years ago by catap (Kirill A. Korinsky)

Upgrade to 5f5189e9be6c70c4db99e8057287d16955b9c620 fixed an issue on my side. I've opened pull request https://github.com/macports/macports-ports/pull/12629

comment:6 Changed 3 years ago by telotortium (Robert Irelan)

Thanks! I will try it out.

Any idea what change in Emacs might have caused and/or fixed the issue?

comment:7 Changed 3 years ago by catap (Kirill A. Korinsky)

Owner: set to catap
Resolution: fixed
Status: newclosed

In 099bdbc9f7b95022855384f1d03708bd679b0128/macports-ports (master):

emacs{-app}-devel: update to 2021-10-20

Closes: #63651

comment:8 Changed 3 years ago by catap (Kirill A. Korinsky)

@telotortium, the issue was fixed at http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d3a832a61ab5766b6ec879cee9ab75bbbc62034a and it has related bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50946

This was introduced with shorthands implementation, at one of this commits:

58055b5fc3 * Document shorthands in the Elisp manual section on Symbols
66f3087530 * Add #_ reader macro to escape shorthand renaming
90cbf0cb8d * Consider shorthands in Elisp's elisp-completion-at-point
68d73eb154 * Rework Elisp shorthands to only allow only prefix substitution
71857d4106 * Move most of the shorthand implementation to C code
6237bad419 * First Elisp version of lisp/shorthand.el, failing some tests

My bet that it was 71857d4106, anyway, I can't proof it because I can't build it. It crashes with error:

lread.c:4433:50: error: address of register variable requested
  tem = oblookup_considering_shorthand (obarray, &string);
                                                 ^~~~~~~
1 error generated.

and 68d73eb154 fixes it, and introduces the error.

Note: See TracTickets for help on using tickets.