bug#69431: 30.0.50; Strange fontificaion behavior

bug#69431: 30.0.50; Strange fontificaion behavior

[OGAWA Hirofumi]

I met the strange font-lock behavior,

# this doesn't work
    $ echo '* Foo' > a.org
    $ emacs -Q a.org

The above opens "a.org" as org-mode, but current emacs doesn't
fontificate the buffer properly for this.

But while reproducing this behavior, I noticed the following works as
expected.

# this works
    $ echo '* Foo' > a.org
    $ emacs -Q --eval "(provide 'dbus)" a.org

Thanks.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-02-27 built on devron
Repository revision: b59d7094b6cb1a09f46f933807e9cd00a8bd1547
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid

Configured using:
 'configure --with-x-toolkit=gtk3 --without-xim --with-imagemagick
 --with-wide-int --with-native-compilation=aot'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2
M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE
XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: ja_JP.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  bug-reference-mode: t
  server-mode: t
  flycheck-pos-tip-mode: t
  global-flycheck-mode: t
  global-company-mode: t
  company-mode: t
  auto-insert-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  electric-pair-mode: t
  icomplete-mode: t
  savehist-mode: t
  repeat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/local/share/emacs/site-lisp/elpa/compat-29.1.4.4/compat hides /usr/local/share/emacs/30.0.50/lisp/emacs-lisp/compat

Features:
(shadow emacsbug grep-context comp-run comp-common bbdb-message
mailalias mule-util sort smerge-mode diff gnus-cite mm-archive mail-extr
textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check gnus-bcklg gnus-async bbdb-gnus-aux gnus-ml disp-table
hl-line elfeed-show elfeed-search bookmark elfeed-csv elfeed elfeed-curl
elfeed-log elfeed-db elfeed-lib avl-tree url-queue xml-query gnus-topic
url-http url-gw url-cache utf-7 epa-file network-stream nsm nnfolder
bbdb-gnus nnnil bbdb-mua spam spam-stat bbdb-com crm bbdb bbdb-site
timezone gnus-uu yenc gnus-demon gnus-delay gnus-draft gnus-agent
gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file svg dom nndraft nnmh gnus-xoauth2 oauth2-ext
plstore gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap
nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int
gnus-range message sendmail yank-media puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus nnheader gnus-util time-date mail-utils range mm-util
mail-prsvr dbus xml dired-aux dircolors-faces dired-x dired
dired-loaddefs company-cscope company-yasnippet flycheck-rust dash
flyspell ispell vc-hg vc-git cus-start diff-mode vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs log-view easy-mmode pcvs-util vc vc-dispatcher
bug-reference server auth-source-pass url-auth generic-x rust-utils
thingatpt rust-mode rust-prog-mode rust-rustfmt rust-playpen
rust-compile rust-cargo rust-common flycheck-relint relint compile
text-property-search comint ansi-osc xr flycheck-pos-tip pos-tip
flycheck ansi-color find-func rx company-oddmuse company-keywords
company-etags etags fileloop generator xref project ring company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company pcase autoinsert cl-extra yasnippet help-mode
elec-pair icomplete savehist advice browse-kill-ring delsel
tab-bar-session desktop frameset repeat mozc-im-plus mozc-popup popup
mozc vcard-autoloads startup-elisp-autoloads rfc-autoloads
mozc-im-plus-autoloads misc-autoloads magit-mini-autoloads
lookup-autoloads langtool-autoloads grammar-check-autoloads
go-translate-autoloads gnus-xoauth2-autoloads debian-autoloads
cxrefs-autoloads company-cscope-autoloads bbdb-loaddefs cus-edit pp
cus-load icons wid-edit browse-kill-ring-autoloads company-autoloads
coterm-autoloads csv-mode-autoloads dpkg-dev-el-autoloads
elfeed-autoloads expand-region-autoloads flycheck-rust-autoloads info
dash-autoloads flycheck-autoloads git-modes-autoloads gnuplot-autoloads
graphviz-dot-mode-autoloads grep-context-autoloads lua-mode-autoloads
markdown-mode-autoloads meson-mode-autoloads mozc-autoloads
php-mode-autoloads po-mode-autoloads popup-autoloads pos-tip-autoloads
relint-autoloads rust-mode-autoloads treesit vundo-autoloads
wgrep-autoloads xr-autoloads yaml-mode-autoloads yasnippet-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib japan-util rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)

Memory information:
((conses 16 572408 83986) (symbols 48 28032 11)
 (strings 32 234644 13139) (string-bytes 1 8411310)
 (vectors 16 110660) (vector-slots 8 1337763 69261)
 (floats 8 10932 7873) (intervals 56 1327 227) (buffers 984 28))

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Wed, 28 Feb 2024 01:58:01 +0900
> 
> 
> I met the strange font-lock behavior,
> 
> # this doesn't work
>     $ echo '* Foo' > a.org
>     $ emacs -Q a.org
> 
> The above opens "a.org" as org-mode, but current emacs doesn't
> fontificate the buffer properly for this.

I cannot reproduce this with today's master branch.  I see "* Foo"
fontified with org-level-1 face.

Maybe this is platform-dependent?

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> The above opens "a.org" as org-mode, but current emacs doesn't
>> fontificate the buffer properly for this.
>
> I cannot reproduce this with today's master branch.  I see "* Foo"
> fontified with org-level-1 face.
>
> Maybe this is platform-dependent?

I can reproduce using the latest master (with make bootstrap), using the
same steps. I cannot reproduce when changing the load path to Org git
folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
same with Emacs built-in version).

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-02-27 built on localhost
Repository revision: 82289c53c5e20f46fa715e75e1011eb62cbe40a0
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Gentoo Linux

Configured using:
 'configure JAVAC=/etc/java-config-2/current-system-vm/bin/javac'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>, 69431@debbugs.gnu.org
> Date: Tue, 27 Feb 2024 17:58:16 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I cannot reproduce this with today's master branch.  I see "* Foo"
> > fontified with org-level-1 face.
> >
> > Maybe this is platform-dependent?
> 
> I can reproduce using the latest master (with make bootstrap), using the
> same steps.

I don't want to bootstrap for this, but I removed all *.elc files from
the lisp/org/ directory and rebuilt, and I still cannot reproduce.

> I cannot reproduce when changing the load path to Org git
> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
> same with Emacs built-in version).

So maybe the problem is already solved somehow?

bug#69431: 30.0.50; Strange fontificaion behavior

[OGAWA Hirofumi]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>, 69431@debbugs.gnu.org
>> Date: Tue, 27 Feb 2024 17:58:16 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I cannot reproduce this with today's master branch.  I see "* Foo"
>> > fontified with org-level-1 face.
>> >
>> > Maybe this is platform-dependent?
>> 
>> I can reproduce using the latest master (with make bootstrap), using the
>> same steps.
>
> I don't want to bootstrap for this, but I removed all *.elc files from
> the lisp/org/ directory and rebuilt, and I still cannot reproduce.
>
>> I cannot reproduce when changing the load path to Org git
>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>> same with Emacs built-in version).
>
> So maybe the problem is already solved somehow?

I found a bit more about this. If build with --native-compilation=no, I
can't reproduce, and at least --native-compilation=aot can reproduce.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I cannot reproduce when changing the load path to Org git
>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>> same with Emacs built-in version).
>
> So maybe the problem is already solved somehow?

... or it has something to do with loading built-in Org mode.
when I do
1. emacs -Q
2. C-x C-f /tmp/a.org
I do not see fontification.

when I do
1. emacs -Q
2. M-: (require 'org)
3. C-x C-f /tmp/a.org
I see fontification...

and when I wait long enough for native compilation to finish, I can see
fontification without loading org.el.

Not sure if it tells anything useful.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
> Date: Tue, 27 Feb 2024 19:26:39 +0000
> 
> > So maybe the problem is already solved somehow?
> 
> ... or it has something to do with loading built-in Org mode.
> when I do
> 1. emacs -Q
> 2. C-x C-f /tmp/a.org
> I do not see fontification.
> 
> when I do
> 1. emacs -Q
> 2. M-: (require 'org)
> 3. C-x C-f /tmp/a.org
> I see fontification...
> 
> and when I wait long enough for native compilation to finish, I can see
> fontification without loading org.el.
> 
> Not sure if it tells anything useful.

> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
> Date: Wed, 28 Feb 2024 04:20:13 +0900
> 
> I found a bit more about this. If build with --native-compilation=no, I
> can't reproduce, and at least --native-compilation=aot can reproduce.

Since this seems to be somehow related to native compilation, I'm
adding Andrea to the discussion, in the hope that he could suggest
some ideas.

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>> 
>> > So maybe the problem is already solved somehow?
>> 
>> ... or it has something to do with loading built-in Org mode.
>> when I do
>> 1. emacs -Q
>> 2. C-x C-f /tmp/a.org
>> I do not see fontification.
>> 
>> when I do
>> 1. emacs -Q
>> 2. M-: (require 'org)
>> 3. C-x C-f /tmp/a.org
>> I see fontification...
>> 
>> and when I wait long enough for native compilation to finish, I can see
>> fontification without loading org.el.
>> 
>> Not sure if it tells anything useful.
>
>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>> 
>> I found a bit more about this. If build with --native-compilation=no, I
>> can't reproduce, and at least --native-compilation=aot can reproduce.
>
> Since this seems to be somehow related to native compilation, I'm
> adding Andrea to the discussion, in the hope that he could suggest
> some ideas.

Hi Eli,

thanks.

I suggest to disable `native-comp-jit-compilation' in the .emacs, clean
the eln-cache and run Emacs ruling out the native compiler, this in
order to understand why without '(require 'org)' fontification does not
happen.

My guess is it's because of some quirk in the code and, when the native
compiler reloads the native compiled version of the code somehow this is
fixed, at least at a first glance I'd guess is not native compiler
related (last famous words...).

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[OGAWA Hirofumi]

Andrea Corallo <acorallo@gnu.org> writes:

>>> I found a bit more about this. If build with --native-compilation=no, I
>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>
>> Since this seems to be somehow related to native compilation, I'm
>> adding Andrea to the discussion, in the hope that he could suggest
>> some ideas.
>
> Hi Eli,
>
> thanks.
>
> I suggest to disable `native-comp-jit-compilation' in the .emacs, clean
> the eln-cache and run Emacs ruling out the native compiler, this in
> order to understand why without '(require 'org)' fontification does not
> happen.
>
> My guess is it's because of some quirk in the code and, when the native
> compiler reloads the native compiled version of the code somehow this is
> fixed, at least at a first glance I'd guess is not native compiler
> related (last famous words...).

    $ echo '* Foo' > a.org
    $ emacs -Q --eval '(setq native-comp-jit-compilation nil)' a.org

This seems make fontification work (with or without clean eln-cache).

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

>>> and when I wait long enough for native compilation to finish, I can see
>>> fontification without loading org.el.
>>> 
>>> Not sure if it tells anything useful.

I bisected the problem down to commit

cf11fdfd8e460d966ba279f00633ab378038de68
Author:     Andrea Corallo <acorallo@gnu.org>
AuthorDate: Sun Dec 3 22:14:32 2023 +0100
Commit:     Andrea Corallo <acorallo@gnu.org>
CommitDate: Sun Dec 3 22:25:12 2023 +0100

Parent:     9c1f24d7a49 * lisp/emacs-lisp/macroexp.el (macroexp-parse-body): Fix bug#67568
Follows:    emacs-29.1.90 (168980)

* lisp/emacs-lisp/comp-run.el (bytecomp): Require it (bug#67590)

1 file changed, 1 insertion(+)
lisp/emacs-lisp/comp-run.el | 1 +

modified   lisp/emacs-lisp/comp-run.el
@@ -33,6 +33,7 @@
 
 (eval-when-compile (require 'cl-lib))
 (require 'comp-common)
+(require 'bytecomp) ;; For `emacs-lisp-compilation-mode'.
 
 (defgroup comp-run nil
   "Emacs Lisp native compiler runtime."


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

> I suggest to disable `native-comp-jit-compilation' in the .emacs, clean
> the eln-cache and run Emacs ruling out the native compiler, this in
> order to understand why without '(require 'org)' fontification does not
> happen.

Doing the following makes fontification happen
./src/emacs -Q --eval '(setq native-comp-jit-compilation nil)' /tmp/a.org
while just
./src/emacs -Q /tmp/a.org
has no fontification.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Ihor Radchenko <yantar92@posteo.net> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> I suggest to disable `native-comp-jit-compilation' in the .emacs, clean
>> the eln-cache and run Emacs ruling out the native compiler, this in
>> order to understand why without '(require 'org)' fontification does not
>> happen.
>
> Doing the following makes fontification happen
> ./src/emacs -Q --eval '(setq native-comp-jit-compilation nil)' /tmp/a.org
> while just
> ./src/emacs -Q /tmp/a.org
> has no fontification.

Mmmhhh, could you dump load-history for the two cases?

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Andrea Corallo <acorallo@gnu.org> writes:

>> Doing the following makes fontification happen
>> ./src/emacs -Q --eval '(setq native-comp-jit-compilation nil)' /tmp/a.org
>> while just
>> ./src/emacs -Q /tmp/a.org
>> has no fontification.
>
> Mmmhhh, could you dump load-history for the two cases?

See the attached.

[-- Attachment #2: fontification.eld.gz --]
[-- Type: application/gzip, Size: 146202 bytes --]

[-- Attachment #3: no-fontification.eld.gz --]
[-- Type: application/gzip, Size: 145875 bytes --]

[-- Attachment #4: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Ihor Radchenko <yantar92@posteo.net>
>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>
>>> > So maybe the problem is already solved somehow?
>>>
>>> ... or it has something to do with loading built-in Org mode.
>>> when I do
>>> 1. emacs -Q
>>> 2. C-x C-f /tmp/a.org
>>> I do not see fontification.
>>>
>>> when I do
>>> 1. emacs -Q
>>> 2. M-: (require 'org)
>>> 3. C-x C-f /tmp/a.org
>>> I see fontification...
>>>
>>> and when I wait long enough for native compilation to finish, I can see
>>> fontification without loading org.el.
>>>
>>> Not sure if it tells anything useful.
>>
>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>
>>> I found a bit more about this. If build with --native-compilation=no, I
>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>
>> Since this seems to be somehow related to native compilation, I'm
>> adding Andrea to the discussion, in the hope that he could suggest
>> some ideas.
>
> I have the same error since my last build ref
> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>
> When running without gdb Emacs just tells in the minubuffer:
> Re-entering top level after C-stack overflow.

Okay, might be some recursive dependecy issue while loading?
>
> With gdb I get a SIGEGV in lface_from_face_name.
> I attach two log files I've created. It was hard to get an exact point
> since the bug only triggers when enough is loaded. At first there's
> memory corruption but no crash.

Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
understand what we are trying to load and in which order before we stack
overflow.

Another idea would be to apply something like the following to
Frequire, run a make, and run again the reproducer to understand what's
going on.

modified   src/fns.c
@@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
   bool from_file = load_in_progress;

   CHECK_SYMBOL (feature);
+  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));

   /* Record the presence of `require' in this file
      even if the feature specified is already loaded.

I'd do the investigation myself but my dev machine went KO yesterday and
to get it fixed it might take till next week :/

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 6331 bytes --]

Andrea Corallo <acorallo@gnu.org> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Ihor Radchenko <yantar92@posteo.net>
>>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>>
>>>> > So maybe the problem is already solved somehow?
>>>>
>>>> ... or it has something to do with loading built-in Org mode.
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. C-x C-f /tmp/a.org
>>>> I do not see fontification.
>>>>
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. M-: (require 'org)
>>>> 3. C-x C-f /tmp/a.org
>>>> I see fontification...
>>>>
>>>> and when I wait long enough for native compilation to finish, I can see
>>>> fontification without loading org.el.
>>>>
>>>> Not sure if it tells anything useful.
>>>
>>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>>
>>>> I found a bit more about this. If build with --native-compilation=no, I
>>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>>
>>> Since this seems to be somehow related to native compilation, I'm
>>> adding Andrea to the discussion, in the hope that he could suggest
>>> some ideas.
>>
>> I have the same error since my last build ref
>> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in
>> 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>>
>> When running without gdb Emacs just tells in the minubuffer:
>> Re-entering top level after C-stack overflow.
>
> Okay, might be some recursive dependecy issue while loading?
It does sound like it.

>>
>> With gdb I get a SIGEGV in lface_from_face_name.
>> I attach two log files I've created. It was hard to get an exact point
>> since the bug only triggers when enough is loaded. At first there's
>> memory corruption but no crash.
>
> Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
> understand what we are trying to load and in which order before we stack
> overflow.
>
> Another idea would be to apply something like the following to
> Frequire, run a make, and run again the reproducer to understand what's
> going on.
>
> modified   src/fns.c
> @@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
>    bool from_file = load_in_progress;
>
>    CHECK_SYMBOL (feature);
> +  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));

I added the message in the case of my init.el it looks like this:
XXX comp
XXX bytecomp
XXX backquote
XXX macroexp
XXX cconv
XXX cl-lib
XXX macroexp
XXX gv
XXX macroexp
XXX rx
XXX subr-x
XXX warnings
XXX icons
XXX cl-lib
XXX comp-common
XXX comp-cstr
XXX cl-lib
XXX cl-extra
XXX cl-lib
XXX seq
XXX help-mode
XXX cl-lib
XXX cl-lib
XXX borg
XXX bytecomp
XXX cl-lib
XXX info
XXX pcase
XXX macroexp
XXX subr-x
XXX loaddefs-gen
XXX radix-tree
XXX lisp-mnt
XXX generate-lisp-file
XXX eieio
XXX eieio-core
XXX cl-lib
XXX cl-macs
XXX cl-lib
XXX macroexp
XXX gv
XXX cl-generic
XXX bytecomp
XXX macroexp
XXX use-package
XXX use-package-core
XXX bytecomp
XXX cl-lib
XXX tabulated-list
XXX use-package-bind-key
XXX use-package-core
XXX bind-key
XXX cl-lib
XXX easy-mmode
XXX use-package-diminish
XXX use-package-core
XXX use-package-delight
XXX use-package-core
XXX use-package-ensure
XXX cl-lib
XXX use-package-core
XXX comp-run
XXX comp-common
XXX bytecomp
XXX epkg
XXX compat
XXX llama
XXX seq
XXX seq
XXX subr-x
XXX closql
XXX compat
XXX eieio
XXX eieio-base
XXX eieio
XXX seq
XXX emacsql
XXX cl-lib
XXX cl-generic
XXX eieio
XXX emacsql-compiler
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX gv
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX emacsql-sqlite-common
XXX emacsql
XXX cl-lib
XXX subr-x
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX macroexp
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX epkg-desc
XXX epkg
XXX find-func
XXX wid-edit
XXX cl-lib
XXX cl-lib
XXX epkg-list
XXX epkg
XXX epkg-desc
XXX epkg-utils
XXX epkg
XXX cl-lib
XXX cl-lib
XXX epkg-elpa
XXX epkg
XXX json
XXX map
XXX seq
XXX subr-x
XXX no-littering
XXX cl-lib
XXX compat
XXX custom
XXX select
XXX saveplace
XXX cl-lib
XXX cl-lib
XXX seq
XXX kmacro
XXX replace
XXX cl-lib
XXX desktop
XXX cl-lib
XXX frameset
XXX cl-lib
XXX printing
XXX lpr
XXX ps-print
XXX lpr
XXX ps-print-loaddefs
XXX cus-face
XXX wid-edit
XXX icons
XXX cus-load
XXX cus-start
XXX cl-lib
XXX cus-load
XXX cus-start
XXX cus-start
XXX auth-source-pass
XXX seq
XXX cl-lib
XXX auth-source
XXX json
XXX password-cache
XXX cl-lib
XXX eieio
XXX url-parse
XXX url-vars
XXX auth-source
XXX helm-pass
XXX helm
XXX helm-core
XXX cl-lib
XXX async
XXX cl-lib
XXX helm-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX helm-multi-match
XXX cl-lib
XXX helm-lib
XXX helm-source
XXX cl-lib
XXX eieio
XXX helm-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX cl-lib
XXX async-bytecomp
XXX cl-lib
XXX async
XXX bytecomp
XXX helm-global-bindings
XXX helm-lib
XXX helm-easymenu
XXX easymenu
XXX password-store
XXX with-editor
XXX cl-lib
XXX compat
XXX server
XXX shell
XXX comint
XXX ring
XXX ansi-color
XXX ansi-osc
XXX regexp-opt
XXX pcomplete
XXX comint
XXX subr-x
XXX subr-x
XXX macroexp
XXX auth-source-pass
XXX auth-source-pass
XXX thingatpt
XXX seq
XXX modus-themes
XXX modus-themes


> I'd do the investigation myself but my dev machine went KO yesterday and
> to get it fixed it might take till next week :/
>
> Thanks
>
>   Andrea


Is the it normal that gdb tell me:
warning: Corrupted shared library list: 0x1701f5b0 != 0x19cf8b60

When running Emacs in GDB?
I have the same error with my last known good version.

I've attach the current log I have and try further.

[-- Attachment #2: emacs.ff20898dad8.log.gz --]
[-- Type: application/x-gzip, Size: 1342081 bytes --]

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

One issue with the problem I noticed with erros I receive that they all
happen after building emacs with make bootstrap.
Even in the "good" revisions.

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Ihor Radchenko <yantar92@posteo.net>
>>>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>>>
>>>>> > So maybe the problem is already solved somehow?
>>>>>
>>>>> ... or it has something to do with loading built-in Org mode.
>>>>> when I do
>>>>> 1. emacs -Q
>>>>> 2. C-x C-f /tmp/a.org
>>>>> I do not see fontification.
>>>>>
>>>>> when I do
>>>>> 1. emacs -Q
>>>>> 2. M-: (require 'org)
>>>>> 3. C-x C-f /tmp/a.org
>>>>> I see fontification...
>>>>>
>>>>> and when I wait long enough for native compilation to finish, I can see
>>>>> fontification without loading org.el.
>>>>>
>>>>> Not sure if it tells anything useful.
>>>>
>>>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>>>
>>>>> I found a bit more about this. If build with --native-compilation=no, I
>>>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>>>
>>>> Since this seems to be somehow related to native compilation, I'm
>>>> adding Andrea to the discussion, in the hope that he could suggest
>>>> some ideas.
>>>
>>> I have the same error since my last build ref
>>> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in
>>> 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>>>
>>> When running without gdb Emacs just tells in the minubuffer:
>>> Re-entering top level after C-stack overflow.
>>
>> Okay, might be some recursive dependecy issue while loading?
> It does sound like it.
>
>>>
>>> With gdb I get a SIGEGV in lface_from_face_name.
>>> I attach two log files I've created. It was hard to get an exact point
>>> since the bug only triggers when enough is loaded. At first there's
>>> memory corruption but no crash.
>>
>> Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
>> understand what we are trying to load and in which order before we stack
>> overflow.
>>
>> Another idea would be to apply something like the following to
>> Frequire, run a make, and run again the reproducer to understand what's
>> going on.
>>
>> modified   src/fns.c
>> @@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
>>    bool from_file = load_in_progress;
>>
>>    CHECK_SYMBOL (feature);
>> +  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));
>
> I added the message in the case of my init.el it looks like this:
> XXX comp
> XXX bytecomp
> XXX backquote
> XXX macroexp
> XXX cconv
> XXX cl-lib
> XXX macroexp
> XXX gv
> XXX macroexp
> XXX rx
> XXX subr-x
> XXX warnings
> XXX icons
> XXX cl-lib
> XXX comp-common
> XXX comp-cstr
> XXX cl-lib
> XXX cl-extra
> XXX cl-lib
> XXX seq
> XXX help-mode
> XXX cl-lib
> XXX cl-lib
> XXX borg
> XXX bytecomp
> XXX cl-lib
> XXX info
> XXX pcase
> XXX macroexp
> XXX subr-x
> XXX loaddefs-gen
> XXX radix-tree
> XXX lisp-mnt
> XXX generate-lisp-file
> XXX eieio
> XXX eieio-core
> XXX cl-lib
> XXX cl-macs
> XXX cl-lib
> XXX macroexp
> XXX gv
> XXX cl-generic
> XXX bytecomp
> XXX macroexp
> XXX use-package
> XXX use-package-core
> XXX bytecomp
> XXX cl-lib
> XXX tabulated-list
> XXX use-package-bind-key
> XXX use-package-core
> XXX bind-key
> XXX cl-lib
> XXX easy-mmode
> XXX use-package-diminish
> XXX use-package-core
> XXX use-package-delight
> XXX use-package-core
> XXX use-package-ensure
> XXX cl-lib
> XXX use-package-core
> XXX comp-run
> XXX comp-common
> XXX bytecomp
> XXX epkg
> XXX compat
> XXX llama
> XXX seq
> XXX seq
> XXX subr-x
> XXX closql
> XXX compat
> XXX eieio
> XXX eieio-base
> XXX eieio
> XXX seq
> XXX emacsql
> XXX cl-lib
> XXX cl-generic
> XXX eieio
> XXX emacsql-compiler
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX gv
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX emacsql-sqlite-common
> XXX emacsql
> XXX cl-lib
> XXX subr-x
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX macroexp
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX epkg-desc
> XXX epkg
> XXX find-func
> XXX wid-edit
> XXX cl-lib
> XXX cl-lib
> XXX epkg-list
> XXX epkg
> XXX epkg-desc
> XXX epkg-utils
> XXX epkg
> XXX cl-lib
> XXX cl-lib
> XXX epkg-elpa
> XXX epkg
> XXX json
> XXX map
> XXX seq
> XXX subr-x
> XXX no-littering
> XXX cl-lib
> XXX compat
> XXX custom
> XXX select
> XXX saveplace
> XXX cl-lib
> XXX cl-lib
> XXX seq
> XXX kmacro
> XXX replace
> XXX cl-lib
> XXX desktop
> XXX cl-lib
> XXX frameset
> XXX cl-lib
> XXX printing
> XXX lpr
> XXX ps-print
> XXX lpr
> XXX ps-print-loaddefs
> XXX cus-face
> XXX wid-edit
> XXX icons
> XXX cus-load
> XXX cus-start
> XXX cl-lib
> XXX cus-load
> XXX cus-start
> XXX cus-start
> XXX auth-source-pass
> XXX seq
> XXX cl-lib
> XXX auth-source
> XXX json
> XXX password-cache
> XXX cl-lib
> XXX eieio
> XXX url-parse
> XXX url-vars
> XXX auth-source
> XXX helm-pass
> XXX helm
> XXX helm-core
> XXX cl-lib
> XXX async
> XXX cl-lib
> XXX helm-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX helm-multi-match
> XXX cl-lib
> XXX helm-lib
> XXX helm-source
> XXX cl-lib
> XXX eieio
> XXX helm-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX cl-lib
> XXX async-bytecomp
> XXX cl-lib
> XXX async
> XXX bytecomp
> XXX helm-global-bindings
> XXX helm-lib
> XXX helm-easymenu
> XXX easymenu
> XXX password-store
> XXX with-editor
> XXX cl-lib
> XXX compat
> XXX server
> XXX shell
> XXX comint
> XXX ring
> XXX ansi-color
> XXX ansi-osc
> XXX regexp-opt
> XXX pcomplete
> XXX comint
> XXX subr-x
> XXX subr-x
> XXX macroexp
> XXX auth-source-pass
> XXX auth-source-pass
> XXX thingatpt
> XXX seq
> XXX modus-themes
> XXX modus-themes
>

Thanks Björn that's helpful, could we try with the following instead?

modified   src/lread.c
@@ -1402,6 +1402,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
   int version;
 
   CHECK_STRING (file);
+  printf ("YYY %s\n", SSDATA (file));
 
   /* If file name is magic, call the handler.  */
   handler = Ffind_file_name_handler (file, Qload);




>> I'd do the investigation myself but my dev machine went KO yesterday and
>> to get it fixed it might take till next week :/
>>
>> Thanks
>>
>>   Andrea
>
>
> Is the it normal that gdb tell me:
> warning: Corrupted shared library list: 0x1701f5b0 != 0x19cf8b60
>
> When running Emacs in GDB?
> I have the same error with my last known good version.

I think so, I've seen this in the past and never bothered too much (but
I'm not a gdb guru so I can't give you a good explanation).

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Andrea Corallo <acorallo@gnu.org> writes:

> Thanks Björn that's helpful, could we try with the following instead?
>
> modified   src/lread.c
> @@ -1402,6 +1402,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
>    int version;
>
>    CHECK_STRING (file);
> +  printf ("YYY %s\n", SSDATA (file));
>
>    /* If file name is magic, call the handler.  */
>    handler = Ffind_file_name_handler (file, Qload);

Yes here's the output:

[-- Attachment #2: files.loaded --]
[-- Type: text/plain, Size: 21969 bytes --]

YYY /usr/share/emacs/30.0.50/site-lisp/subdirs.el
YYY /usr/share/emacs/30.0.50/site-lisp/leim-list.el
YYY /usr/share/emacs/30.0.50/site-lisp/term/subdirs.el
YYY /usr/share/emacs/30.0.50/site-lisp/term/leim-list.el
YYY /usr/share/emacs/site-lisp/subdirs.el
YYY /usr/share/emacs/site-lisp/leim-list.el
YYY /usr/share/emacs/site-lisp/auctex/subdirs.el
YYY /usr/share/emacs/site-lisp/auctex/leim-list.el
YYY /usr/share/emacs/site-lisp/pdf-tools/subdirs.el
YYY /usr/share/emacs/site-lisp/pdf-tools/leim-list.el
YYY /usr/share/emacs/site-lisp/site-start.d/subdirs.el
YYY /usr/share/emacs/site-lisp/site-start.d/leim-list.el
YYY /usr/share/emacs/site-lisp/tablist/subdirs.el
YYY /usr/share/emacs/site-lisp/tablist/leim-list.el
YYY /usr/share/emacs/site-lisp/auctex/images/subdirs.el
YYY /usr/share/emacs/site-lisp/auctex/images/leim-list.el
YYY /home/bidar/dev/emacs/emacs/lisp/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/vc/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/use-package/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/url/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/textmodes/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/progmodes/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/play/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/org/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/nxml/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/net/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/mh-e/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/mail/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/leim/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/language/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/international/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/image/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/gnus/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/eshell/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/erc/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/emulation/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/emacs-lisp/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/cedet/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/calendar/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/calc/subdirs.el
YYY /home/bidar/dev/emacs/emacs/lisp/obsolete/subdirs.el
YYY /home/bidar/.local/etc/emacs/early-init
YYY site-start
YYY /usr/lib/ispell/ispell-emacs-menu.el
YYY ispell
YYY /usr/share/emacs/site-lisp/suse-start-auctex.el
YYY auctex.el
YYY /usr/share/emacs/site-lisp/tex-site.el
YYY auctex-autoloads
YYY /usr/share/emacs/site-lisp/suse-start-autoconf-el.el
YYY /usr/share/emacs/site-lisp/suse-start-po-mode.el
YYY /usr/share/emacs/site-lisp/suse-start-preview-latex.el
YYY preview-latex.el
YYY /usr/share/emacs/site-lisp/suse-start-quilt-mode.el
YYY /usr/share/emacs/site-lisp/site-start.d/archsitedir.el
YYY /usr/share/emacs/site-lisp/site-start.d/auctex.el
YYY /usr/share/emacs/site-lisp/site-start.d/pdf-tools-init.el
YYY /usr/share/emacs/site-lisp/pdf-tools/pdf-tools-autoloads.el
YYY /usr/share/emacs/site-lisp/site-start.d/preview-latex.el
YYY /usr/share/emacs/site-lisp/site-start.d/tablist-init.el
YYY /usr/share/emacs/site-lisp/site-start.d/vterm-init.el
YYY comp
YYY bytecomp
YYY cl-extra
YYY cl-lib
YYY cl-loaddefs
YYY help-mode
YYY cl-macs
YYY gv
YYY cl-seq
YYY rx
YYY subr-x
YYY warnings
YYY icons
YYY comp-cstr
YYY term/locale
YYY /home/bidar/.local/etc/emacs/init
YYY borg
YYY info
YYY pcase
YYY loaddefs-gen
YYY radix-tree
YYY lisp-mnt
YYY generate-lisp-file
YYY eieio
YYY eieio-core
YYY byte-opt
YYY derived
YYY /home/bidar/.local/private/etc/emacs/lib/a/a-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ace-link/ace-link-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ace-window/ace-window-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ag/ag-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/aio/aio-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/alert/alert-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/all-the-icons/all-the-icons-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/anaconda-mode/anaconda-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/async/async-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/atomic-chrome/atomic-chrome-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/auto-compile/auto-compile-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/autocrypt/autocrypt-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/avy/avy-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/back-button/back-button-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/bbdb/lisp/bbdb-loaddefs.el
YYY /home/bidar/.local/private/etc/emacs/lib/bbdb-vcard/bbdb-vcard-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/bitbake-modes/bitbake-modes-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/borg/borg-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/bug-mode/lisp/bug-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/bui/bui-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/buttercup/buttercup-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ccls/ccls-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/cdlatex/cdlatex-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/circe/circe-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/circe-notifications/circe-notifications-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/closql/closql-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/cmake-font-lock/cmake-font-lock-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/cmake-mode/cmake-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/code-review/code-review-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company/company-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-anaconda/company-anaconda-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-emoji/company-emoji-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-irony/company-irony-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-lua/company-lua-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-nginx/company-nginx-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-quickhelp/company-quickhelp-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/company-shell/company-shell-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/compat/compat-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/copy-as-format/copy-as-format-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/crux/crux-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/cursor-chg/cursor-chg-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dap-mode/dap-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dash/dash-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/datetime/datetime-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/debbugs/debbugs-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/default-text-scale/default-text-scale-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/deferred/deferred-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/devhelp/devhelp-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dired-du/dired-du-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dired-hacks/dired-hacks-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dired-rsync/dired-rsync-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/doom-modeline/doom-modeline-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/dumb-jump/dumb-jump-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/edit-indirect/edit-indirect-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/editorconfig/editorconfig-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/eimp/eimp-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/el-mock/el-mock-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed/elfeed-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed-autotag/elfeed-autotag-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed-protocol/elfeed-protocol-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed-score/elfeed-score-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed-summary/elfeed-summary-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elfeed-tube/elfeed-tube-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/elixir-mode/elixir-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/emacsql/emacsql-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/emojify/emojify-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/epkg/lisp/epkg-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/evil/evil-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/evil-multiedit/evil-multiedit-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/expand-region/expand-region-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/extmap/extmap-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/f/f-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/fedi/fedi-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/flycheck/flycheck-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/flycheck-color-mode-line/flycheck-color-mode-line-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/forge/lisp/forge-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/frames-only-mode/frames-only-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ggtags/ggtags-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ghub/lisp/ghub-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/git-modes/git-modes-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/gitconfig/gitconfig-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/gnus-alias/gnus-alias-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/gnus-desktop-notify/gnus-desktop-notify-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/gnus-notes/gnus-notes-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/gnus-recent/gnus-recent-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/goto-chg/goto-chg-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/grep-context/grep-context-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/guess-language/guess-language-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm/helm-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-circe/helm-circe-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-descbinds/helm-descbinds-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-emms/helm-emms-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-ext/helm-ext-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-icons/helm-icons-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-ls-git/helm-ls-git-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-make/helm-make-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-org-rifle/helm-org-rifle-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-pass/helm-pass-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/helm-projectile/helm-projectile-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/highlight-indent-guides/highlight-indent-guides-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ht/ht-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/htmlize/htmlize-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/hydra/hydra-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/i3/i3-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/i3wm-config-mode/i3wm-config-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ibuffer-projectile/ibuffer-projectile-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ical2org/ical2org-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/iedit/iedit-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ir-black-theme/ir-black-theme-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/irony/irony-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ivy/ivy-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/jira-markup-mode/jira-markup-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/js2-mode/js2-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/khardel/khardel-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/levenshtein/levenshtein-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ligature/ligature-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/link-hint/link-hint-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lisp/lisp-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/llama/llama-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/logview/logview-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lsp-docker/lsp-docker-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lsp-mode/lsp-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lsp-treemacs/lsp-treemacs-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lsp-ui/lsp-ui-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/lua-mode/lua-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/magit/lisp/magit-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/magit-popup/magit-popup-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/marginalia/marginalia-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/markdown-mode/markdown-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/mastodon/lisp/mastodon-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/meson-mode/meson-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/message-attachment-reminder/message-attachment-reminder-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/message-view-patch/message-view-patch-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/message-x/message-x-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/minions/minions-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/mmm-mode/mmm-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/mode-icons/mode-icons-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/modus-themes/modus-themes-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/move-text/move-text-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/mpv/mpv-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/multi-vterm/multi-vterm-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/multiple-cursors/multiple-cursors-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/navi-mode/navi-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/nerd-icons/nerd-icons-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/nerd-icons-ibuffer/nerd-icons-ibuffer-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/nginx-mode/nginx-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/no-littering/no-littering-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org/lisp/org-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-appear/org-appear-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-caldav/org-caldav-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-contacts/org-contacts-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-contrib/lisp/org-contrib-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-edit-indirect/org-edit-indirect-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-modern/org-modern-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-pomodoro/org-pomodoro-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-super-agenda/org-super-agenda-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-tree-slide/org-tree-slide-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/org-vcard/org-vcard-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/orgit/orgit-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/orgit-forge/orgit-forge-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/outorg/outorg-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/outshine/outshine-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/pass/pass-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/password-store/contrib/emacs/password-store-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/persist/persist-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/persp-mode/persp-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/perspective/perspective-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/pfuture/pfuture-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/piper/piper-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/pkgbuild-mode/pkgbuild-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/plantuml-mode/plantuml-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/popup/popup-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/pos-tip/pos-tip-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/posframe/posframe-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/projectile/projectile-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/pythonic/pythonic-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/qml-mode/qml-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/rainbow-delimiters/rainbow-delimiters-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/request/request-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/rich-minority/rich-minority-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/rpm-spec-mode/rpm-spec-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/s/s-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/selected/selected-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/shrink-path/shrink-path-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/simple-httpd/simple-httpd-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/skewer-mode/skewer-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/smart-region/smart-region-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/smartparens/smartparens-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/smartrep/smartrep-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/spinner/spinner-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ssh-config-mode/ssh-config-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/swiper-helm/swiper-helm-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/symbol-overlay/symbol-overlay-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/systemd/systemd-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/toml-mode/toml-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/transient/lisp/transient-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/treemacs/src/elisp/treemacs-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/treemacs-nerd-icons/treemacs-nerd-icons-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/treepy/treepy-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ts/ts-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/use-package/use-package-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/uuidgen/uuidgen-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/vc-osc/vc-osc-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/vim-modeline/vim-modeline-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/vlf/vlf-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/w3m/shimbun/w3m-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/web-mode/web-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/websocket/websocket-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/wgrep/wgrep-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/which-key/which-key-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/whole-line-or-region/whole-line-or-region-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/with-editor/lisp/with-editor-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/ws-butler/ws-butler-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/xterm-color/xterm-color-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/yaml/yaml-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/yaml-mode/yaml-mode-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/yasnippet/yasnippet-autoloads.el
YYY /home/bidar/.local/private/etc/emacs/lib/zop-to-char/zop-to-char-autoloads.el
YYY use-package
YYY use-package-core
YYY use-package-bind-key
YYY bind-key
YYY easy-mmode
YYY use-package-diminish
YYY use-package-delight
YYY use-package-ensure
YYY epkg
YYY compat
YYY llama
YYY closql
YYY eieio-base
YYY emacsql
YYY emacsql-compiler
YYY emacsql-sqlite-common
YYY epkg-desc
YYY find-func
YYY wid-edit
YYY epkg-list
YYY epkg-utils
YYY epkg-elpa
YYY json
YYY map
YYY no-littering
YYY delsel
YYY saveplace
YYY edmacro
YYY kmacro
YYY desktop
YYY frameset
YYY printing
YYY lpr
YYY ps-print
YYY ps-print-loaddefs
YYY cus-edit
YYY cus-load
YYY cus-start
YYY pp
YYY cus-start
YYY cus-start
YYY auth-source-pass
YYY auth-source
YYY password-cache
YYY url-parse
YYY url-vars
YYY helm-pass
YYY helm
YYY helm-core
YYY async
YYY helm-lib
YYY helm-multi-match
YYY helm-source
YYY async-bytecomp
YYY helm-global-bindings
YYY helm-easymenu
YYY password-store
YYY with-editor
YYY server
YYY shell
YYY comint
YYY ring
YYY ansi-color
YYY ansi-osc
YYY pcomplete
YYY thingatpt
YYY modus-themes
YYY /home/bidar/.local/private/etc/emacs/lib/modus-themes/modus-vivendi-theme
YYY savehist
YYY /home/bidar/.local/etc/emacs/var/savehist.el
YYY autorevert
YYY filenotify

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Thanks Björn that's helpful, could we try with the following instead?
>>
>> modified   src/lread.c
>> @@ -1402,6 +1402,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
>>    int version;
>>
>>    CHECK_STRING (file);
>> +  printf ("YYY %s\n", SSDATA (file));
>>
>>    /* If file name is magic, call the handler.  */
>>    handler = Ffind_file_name_handler (file, Qload);
>
> Yes here's the output:
>

[...]

Thanks, I can't see anything evidently wrong in the two traces.

I need my machine to look into it, I should have it tomorrow/beginning
of next week.

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <acorallo@gnu.org> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> Thanks Björn that's helpful, could we try with the following instead?
>>>
>>> modified   src/lread.c
>>> @@ -1402,6 +1402,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
>>>    int version;
>>>
>>>    CHECK_STRING (file);
>>> +  printf ("YYY %s\n", SSDATA (file));
>>>
>>>    /* If file name is magic, call the handler.  */
>>>    handler = Ffind_file_name_handler (file, Qload);
>>
>> Yes here's the output:
>>
>
> [...]
>
> Thanks, I can't see anything evidently wrong in the two traces.

I verified if anything is wrong in my setup but reverting to the last
known good ref c59c8db98a1d031a20ec7850978653657e394baa made everything
work again.
One thing I noticed when updating my package is that building without
make bootstrap was impossible. Only after make bootstrap the build did
succeed again.

> I need my machine to look into it, I should have it tomorrow/beginning
> of next week.

Good look. Thanks for your work.

Björn

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <acorallo@gnu.org> writes:

> Thanks, I can't see anything evidently wrong in the two traces.

Did you check the attached gdb logs?

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Andrea Corallo <acorallo@gnu.org> writes:

> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Ihor Radchenko <yantar92@posteo.net>
>>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>>
>>>> > So maybe the problem is already solved somehow?
>>>>
>>>> ... or it has something to do with loading built-in Org mode.
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. C-x C-f /tmp/a.org
>>>> I do not see fontification.
>>>>
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. M-: (require 'org)
>>>> 3. C-x C-f /tmp/a.org
>>>> I see fontification...
>>>>
>>>> and when I wait long enough for native compilation to finish, I can see
>>>> fontification without loading org.el.
>>>>
>>>> Not sure if it tells anything useful.
>>>
>>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>>
>>>> I found a bit more about this. If build with --native-compilation=no, I
>>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>>
>>> Since this seems to be somehow related to native compilation, I'm
>>> adding Andrea to the discussion, in the hope that he could suggest
>>> some ideas.
>>
>> I have the same error since my last build ref
>> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>>
>> When running without gdb Emacs just tells in the minubuffer:
>> Re-entering top level after C-stack overflow.
>
> Okay, might be some recursive dependecy issue while loading?
>>
>> With gdb I get a SIGEGV in lface_from_face_name.
>> I attach two log files I've created. It was hard to get an exact point
>> since the bug only triggers when enough is loaded. At first there's
>> memory corruption but no crash.
>
> Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
> understand what we are trying to load and in which order before we stack
> overflow.
>
> Another idea would be to apply something like the following to
> Frequire, run a make, and run again the reproducer to understand what's
> going on.
>
> modified   src/fns.c
> @@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
>    bool from_file = load_in_progress;
>
>    CHECK_SYMBOL (feature);
> +  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));
>
>    /* Record the presence of `require' in this file
>       even if the feature specified is already loaded.
>
> I'd do the investigation myself but my dev machine went KO yesterday and
> to get it fixed it might take till next week :/
>
> Thanks
>
>   Andrea

I found the culprit of the problem: it's load-theme.
The only theme's could trigger the bugs so far for me where modus
themes.

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Björn Bidar <bjorn.bidar@thaodan.de> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Ihor Radchenko <yantar92@posteo.net>
>>>>> Cc: hirofumi@mail.parknet.co.jp, 69431@debbugs.gnu.org
>>>>> Date: Tue, 27 Feb 2024 19:26:39 +0000
>>>>>
>>>>> > So maybe the problem is already solved somehow?
>>>>>
>>>>> ... or it has something to do with loading built-in Org mode.
>>>>> when I do
>>>>> 1. emacs -Q
>>>>> 2. C-x C-f /tmp/a.org
>>>>> I do not see fontification.
>>>>>
>>>>> when I do
>>>>> 1. emacs -Q
>>>>> 2. M-: (require 'org)
>>>>> 3. C-x C-f /tmp/a.org
>>>>> I see fontification...
>>>>>
>>>>> and when I wait long enough for native compilation to finish, I can see
>>>>> fontification without loading org.el.
>>>>>
>>>>> Not sure if it tells anything useful.
>>>>
>>>>> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>>>>> Cc: Ihor Radchenko <yantar92@posteo.net>, 69431@debbugs.gnu.org
>>>>> Date: Wed, 28 Feb 2024 04:20:13 +0900
>>>>>
>>>>> I found a bit more about this. If build with --native-compilation=no, I
>>>>> can't reproduce, and at least --native-compilation=aot can reproduce.
>>>>
>>>> Since this seems to be somehow related to native compilation, I'm
>>>> adding Andrea to the discussion, in the hope that he could suggest
>>>> some ideas.
>>>
>>> I have the same error since my last build ref
>>> 1687adcb5c93b490e2e7edcd14615af295e791ed same issue later in 6a77355527b2f7f1dca9c2296c2684033c9aa875.
>>>
>>> When running without gdb Emacs just tells in the minubuffer:
>>> Re-entering top level after C-stack overflow.
>>
>> Okay, might be some recursive dependecy issue while loading?
>>>
>>> With gdb I get a SIGEGV in lface_from_face_name.
>>> I attach two log files I've created. It was hard to get an exact point
>>> since the bug only triggers when enough is loaded. At first there's
>>> memory corruption but no crash.
>>
>> Would be cool to have a Lisp backtrace at the moment of the SIGEGV to
>> understand what we are trying to load and in which order before we stack
>> overflow.
>>
>> Another idea would be to apply something like the following to
>> Frequire, run a make, and run again the reproducer to understand what's
>> going on.
>>
>> modified   src/fns.c
>> @@ -3408,6 +3408,7 @@ DEFUN ("require", Frequire, Srequire, 1, 3, 0,
>>    bool from_file = load_in_progress;
>>
>>    CHECK_SYMBOL (feature);
>> +  printf ("XXX %s\n", SSDATA (Fsymbol_name (feature)));
>>
>>    /* Record the presence of `require' in this file
>>       even if the feature specified is already loaded.
>>
>> I'd do the investigation myself but my dev machine went KO yesterday and
>> to get it fixed it might take till next week :/
>>
>> Thanks
>>
>>   Andrea
>
> I found the culprit of the problem: it's load-theme.
> The only theme's could trigger the bugs so far for me where modus
> themes.

Hi Björn,

thanks.  Sorry I had to pause on this as I'm focused on fixing
everything I've broke recently on master 😅.  I'll be back on looking at
this soon.

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I cannot reproduce when changing the load path to Org git
>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>>> same with Emacs built-in version).
>>
>> So maybe the problem is already solved somehow?
>
> ... or it has something to do with loading built-in Org mode.
> when I do
> 1. emacs -Q
> 2. C-x C-f /tmp/a.org
> I do not see fontification.

On 415604c7a77 (current master) I'm having trouble reproducing this.
Both with the eln cache empty both with it already warmed.

Is this just local on my machine or the bug vanished? 🤔

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[OGAWA Hirofumi]

Andrea Corallo <acorallo@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> I cannot reproduce when changing the load path to Org git
>>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>>>> same with Emacs built-in version).
>>>
>>> So maybe the problem is already solved somehow?
>>
>> ... or it has something to do with loading built-in Org mode.
>> when I do
>> 1. emacs -Q
>> 2. C-x C-f /tmp/a.org
>> I do not see fontification.
>
> On 415604c7a77 (current master) I'm having trouble reproducing this.
> Both with the eln cache empty both with it already warmed.
>
> Is this just local on my machine or the bug vanished? 🤔

I'm still able to reproduce this on 415604c7a77.

    $ emacs -Q a.org

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

>> when I do
>> 1. emacs -Q
>> 2. C-x C-f /tmp/a.org
>> I do not see fontification.
>
> On 415604c7a77 (current master) I'm having trouble reproducing this.
> Both with the eln cache empty both with it already warmed.
>
> Is this just local on my machine or the bug vanished? 🤔

I can still reproduce on 90c2e287b76.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Ihor Radchenko <yantar92@posteo.net> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> I cannot reproduce when changing the load path to Org git
>>>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>>>>> same with Emacs built-in version).
>>>>
>>>> So maybe the problem is already solved somehow?
>>>
>>> ... or it has something to do with loading built-in Org mode.
>>> when I do
>>> 1. emacs -Q
>>> 2. C-x C-f /tmp/a.org
>>> I do not see fontification.
>>
>> On 415604c7a77 (current master) I'm having trouble reproducing this.
>> Both with the eln cache empty both with it already warmed.
>>
>> Is this just local on my machine or the bug vanished? 🤔
>
> I'm still able to reproduce this on 415604c7a77.
>
>     $ emacs -Q a.org

Okay I can reproduce it using Emacs with GUI and not on terminal.

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> Ihor Radchenko <yantar92@posteo.net> writes:
>>>
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>>> I cannot reproduce when changing the load path to Org git
>>>>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>>>>>> same with Emacs built-in version).
>>>>>
>>>>> So maybe the problem is already solved somehow?
>>>>
>>>> ... or it has something to do with loading built-in Org mode.
>>>> when I do
>>>> 1. emacs -Q
>>>> 2. C-x C-f /tmp/a.org
>>>> I do not see fontification.
>>>
>>> On 415604c7a77 (current master) I'm having trouble reproducing this.
>>> Both with the eln cache empty both with it already warmed.
>>>
>>> Is this just local on my machine or the bug vanished? 🤔
>>
>> I'm still able to reproduce this on 415604c7a77.
>>
>>     $ emacs -Q a.org
>
> Okay I can reproduce it using Emacs with GUI and not on terminal.

Okay I've spent some time investigating, on my setup I can reproduce
this on GUI *only* when the eln-cache is empty with the suggested $ emacs -Q foo.org

I can't reproduce configuring with --with-native-compilation=aot

I can't reproduce with $ emacs -Q -eval "(setq native-comp-jit-compilation nil)" foo.org

These observations would suggest is native compilation related.

I can't see any SIGEGV in gdb in all of these tests.

Also as Ihor suggested (thanks!) reverting cf11fdfd8e46 makes issue not
reproducible here, but I still have to understand the reason (maybe some
circular dependency??).

Meanwhile Björn could you try reverting cf11fdfd8e46 and report if fixes
for you as well?

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

Ping!  Björn, could you please try what Andrea asked you?  I'd like to
make progress with this bug report.

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: 69431@debbugs.gnu.org,  Ihor Radchenko <yantar92@posteo.net>,  Eli
>  Zaretskii <eliz@gnu.org>
> Date: Thu, 07 Mar 2024 17:33:14 -0500
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> >
> >> Andrea Corallo <acorallo@gnu.org> writes:
> >>
> >>> Ihor Radchenko <yantar92@posteo.net> writes:
> >>>
> >>>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>>
> >>>>>> I cannot reproduce when changing the load path to Org git
> >>>>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
> >>>>>> same with Emacs built-in version).
> >>>>>
> >>>>> So maybe the problem is already solved somehow?
> >>>>
> >>>> ... or it has something to do with loading built-in Org mode.
> >>>> when I do
> >>>> 1. emacs -Q
> >>>> 2. C-x C-f /tmp/a.org
> >>>> I do not see fontification.
> >>>
> >>> On 415604c7a77 (current master) I'm having trouble reproducing this.
> >>> Both with the eln cache empty both with it already warmed.
> >>>
> >>> Is this just local on my machine or the bug vanished? 🤔
> >>
> >> I'm still able to reproduce this on 415604c7a77.
> >>
> >>     $ emacs -Q a.org
> >
> > Okay I can reproduce it using Emacs with GUI and not on terminal.
> 
> Okay I've spent some time investigating, on my setup I can reproduce
> this on GUI *only* when the eln-cache is empty with the suggested $ emacs -Q foo.org
> 
> I can't reproduce configuring with --with-native-compilation=aot
> 
> I can't reproduce with $ emacs -Q -eval "(setq native-comp-jit-compilation nil)" foo.org
> 
> These observations would suggest is native compilation related.
> 
> I can't see any SIGEGV in gdb in all of these tests.
> 
> Also as Ihor suggested (thanks!) reverting cf11fdfd8e46 makes issue not
> reproducible here, but I still have to understand the reason (maybe some
> circular dependency??).
> 
> Meanwhile Björn could you try reverting cf11fdfd8e46 and report if fixes
> for you as well?
> 
> Thanks
> 
>   Andrea
> 

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I replied to only Eli by accident.

No difference.
In fact (bootstrap) Emacs already crashes during build:
Breakpoint 1 at 0x424584: file /home/bidar/dev/emacs/emacs/src/emacs.c, line 441.
(gdb) bt
#0  memcpy
    (__len=8, __src=0x56d8, __dest=<synthetic pointer>,
__dest=<optimized out>, __src=<optimized out>, __len=<optimized out>)
at /usr/include/bits/string_fortified.h:29
#1 hash_string (ptr=<optimized out>, len=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5057
#2 0x00000000005b3582 in sxhash_obj.part.0.lto_priv.0 (obj=<optimized
out>, depth=depth@entry=3)
    at /home/bidar/dev/emacs/emacs/src/fns.c:5213
#3 0x00000000005b35d4 in sxhash_obj (depth=3, obj=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5201
#4 sxhash_vector (depth=<optimized out>, vec=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5151
#5 sxhash_obj.part.0.lto_priv.0 (obj=<optimized out>,
depth=depth@entry=2) at /home/bidar/dev/emacs/emacs/src/fns.c:5229
#6 0x00000000005b35d4 in sxhash_obj (depth=2, obj=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5201
#7 sxhash_vector (depth=<optimized out>, vec=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5151
#8 sxhash_obj.part.0.lto_priv.0 (obj=<optimized out>,
depth=depth@entry=1) at /home/bidar/dev/emacs/emacs/src/fns.c:5229
#9 0x00000000005b35d4 in sxhash_obj (depth=1, obj=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5201
#10 sxhash_vector (depth=<optimized out>, vec=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:5151
#11 sxhash_obj.part.0.lto_priv.0 (obj=<optimized out>,
depth=depth@entry=0) at /home/bidar/dev/emacs/emacs/src/fns.c:5229
#12 0x00000000005b396b in sxhash_obj (depth=0, obj=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:4478
#13 sxhash (obj=<optimized out>) at /home/bidar/dev/emacs/emacs/src/fns.c:5192
#14 hashfn_equal (key=<optimized out>, h=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/fns.c:4479
#15 0x00000000005b5263 in hash_from_key (key=XIL(0x14ebe5d),
h=0xd70ed0) at /home/bidar/dev/emacs/emacs/src/lisp.h:2720
#16 Fputhash (key=XIL(0x14ebe5d), value=XIL(0x14ebe5d),
table=XIL(0xd70ed5)) at /home/bidar/dev/emacs/emacs/src/fns.c:5639
#17 0x0000000000577d13 in purecopy (obj=XIL(0x14ebe5d)) at
/home/bidar/dev/emacs/emacs/src/alloc.c:6087
#18 0x0000000000578334 in Fpurecopy (obj=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/alloc.c:5993
#19 0x0000000000583648 in Fdefalias (symbol=XIL(0x8fb0e0),
definition=XIL(0xe5c8cd), docstring=XIL(0))
    at /home/bidar/dev/emacs/emacs/src/data.c:992
#20 0x00000000005a148f in eval_sub (form=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/eval.c:2531
#21 0x00000000005d3f55 in readevalloop
    (readcharfun=readcharfun@entry=XIL(0x8400),
infile0=infile0@entry=0x7fffffffc040,
sourcename=sourcename@entry=XIL(0x14d8274),
printflag=printflag@entry=false, unibyte=unibyte@entry=XIL(0),
readfun=readfun@entry=XIL(0), start=XIL(0), end=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/lread.c:2601
#22 0x00000000005d4bf3 in Fload
    (file=<optimized out>, noerror=<optimized out>,
nomessage=<optimized out>, nosuffix=<optimized out>,
must_suffix=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/lread.c:1792
#23 0x00000000005a1465 in eval_sub (form=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/eval.c:2539
#24 0x00000000005d3f55 in readevalloop
    (readcharfun=readcharfun@entry=XIL(0x8400),
infile0=infile0@entry=0x7fffffffc360,
sourcename=sourcename@entry=XIL(0xd09994),
printflag=printflag@entry=false, unibyte=unibyte@entry=XIL(0),
readfun=readfun@entry=XIL(0), start=XIL(0), end=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/lread.c:2601
#25 0x00000000005d4bf3 in Fload
    (file=<optimized out>, noerror=<optimized out>,
nomessage=<optimized out>, nosuffix=<optimized out>,
must_suffix=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/lread.c:1792
#26 0x00000000005a1465 in eval_sub (form=<optimized out>) at
/home/bidar/dev/emacs/emacs/src/eval.c:2539
#27 0x000000000050c236 in Feval (lexical=XIL(0x30), form=XIL(0x7ffff2d28423))
    at /home/bidar/dev/emacs/emacs/src/eval.c:2389
#28 top_level_2 () at /home/bidar/dev/emacs/emacs/src/keyboard.c:1183
#29 0x000000000059d787 in internal_condition_case
    (bfun=0x50c170 <top_level_2>, handlers=<optimized out>, hfun=0x50d580 <cmd_error>)
    at /home/bidar/dev/emacs/emacs/src/eval.c:1537
#30 0x000000000050c292 in top_level_1 (ignore=ignore@entry=XIL(0)) at
/home/bidar/dev/emacs/emacs/src/keyboard.c:1195
#31 0x000000000059d6e1 in internal_catch (tag=<optimized out>,
func=0x50c270 <top_level_1>, arg=XIL(0))
    at /home/bidar/dev/emacs/emacs/src/eval.c:1217
#32 0x000000000050dccb in command_loop () at /home/bidar/dev/emacs/emacs/src/keyboard.c:1144
#33 0x000000000068d796 in recursive_edit_1.isra.0 () at
/home/bidar/dev/emacs/emacs/src/keyboard.c:753
#34 0x000000000050fb2a in Frecursive_edit () at
/home/bidar/dev/emacs/emacs/src/keyboard.c:836
#35 0x000000000042ed1f in main (argc=<optimized out>, argv=<optimized out>)
    at /home/bidar/dev/emacs/emacs/src/emacs.c:2633
You can't do that without a process to debug.

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The bug in my last message only seem happen sometimes.
Now Emacs did not built without bootstrap as before
it failed with: error ("Invalid byte opcode: op=0, ptr=0")
imagemagick-register-types()
during the built.

After continuing to built with make bootstrap Emacs built fine but the same bug occured that
I originally mentioned happened again.
Crash in:
0x000000000059ea4e in funcall_subr (subr=0xbdc980 <Sinternal_get_lisp_face_attribute>, numargs=numargs@entry=3, 
    args=args@entry=0x7fffff6700e8) at /home/bidar/dev/emacs/emacs/src/eval.c:3094
#0  0x000000000059ea4e in funcall_subr
    (subr=0xbdc980 <Sinternal_get_lisp_face_attribute>, numargs=numargs@entry=3, args=args@entry=0x7fffff6700e8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3094
#1  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffff6700e8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#2  0x000000000059f56a in Ffuncall (nargs=4, args=0x7fffff6700e0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#3  0x00007ffff19ba9b2 in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#4  0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670268)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#5  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff670268)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#6  0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff670260) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#7  0x00007ffff19bacfc in F666163652d6174747269627574652d6d65726765642d77697468_face_attribute_merged_with_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#8  0x000000000059ea6c in funcall_subr (subr=0x7ffff227c6c8, numargs=numargs@entry=4, args=args@entry=0x7fffff6703f8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#9  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff6703f8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#10 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff6703f0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#11 0x00007ffff19bab9e in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#12 0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670568)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#13 0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff670568)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#14 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff670560) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#15 0x00007ffff19bacfc in F666163652d6174747269627574652d6d65726765642d77697468_face_attribute_merged_with_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#16 0x000000000059ea6c in funcall_subr (subr=0x7ffff227c6c8, numargs=numargs@entry=4, args=args@entry=0x7fffff6706f8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#17 0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff6706f8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#18 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff6706f0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#19 0x00007ffff19bab9e in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#20 0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670868)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The bug in my last message only seem happen sometimes.
Now Emacs did not built without bootstrap as before
it failed with: error ("Invalid byte opcode: op=0, ptr=0")
imagemagick-register-types()
during the built.

After continuing to built with make bootstrap Emacs built fine but the same bug occured that
I originally mentioned happened again.
Crash in:
0x000000000059ea4e in funcall_subr (subr=0xbdc980 <Sinternal_get_lisp_face_attribute>, numargs=numargs@entry=3, 
    args=args@entry=0x7fffff6700e8) at /home/bidar/dev/emacs/emacs/src/eval.c:3094
#0  0x000000000059ea4e in funcall_subr
    (subr=0xbdc980 <Sinternal_get_lisp_face_attribute>, numargs=numargs@entry=3, args=args@entry=0x7fffff6700e8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3094
#1  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffff6700e8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#2  0x000000000059f56a in Ffuncall (nargs=4, args=0x7fffff6700e0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#3  0x00007ffff19ba9b2 in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#4  0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670268)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#5  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff670268)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#6  0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff670260) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#7  0x00007ffff19bacfc in F666163652d6174747269627574652d6d65726765642d77697468_face_attribute_merged_with_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#8  0x000000000059ea6c in funcall_subr (subr=0x7ffff227c6c8, numargs=numargs@entry=4, args=args@entry=0x7fffff6703f8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#9  0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff6703f8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#10 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff6703f0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#11 0x00007ffff19bab9e in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#12 0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670568)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#13 0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff670568)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#14 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff670560) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#15 0x00007ffff19bacfc in F666163652d6174747269627574652d6d65726765642d77697468_face_attribute_merged_with_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#16 0x000000000059ea6c in funcall_subr (subr=0x7ffff227c6c8, numargs=numargs@entry=4, args=args@entry=0x7fffff6706f8)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096
#17 0x000000000059f380 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffff6706f8)
    at /home/bidar/dev/emacs/emacs/src/lisp.h:2217
#18 0x000000000059f56a in Ffuncall (nargs=5, args=0x7fffff6706f0) at /home/bidar/dev/emacs/emacs/src/eval.c:3022
#19 0x00007ffff19bab9e in F666163652d617474726962757465_face_attribute_0 ()
    at /home/bidar/dev/emacs/emacs/src/../native-lisp/30.0.50-4df357ea/preloaded/faces-b9447c93-32c2609b.eln
#20 0x000000000059ea6c in funcall_subr (subr=0x7ffff1d608a8, numargs=numargs@entry=4, args=args@entry=0x7fffff670868)
    at /home/bidar/dev/emacs/emacs/src/eval.c:3096

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  Björn, could you please try what Andrea asked you?  I'd like to
> make progress with this bug report.
>
>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: 69431@debbugs.gnu.org,  Ihor Radchenko <yantar92@posteo.net>,  Eli
>>  Zaretskii <eliz@gnu.org>
>> Date: Thu, 07 Mar 2024 17:33:14 -0500
>> 
>> Andrea Corallo <acorallo@gnu.org> writes:
>> 
>> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
>> >
>> >> Andrea Corallo <acorallo@gnu.org> writes:
>> >>
>> >>> Ihor Radchenko <yantar92@posteo.net> writes:
>> >>>
>> >>>> Eli Zaretskii <eliz@gnu.org> writes:
>> >>>>
>> >>>>>> I cannot reproduce when changing the load path to Org git
>> >>>>>> folder ( main, bugfix branches, and Org 9.6.15 tag which should be the
>> >>>>>> same with Emacs built-in version).
>> >>>>>
>> >>>>> So maybe the problem is already solved somehow?
>> >>>>
>> >>>> ... or it has something to do with loading built-in Org mode.
>> >>>> when I do
>> >>>> 1. emacs -Q
>> >>>> 2. C-x C-f /tmp/a.org
>> >>>> I do not see fontification.
>> >>>
>> >>> On 415604c7a77 (current master) I'm having trouble reproducing this.
>> >>> Both with the eln cache empty both with it already warmed.
>> >>>
>> >>> Is this just local on my machine or the bug vanished? 🤔
>> >>
>> >> I'm still able to reproduce this on 415604c7a77.
>> >>
>> >>     $ emacs -Q a.org
>> >
>> > Okay I can reproduce it using Emacs with GUI and not on terminal.
>> 
>> Okay I've spent some time investigating, on my setup I can reproduce
>> this on GUI *only* when the eln-cache is empty with the suggested $ emacs -Q foo.org
>> 
>> I can't reproduce configuring with --with-native-compilation=aot
>> 
>> I can't reproduce with $ emacs -Q -eval "(setq native-comp-jit-compilation nil)" foo.org
>> 
>> These observations would suggest is native compilation related.
>> 
>> I can't see any SIGEGV in gdb in all of these tests.
>> 
>> Also as Ihor suggested (thanks!) reverting cf11fdfd8e46 makes issue not
>> reproducible here, but I still have to understand the reason (maybe some
>> circular dependency??).
>> 
>> Meanwhile Björn could you try reverting cf11fdfd8e46 and report if fixes
>> for you as well?

I'm trying to progress on this but I've difficult time at getting a grip
on this bug.  One of the reason why is that on my reproducer Emacs
doesn't crash nor complain, the other reason is that I'm not really into
our fontification.  I'll keep on looking into it but I'd appretiate any
hint like: what should be happening to fontify the buffer that is not
actually happening here?  With such info I could try investingating the
issue from there comparing with the working case.

Thanks in advance!

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Björn Bidar <bjorn.bidar@thaodan.de>,
>   hirofumi@mail.parknet.co.jp,
>   69431@debbugs.gnu.org,  yantar92@posteo.net
> Date: Sun, 24 Mar 2024 05:12:17 -0400
> 
> >> Meanwhile Björn could you try reverting cf11fdfd8e46 and report if fixes
> >> for you as well?
> 
> I'm trying to progress on this but I've difficult time at getting a grip
> on this bug.  One of the reason why is that on my reproducer Emacs
> doesn't crash nor complain, the other reason is that I'm not really into
> our fontification.  I'll keep on looking into it but I'd appretiate any
> hint like: what should be happening to fontify the buffer that is not
> actually happening here?  With such info I could try investingating the
> issue from there comparing with the working case.

Maybe Stefan (CC'ed) could help in that matter?

bug#69431: 30.0.50; Strange fontificaion behavior

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I'm trying to progress on this but I've difficult time at getting a grip
> on this bug.  One of the reason why is that on my reproducer Emacs
> doesn't crash nor complain, the other reason is that I'm not really into
> our fontification.  I'll keep on looking into it but I'd appretiate any
> hint like: what should be happening to fontify the buffer that is not
> actually happening here?  With such info I could try investingating the
> issue from there comparing with the working case.

Hmm... here, after

    rm -rf ~/.emacs.d/eln-cache
    src/emacs -Q --eval '(setq debug-on-error t)' a.org

I get a buffer with no fontification, that claims to be in Org mode but
whose `font-lock-keywords` is just (t nil), which explains the lack
of fontification.

And if I wait long enough for all the org files to be native-compiled,

    src/emacs -Q --eval '(setq debug-on-error t)' a.org

opens up a buffer with the usual fontification.


        Stefan "puzzled"

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm trying to progress on this but I've difficult time at getting a grip
>> on this bug.  One of the reason why is that on my reproducer Emacs
>> doesn't crash nor complain, the other reason is that I'm not really into
>> our fontification.  I'll keep on looking into it but I'd appretiate any
>> hint like: what should be happening to fontify the buffer that is not
>> actually happening here?  With such info I could try investingating the
>> issue from there comparing with the working case.
>
> Hmm... here, after
>
>     rm -rf ~/.emacs.d/eln-cache
>     src/emacs -Q --eval '(setq debug-on-error t)' a.org
>
> I get a buffer with no fontification, that claims to be in Org mode but
> whose `font-lock-keywords` is just (t nil), which explains the lack
> of fontification.

Where `font-lock-keywords` are supposed to be set?

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> I'm trying to progress on this but I've difficult time at getting a grip
>>> on this bug.  One of the reason why is that on my reproducer Emacs
>>> doesn't crash nor complain, the other reason is that I'm not really into
>>> our fontification.  I'll keep on looking into it but I'd appretiate any
>>> hint like: what should be happening to fontify the buffer that is not
>>> actually happening here?  With such info I could try investingating the
>>> issue from there comparing with the working case.
>>
>> Hmm... here, after
>>
>>     rm -rf ~/.emacs.d/eln-cache
>>     src/emacs -Q --eval '(setq debug-on-error t)' a.org
>>
>> I get a buffer with no fontification, that claims to be in Org mode but
>> whose `font-lock-keywords` is just (t nil), which explains the lack
>> of fontification.
>
> Where `font-lock-keywords` are supposed to be set?

`font-lock-keywords` is normally set from `font-lock-defaults` (which is
set by the major-mode) by `font-lock-set-defaults` when `font-lock-mode`
is enabled (which usually happens soon after enabling the major mode,
via `after-change-major-mode-hook`).


        Stefan

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I'm trying to progress on this but I've difficult time at getting a grip
>>>> on this bug.  One of the reason why is that on my reproducer Emacs
>>>> doesn't crash nor complain, the other reason is that I'm not really into
>>>> our fontification.  I'll keep on looking into it but I'd appretiate any
>>>> hint like: what should be happening to fontify the buffer that is not
>>>> actually happening here?  With such info I could try investingating the
>>>> issue from there comparing with the working case.
>>>
>>> Hmm... here, after
>>>
>>>     rm -rf ~/.emacs.d/eln-cache
>>>     src/emacs -Q --eval '(setq debug-on-error t)' a.org
>>>
>>> I get a buffer with no fontification, that claims to be in Org mode but
>>> whose `font-lock-keywords` is just (t nil), which explains the lack
>>> of fontification.
>>
>> Where `font-lock-keywords` are supposed to be set?
>
> `font-lock-keywords` is normally set from `font-lock-defaults` (which is
> set by the major-mode) by `font-lock-set-defaults` when `font-lock-mode`
> is enabled (which usually happens soon after enabling the major mode,
> via `after-change-major-mode-hook`).

Sorry didn't had much time to progress on this.

I see `font-lock-mode` and `font-lock-set-defaults` are called when
opening an org file here on my reproducer.

Also I see `font-lock-set-defaults` is actually set! So I'm wondering
why afterwards the value changes for my test.org.

Will look into it more hopefully tomorrow.

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>>> I'm trying to progress on this but I've difficult time at getting a grip
>>>>> on this bug.  One of the reason why is that on my reproducer Emacs
>>>>> doesn't crash nor complain, the other reason is that I'm not really into
>>>>> our fontification.  I'll keep on looking into it but I'd appretiate any
>>>>> hint like: what should be happening to fontify the buffer that is not
>>>>> actually happening here?  With such info I could try investingating the
>>>>> issue from there comparing with the working case.
>>>>
>>>> Hmm... here, after
>>>>
>>>>     rm -rf ~/.emacs.d/eln-cache
>>>>     src/emacs -Q --eval '(setq debug-on-error t)' a.org
>>>>
>>>> I get a buffer with no fontification, that claims to be in Org mode but
>>>> whose `font-lock-keywords` is just (t nil), which explains the lack
>>>> of fontification.
>>>
>>> Where `font-lock-keywords` are supposed to be set?
>>
>> `font-lock-keywords` is normally set from `font-lock-defaults` (which is
>> set by the major-mode) by `font-lock-set-defaults` when `font-lock-mode`
>> is enabled (which usually happens soon after enabling the major mode,
>> via `after-change-major-mode-hook`).
>
> Sorry didn't had much time to progress on this.
>
> I see `font-lock-mode` and `font-lock-set-defaults` are called when
> opening an org file here on my reproducer.
>
> Also I see `font-lock-set-defaults` is actually set! So I'm wondering
> why afterwards the value changes for my test.org.
>
> Will look into it more hopefully tomorrow.

Driven by curiosity I went a little further today...

I've applied the following:

================

1 file changed, 6 insertions(+)
lisp/font-lock.el | 6 ++++++

modified   lisp/font-lock.el
@@ -1874,6 +1874,10 @@ font-lock-refresh-defaults
 (defvar-local font-lock-major-mode nil
   "Major mode for which the font-lock settings have been setup.")

+(defun k-variable-watcher (_symbol newval op _buffer)
+  (message "XXX %s" op)
+  (backtrace))
+
 (defun font-lock-set-defaults ()
   "Set fontification defaults appropriately for this mode.
 Sets various variables using `font-lock-defaults' and
@@ -1934,6 +1938,8 @@ font-lock-set-defaults
       (unless (eq (car font-lock-keywords) t)
         (setq font-lock-keywords
               (font-lock-compile-keywords font-lock-keywords))))
+    (when (string= (buffer-name) "test.org")
+      (add-variable-watcher 'font-lock-keywords #'k-variable-watcher))
     (font-lock-flush)))
 ^L
 ;;; Color etc. support.

================

And this is what it logs on *Messages* depending on the fact that the
eln-cache is wiped or not:

Warm eln-cache (working fontification)
================
For information about GNU Emacs and the GNU system, type C-h C-a.
XXX set
  backtrace()
  k-variable-watcher(font-lock-keywords ((org-font-lock-hook) ("^\\(\\**\\)\\(\\* \\)\\(.*\\)" (1 (org-get-level-face 1)) (2 (org-get-level-face 2)) (3 (org-get-level-face 3))) ("^[ \11]*\\(\\(|\\|\\+-[-+]\\).*\\S-\\)" (1 'org-table t)) ("^[ \11]*|\\(?:.*?|\\)? *\\(:?=[^|\n]*\\)" (1 'org-formula t)) ("^[ \11]*| *\\([#*]\\) *|" (1 'org-formula t)) ("^[ \11]*|\\( *\\([$!_^/]\\) *|.*\\)|" (1 'org-formula t)) ("| *\\(<[lrc]?[0-9]*>\\)" (1 'org-formula t)) ("^\\(?4:[ \11]*\\)\\(?1::\\(?2:\\S-+\\):\\)\\(?:\\(?3:$\\)\\|[ \11]+\\(?3:.*?\\)\\)\\(?5:[ \11]*\\)$" (1 'org-special-keyword t) (3 'org-property-value t)) (org-fontify-drawers) (org-activate-links) (org-activate-tags (1 'org-tag prepend)) (org-activate-target-links (1 'org-link t)) (org-activate-dates (0 'org-date t)) (org-activate-footnote
 -links)\
 ("<<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>>" (0 'org-target t)) ("<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>" (0 'org-target t)) ("^&?%%(.*\\|<%%([^>\n]*?>" (0 'org-sexp-date t)) (org-fontify-macros) ("^\\(\\*+\\)\\(?: +\\(DONE\\|TODO\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 (org-get-todo-face 2) prepend)) ("^\\(\\*+\\)\\(?: +\\(?:DONE\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 'org-headline-done prepend)) (org-font-lock-add-priority-faces) (org-font-lock-add-tag-faces) ("\\<DEADLINE:" (0 'org-special-keyword t)) ("\\<SCHEDULED:" (0 'org-special-keyword t)) ("\\<CLOSED:" (0 'org-special-keyword t)) ("\\<CLOCK:" (0 'org-special-keyword t)) (org-do-emphasis-faces) ("^[ \11]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ \11]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \11]*\\
 )?\\(\\\
[[- X]\\]\\)" 1 'org-checkbox prepend) ("\\[\\([0-9]*%\\)\\]\\|\\[\\([0-9]*\\)/\\([0-9]*\\)\\]" (0 (org-get-checkbox-statistics-face) prepend)) ("\\(?:^[ \11]*[-+]\\|^[ \11]+[*]\\)[ \11]+\\(.*?[ \11]+::\\)\\([ \11]+\\|$\\)" 1 'org-list-dt prepend) ("\\(@@\\)\\([a-z-]+:\\).*?\\(@@\\)" (1 'font-lock-comment-face t) (2 'org-tag t) (3 'font-lock-comment-face t)) ("^\\*+ \\(.*:ARCHIVE:.*\\)" (1 'org-archived prepend)) (org-do-latex-and-related) (org-fontify-entities) (org-raise-scripts) (org-activate-code (1 'org-code t)) ("^\\*+\\(?: +\\(DONE\\|TODO\\)\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:COMMENT\\)\\(?: \\|$\\)" (9 'org-special-keyword t)) (org-fontify-meta-lines-and-blocks) (org-fontify-inline-src-blocks) (org-cite-activate)) set #<buffer test.org>)
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" (14180533 64513))
  find-file-noselect("/home/andcor03/test.org")
  command-line-1(("-eval" "(setq native-comp-jit-compilation t)" "/home/andcor03/test.org"))
  command-line()
  normal-top-level()

XXX set
  backtrace()
  k-variable-watcher(font-lock-keywords (t ((org-font-lock-hook) ("^\\(\\**\\)\\(\\* \\)\\(.*\\)" (1 (org-get-level-face 1)) (2 (org-get-level-face 2)) (3 (org-get-level-face 3))) ("^[ \11]*\\(\\(|\\|\\+-[-+]\\).*\\S-\\)" (1 'org-table t)) ("^[ \11]*|\\(?:.*?|\\)? *\\(:?=[^|\n]*\\)" (1 'org-formula t)) ("^[ \11]*| *\\([#*]\\) *|" (1 'org-formula t)) ("^[ \11]*|\\( *\\([$!_^/]\\) *|.*\\)|" (1 'org-formula t)) ("| *\\(<[lrc]?[0-9]*>\\)" (1 'org-formula t)) ("^\\(?4:[ \11]*\\)\\(?1::\\(?2:\\S-+\\):\\)\\(?:\\(?3:$\\)\\|[ \11]+\\(?3:.*?\\)\\)\\(?5:[ \11]*\\)$" (1 'org-special-keyword t) (3 'org-property-value t)) (org-fontify-drawers) (org-activate-links) (org-activate-tags (1 'org-tag prepend)) (org-activate-target-links (1 'org-link t)) (org-activate-dates (0 'org-date t)) (org-activate-footn
 ote-lin\
ks) ("<<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>>" (0 'org-target t)) ("<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>" (0 'org-target t)) ("^&?%%(.*\\|<%%([^>\n]*?>" (0 'org-sexp-date t)) (org-fontify-macros) ("^\\(\\*+\\)\\(?: +\\(DONE\\|TODO\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 (org-get-todo-face 2) prepend)) ("^\\(\\*+\\)\\(?: +\\(?:DONE\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 'org-headline-done prepend)) (org-font-lock-add-priority-faces) (org-font-lock-add-tag-faces) ("\\<DEADLINE:" (0 'org-special-keyword t)) ("\\<SCHEDULED:" (0 'org-special-keyword t)) ("\\<CLOSED:" (0 'org-special-keyword t)) ("\\<CLOCK:" (0 'org-special-keyword t)) (org-do-emphasis-faces) ("^[ \11]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ \11]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \11]
 *\\)?\\\
(\\[[- X]\\]\\)" 1 'org-checkbox prepend) ("\\[\\([0-9]*%\\)\\]\\|\\[\\([0-9]*\\)/\\([0-9]*\\)\\]" (0 (org-get-checkbox-statistics-face) prepend)) ("\\(?:^[ \11]*[-+]\\|^[ \11]+[*]\\)[ \11]+\\(.*?[ \11]+::\\)\\([ \11]+\\|$\\)" 1 'org-list-dt prepend) ("\\(@@\\)\\([a-z-]+:\\).*?\\(@@\\)" (1 'font-lock-comment-face t) (2 'org-tag t) (3 'font-lock-comment-face t)) ("^\\*+ \\(.*:ARCHIVE:.*\\)" (1 'org-archived prepend)) (org-do-latex-and-related) (org-fontify-entities) (org-raise-scripts) (org-activate-code (1 'org-code t)) ("^\\*+\\(?: +\\(DONE\\|TODO\\)\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:COMMENT\\)\\(?: \\|$\\)" (9 'org-special-keyword t)) (org-fontify-meta-lines-and-blocks) (org-fontify-inline-src-blocks) (org-cite-activate)) (org-font-lock-hook (0 nil)) ("^\\(\\**\\)\\(\\* \\)\\(.*\\)" (
 1 (org-\
get-level-face 1)) (2 (org-get-level-face 2)) (3 (org-get-level-face 3))) ("^[ \11]*\\(\\(|\\|\\+-[-+]\\).*\\S-\\)" (1 'org-table t)) ("^[ \11]*|\\(?:.*?|\\)? *\\(:?=[^|\n]*\\)" (1 'org-formula t)) ("^[ \11]*| *\\([#*]\\) *|" (1 'org-formula t)) ("^[ \11]*|\\( *\\([$!_^/]\\) *|.*\\)|" (1 'org-formula t)) ("| *\\(<[lrc]?[0-9]*>\\)" (1 'org-formula t)) ("^\\(?4:[ \11]*\\)\\(?1::\\(?2:\\S-+\\):\\)\\(?:\\(?3:$\\)\\|[ \11]+\\(?3:.*?\\)\\)\\(?5:[ \11]*\\)$" (1 'org-special-keyword t) (3 'org-property-value t)) (org-fontify-drawers (0 nil)) (org-activate-links (0 nil)) (org-activate-tags (1 'org-tag prepend)) (org-activate-target-links (1 'org-link t)) (org-activate-dates (0 'org-date t)) (org-activate-footnote-links (0 nil)) ("<<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>>"
  (0 'or\
g-target t)) ("<<\\([^<>\n\15 \11]\\|[^<>\n\15 \11][^<>\n\15]*[^<>\n\15 \11]\\)>>" (0 'org-target t)) ("^&?%%(.*\\|<%%([^>\n]*?>" (0 'org-sexp-date t)) (org-fontify-macros (0 nil)) ("^\\(\\*+\\)\\(?: +\\(DONE\\|TODO\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 (org-get-todo-face 2) prepend)) ("^\\(\\*+\\)\\(?: +\\(?:DONE\\)\\)\\(?: +\\(.*?\\)\\)?[ \11]*$" (2 'org-headline-done prepend)) (org-font-lock-add-priority-faces (0 nil)) (org-font-lock-add-tag-faces (0 nil)) ("\\<DEADLINE:" (0 'org-special-keyword t)) ("\\<SCHEDULED:" (0 'org-special-keyword t)) ("\\<CLOSED:" (0 'org-special-keyword t)) ("\\<CLOCK:" (0 'org-special-keyword t)) (org-do-emphasis-faces (0 nil)) ("^[ \11]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ \11]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \11]*\\)?\\(\\[[- X]\\]\\)" (1 'org-checkbox prepend))
  ("\\[\\
\([0-9]*%\\)\\]\\|\\[\\([0-9]*\\)/\\([0-9]*\\)\\]" (0 (org-get-checkbox-statistics-face) prepend)) ("\\(?:^[ \11]*[-+]\\|^[ \11]+[*]\\)[ \11]+\\(.*?[ \11]+::\\)\\([ \11]+\\|$\\)" (1 'org-list-dt prepend)) ("\\(@@\\)\\([a-z-]+:\\).*?\\(@@\\)" (1 'font-lock-comment-face t) (2 'org-tag t) (3 'font-lock-comment-face t)) ("^\\*+ \\(.*:ARCHIVE:.*\\)" (1 'org-archived prepend)) (org-do-latex-and-related (0 nil)) (org-fontify-entities (0 nil)) (org-raise-scripts (0 nil)) (org-activate-code (1 'org-code t)) ("^\\*+\\(?: +\\(DONE\\|TODO\\)\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:COMMENT\\)\\(?: \\|$\\)" (9 'org-special-keyword t)) (org-fontify-meta-lines-and-blocks (0 nil)) (org-fontify-inline-src-blocks (0 nil)) (org-cite-activate (0 nil))) set #<buffer test.org>)
  font-lock-fontify-keywords-region(1 7 nil)
  font-lock-default-fontify-region(1 7 nil)
  font-lock-fontify-region(1 7)
  #f(compiled-function (fun) #<bytecode 0x1baf782d70c71cbf>)(font-lock-fontify-region)
  jit-lock--run-functions(1 7)
  jit-lock-fontify-now(1 7)
  jit-lock-function(1)
  redisplay_internal\ \(C\ function\)()
================


Empty eln-cache (fontification broken):
================
For information about GNU Emacs and the GNU system, type C-h C-a.
XXX makunbound
  backtrace()
  k-variable-watcher(font-lock-keywords nil makunbound #<buffer test.org>)
  kill-local-variable(font-lock-keywords)
  org-set-font-lock-defaults()
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode--apply-alist((("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" . elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr) ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode) ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'" . ruby-mode) ("\\.re?st\\'" . rst-mode) ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" . python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" . less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode) ("\\.aw
 k\\'" .\
 awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'" . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ("\\.m\\'" . objc-mode) ("\\.ii\\'" . c++-mode) ("\\.i\\'" . c-mode) ("\\.lex\\'" . c-mode) ("\\.y\\(acc\\)?\\'" . c-mode) ("\\.h\\'" . c-or-c++-mode) ("\\.c\\'" . c-mode) ("\\.\\(CC?\\|HH?\\)\\'" . c++-mode) ("\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\'" . c++-mode) ("\\.\\(cc\\|hh\\)\\'" . c++-mode) ("\\.\\(bat\\|cmd\\)\\'" . bat-mode) ("\\.[sx]?html?\\(\\.[a-zA-Z_]+\\)?\\'" . mhtml-mode) ("\\.svgz?\\'" . image-mode) ("\\.svgz?\\'" . xml-mode) ("\\.x[bp]m\\'" . image-mode) ("\\.x[bp]m\\'" . c-mode) ("\\.p[bpgn]m\\'" . image-mode) ("\\.tiff?\\'" . image-mode) ("\\.gif\\'" . image-mode) ("\\.png\\'" . image-mode) ("\\.jpe?g\\'" . image-mode) ("\\.webp\\'" . image-mode) ("\\.te?xt
 \\'" . \
text-mode) ("\\.[tT]e[xX]\\'" . tex-mode) ("\\.ins\\'" . tex-mode) ("\\.ltx\\'" . latex-mode) ("\\.dtx\\'" . doctex-mode) ...) nil nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" (14180533 64513))
  find-file-noselect("/home/andcor03/test.org")
  command-line-1(("-eval" "(setq native-comp-jit-compilation t)" "/home/andcor03/test.org"))
  command-line()
  normal-top-level()

XXX set
  backtrace()
  k-variable-watcher(font-lock-keywords (t nil) set nil)
  font-lock-fontify-keywords-region(1 7 nil)
  font-lock-default-fontify-region(1 7 nil)
  font-lock-fontify-region(1 7)
  #f(compiled-function (fun) #<bytecode 0x1baf3a4708041cbf>)(font-lock-fontify-region)
  jit-lock--run-functions(1 7)
  jit-lock-fontify-now(1 7)
  jit-lock-function(1)
  redisplay_internal\ \(C\ function\)()

================

So from what I see in the non working example 'font-lock-keywords' is
cleared at the end of 'org-set-font-lock-defaults' which does
'(kill-local-variable 'font-lock-keywords)'.

Now why this is not happening in the working example I'm not sure ATM,
('org-set-font-lock-defaults' is not even called there AFAICS).

Maybe org maintainers can comment if this is expected or not, or explain
meanwhile the mechanism so debug will be easier.

Thanks!

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

> I've applied the following:
>
>  (defun font-lock-set-defaults ()
> ...
> +    (when (string= (buffer-name) "test.org")
> +      (add-variable-watcher 'font-lock-keywords #'k-variable-watcher))
>
> Warm eln-cache (working fontification)
> ================
> For information about GNU Emacs and the GNU system, type C-h C-a.
> XXX set
>   backtrace()
>   k-variable-watcher(font-lock-keywords ... set #<buffer test.org>)
>   normal-mode(t)
>
> XXX set
>   backtrace()
>   k-variable-watcher(font-lock-keywords ... set #<buffer test.org>)
> ...
>   jit-lock-function(1)
>
> Empty eln-cache (fontification broken):
> ================
> For information about GNU Emacs and the GNU system, type C-h C-a.
> XXX makunbound
>   backtrace()
>   k-variable-watcher(font-lock-keywords nil makunbound #<buffer test.org>)
>   kill-local-variable(font-lock-keywords)
>   org-set-font-lock-defaults()
>   org-mode()
> ...
> XXX set
>   backtrace()
>   k-variable-watcher(font-lock-keywords (t nil) set nil)
> ...
>   jit-lock-function(1)
>
> ================
>
> So from what I see in the non working example 'font-lock-keywords' is
> cleared at the end of 'org-set-font-lock-defaults' which does
> '(kill-local-variable 'font-lock-keywords)'.
>
> Now why this is not happening in the working example I'm not sure ATM,
> ('org-set-font-lock-defaults' is not even called there AFAICS).

I am pretty sure that it does get called, but before your variable
watcher becomes active.

I suspect that font-lock is dumped to Emacs.
Maybe related to bug#66741.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I want to add the bug happens for me to where I don't load an org-mode
file but have org-mode as a mode for the scratch buffer plus
modus-theme-vivendi as theme.

I tried to trigger the bug with just emacs -Q plus modus-theme-vivendi
but that wasn't enough.
I assume the bug isn't triggered before a certain amount of memory has
been used.

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Okay after "some" debugging my theory is that it is problematic to setup
the fontification while the setup of another fontification is active on
the stack.

This is what is happening here because while we are setting up
fontification for 'test.org' native compilation activated
'emacs-lisp-compilation-mode' on the '*Async-native-compile-log*'
buffer.

If I remove the invocations of 'emacs-lisp-compilation-mode' from
'comp-run-async-workers' my org file gets fontified correctly.

Applying:

==============
modified   lisp/files.el
@@ -2828,6 +2828,13 @@ after-find-file

 (define-obsolete-function-alias 'report-errors 'with-demoted-errors "25.1")

+(defun k-variable-watcher (_symbol newval op _buffer)
+  (when (string= (buffer-name) "test.org")
+    (message "XXX %s" op)
+    (backtrace)))
+
+(add-variable-watcher 'font-lock-keywords #'k-variable-watcher)
+
 (defun normal-mode (&optional find-file)
   "Choose the major mode for this buffer automatically.
 Also sets up any specified local variables of the file or its directory.
==============

The backtrace I see in *Messages* looks like this in the non working
case (cold eln-cache):

==============
XXX set
  backtrace()
  k-variable-watcher(font-lock-keywords ((eval list (or outline-search-function (concat "^\\(?:" outline-regexp "\\).*" outline-heading-end-regexp)) 0 '(if outline-minor-mode (if outline-minor-mode-highlight (list 'face (outline-font-lock-face))) (outline-font-lock-face)) (when outline-minor-mode (pcase outline-minor-mode-highlight ('override t) ('append 'append))) t)) set #<buffer test.org>)
  font-lock-set-defaults()
  font-lock-mode-internal(t)
  font-lock-default-function(t)
  font-lock-mode()
  turn-on-font-lock()
  turn-on-font-lock-if-desired()
  global-font-lock-mode-enable-in-buffers()
  run-hooks(after-change-major-mode-hook)
  run-mode-hooks(emacs-lisp-compilation-mode-hook)
  emacs-lisp-compilation-mode()
  comp-run-async-workers()
  native--compile-async("/home/andcor03/emacs2/lisp/net/dbus.el" nil late)
  apply(native--compile-async ("/home/andcor03/emacs2/lisp/net/dbus.el" nil late))
  read-event(nil nil 0.001)
  dbus-call-method(:system "org.freedesktop.DBus" "/org/freedesktop/DBus" "org.freedesktop.DBus" "AddMatch" "type='signal',interface='org.freedesktop.DBus.Local',member='Disconnected',path='/org/freedesktop/DBus/Local'")
  dbus-register-signal(:system nil "/org/freedesktop/DBus/Local" "org.freedesktop.DBus.Local" "Disconnected" dbus-handle-bus-disconnect)
  dbus-init-bus(:system)
  dbus--init()
  byte-code("\300\301\302\"\210\302 \210\303\304!\207" [add-hook after-pdump-load-hook dbus--init provide dbus] 3)
  require(dbus)
  byte-code("\300\301!\210\300\302!\210\303\304\305\306\307DD\310\311\312\313\314&\7\207" [require gnus dbus custom-declare-variable gnus-dbus-close-on-sleep funcall function #f(compiled-function () #<bytecode -0x1df07492cba9682>) ("/home/andcor03/emacs2/lisp/gnus/gnus-dbus.elc" . 86) :group gnus-dbus :type boolean] 8)
  require(gnus-dbus)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\311\312\313\"\210\311\314\315\"\210\311\316\315\"\210\311\317\315\"\210\320\321\322\323\324DD\325\326\327\330\331&\7\210\320\332\322\323\333DD\334\335\336\326\327\330\337&\11\210\320\340\322\323\341DD\342\335\336\326\327\330\343&\11\210\320\344\322\323\345DD\346\326\327\330\331&\7\210\320\347\322\323\350DD\351\326\327\330\352&\7\210\320\353\322\323\354DD\355\326\356\330\357&\7\210\320\360\322\323\361DD\362\326\356\330\363&\7\210\320\364\322\323\365DD\366\326\327\330\367&\7\210\320\370\322\323\371DD\372\326\373\330\357&\7\210\320\374\322\323\375DD\376\326\373\330\377&\7\207" [require gnus gnus-win gnus-int gnus-spec gnus-range gnus-util gnus-cloud gnus-dbus autoload message-make-date "message" gnus-agent-read-servers-validate "gnus-agent" gnus-agent-save-local gnus-agent-possibly-alter-active custom-declare-variable gnus-startup-file funcall function #f(compiled-function () #<bytecode -0x16373a68b89bcc3e>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 86) :group gnus-start :type file gnus-backup-startup-file #f(compiled-function () #<bytecode 0xd353236499f29a>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 172) :version "22.1" (choice (const :tag "Never" never) (const :tag "If existing" nil) (other :tag "Always" t)) gnus-save-startup-file-via-temp-buffer #f(compiled-function () #<bytecode 0xb738b6fba16d1a>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 316) (choice (const :tag "Write via buffer" t) (const :tag "Write directly to file" nil)) gnus-init-file #f(compiled-function () #<bytecode 0xb3022756901fc2>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 549) gnus-site-init-file #f(compiled-function () #<bytecode 0x1e4de8aa016bec56>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 672) (choice file (const nil)) gnus-use-dribble-file #f(compiled-function () #<bytecode 0xb738b6fba16d1a>) ("/home/andcor03/emacs2/lisp/gnus/gnus-start.elc" . 820) gnus-dribble-file boolean gnus-dribble-directory #f(compiled-function () #<bytecode 0xb738b6fba17c1a>) ...] 10)
  require(gnus-start)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\315\316\317\"\210\315\320\321\"\210\315\322\323\"\210\315\324\323\"\210\315\325\326\"\210\327\330\331\332\333DD\334\335\303\336\337&\7\210\327\340\331\332\341DD\342\335\343\336\344&\7\210\327\345\331\332\346DD\347\350\351\335\352\336\353&\11\210\327\354\331\332\355DD\356\350\357\335\352\336\353&\11\210\327\360\331\332\361DD\362\335\363\336\364&\7\210\327\365\331\332\366DD\367\370\371\335\352\336\372&\11\210\327\373\331\332\374DD\375\335\363\336\353&\7\210\327\376\331\332\377DD\201@\0\335\363\336\201A\0&\7\210\327\201B\0\331\332\201C\0DD\201D\0\335\363\335\343\336\353&\11\210\327\201E\0\331\332\201F\0DD\201G\0\335\363\350\201H\0\336\201I\0&\11\210\327\201J\0\331\332\201K\0DD\201L\0\350\201M\0\335\201N\0\336\337&\11\210\327\201O\0\331\332\201P\0DD\201Q\0\335\201N\0\336\337&\7\210\327\201R\0\331\332\201S\0DD\201T\0\335\352\336\201U\0&\7\210\327\201V\0\331\332\201W\0DD\201X\0\335\352\350\201Y\0\336\201U\0&\11\210\327\201Z\0\331\332\201[\0DD\201\\\0\335\201N\0\336\201U\0&\7\210\327\201]\0\331\332\201^\0DD\201_\0\335\363\336\332&\7\207" [require cl-lib gnus gnus-start nnmail gnus-spec gnus-int gnus-range gnus-win gnus-undo gmm-utils time-date range autoload gnus-agent-total-fetched-for "gnus-agent" gnus-cache-total-fetched-for "gnus-cache" gnus-cloud-upload-all-data "gnus-cloud" gnus-cloud-download-all-data gnus-topic-find-groups "gnus-topic" custom-declare-variable gnus-no-groups-message funcall function #f(compiled-function () #<bytecode -0x156b006a3fe4da40>) ("/home/andcor03/emacs2/lisp/gnus/gnus-group.elc" . 86) :group :type string gnus-keep-same-level #f(compiled-function () #<bytecode 0x22638b6ab444452>) ("/home/andcor03/emacs2/lisp/gnus/gnus-group.elc" . 153) gnus-group-levels (choice (const nil) (const best) (sexp :tag "other" t)) gnus-group-goto-unread #f(compiled-function () #<bytecode 0x22638b6ab445552>) ("/home/andcor03/emacs2/lisp/gnus/gnus-group.elc" . 752) :link (custom-manual "(gnus)Group Maneuvering") gnus-group-various boolean gnus-goto-next-group-when-activating #f(compiled-function () #<bytecode 0x22638b6ab445552>) ("/home/andcor03/emacs2/lisp/gnus/gnus-group.elc" . 837) (custom-manual "(gnus)Scanning New Messages") gnus-permanently-visible-groups #f(compiled-function () #<bytecode 0x22638b6ab444452>) ...] 10)
  require(gnus-group)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315!\210\316\317\320\321\322$\210\316\323\320\"\210\316\324\325\321\326$\210\316\327\330\321\211$\210\316\331\330\321\211$\210\316\332\330\321\211$\210\316\333\334\321\211$\210\316\335\334\321\211$\210\336\337\340\341\342DD\343\344\345\346\347&\7\210\336\350\340\341\351DD\352\353\354\344\345\355\356\346\347&\13\210\336\357\340\341\360DD\361\353\362\344\363\355\364\346\347&\13\210\336\365\340\341\366DD\367\344\370\346\371&\7\210\336\372\340\341\373DD\374\344\370\346\375&\7\210\376\377\201@\0\321#\210\201A\0\211\203\355\0\211@\377\1N\203\350\0\201@\0\1N\204\350\0\201B\0\201@\0\2\377\4N#\210\210A\202\310\0\210\201C\0\377\201@\0\201D\0#\210\336\201@\0\340\341\201E\0DD\201F\0\355\201D\0\344\370\346\201G\0&\11\210\336\201H\0\340\341\201I\0DD\201J\0\355\201K\0\344\370\346\347&\11\210\336\201L\0\340\341\201M\0DD\201N\0\344\370\346\201O\0&\7\210\336\201P\0\340\341\201Q\0DD\201R\0\355\201S\0\344\370\346\347&\11\210\336\201T\0\340\341\201U\0DD\201V\0\344\370\346\201W\0&\7\207" [require cl-lib gnus gnus-group gnus-spec gnus-range gnus-int gnus-undo gnus-util gmm-utils mm-decode shr url nnoo autoload gnus-summary-limit-include-cached "gnus-cache" nil (gnus-summary-mode) gnus-cache-write-active gnus-pick-line-number "gnus-salt" t nnselect-article-rsv "nnselect" nnselect-article-group gnus-nnselect-group-p gnus-search-thread "gnus-search" gnus-search-server-to-engine custom-declare-variable gnus-kill-summary-on-exit funcall function #f(compiled-function () #<bytecode 0x1f738b5a7440a24>) ("/home/andcor03/emacs2/lisp/gnus/gnus-sum.elc" . 87) :group gnus-summary-exit :type boolean gnus-summary-next-group-on-exit #f(compiled-function () #<bytecode 0x1f738b5a7440a24>) ("/home/andcor03/emacs2/lisp/gnus/gnus-sum.elc" . 253) :link (custom-manual "(gnus)Group Maneuvering") :version "23.1" gnus-summary-stop-at-end-of-message #f(compiled-function () #<bytecode 0x1f738b5a7441124>) ("/home/andcor03/emacs2/lisp/gnus/gnus-sum.elc" . 349) ...] 12)
  require(gnus-sum)
  byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305\306\307#\204\36\0\300\310\306\307#\210\300\311!\210\312\313\314\315\316DD\317\320\321\322\323&\7\210\312\324\314\315\325DD\326\320\327\330\331\332\333\322\323&\13\210\334\335\336\337\340\341%\207" [require org-macs gnus-sum gnus-util nnheader nnselect nil t nnir ol custom-declare-variable org-gnus-prefer-web-links funcall function #f(compiled-function () #<bytecode -0x14706cb1bbcafd06>) ("/home/andcor03/emacs2/lisp/org/ol-gnus.elc" . 87) :group org-link-store :type boolean org-gnus-no-server #f(compiled-function () #<bytecode -0x14706cb1bbcafd06>) ("/home/andcor03/emacs2/lisp/org/ol-gnus.elc" . 353) org-link-follow :version "24.4" :package-version (Org . "8.0") org-link-set-parameters "gnus" :follow org-gnus-open :store org-gnus-store-link] 12)
  require(ol-gnus)
  org-load-modules-maybe()
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode--apply-alist((("\\.gpg\\(~\\|\\.~[0-9]+~\\)?\\'" nil epa-file) ("\\.elc\\'" . elisp-byte-code-mode) ("\\.zst\\'" nil jka-compr) ("\\.dz\\'" nil jka-compr) ("\\.xz\\'" nil jka-compr) ("\\.lzma\\'" nil jka-compr) ("\\.lz\\'" nil jka-compr) ("\\.g?z\\'" nil jka-compr) ("\\.bz2\\'" nil jka-compr) ("\\.Z\\'" nil jka-compr) ("\\.vr[hi]?\\'" . vera-mode) ("\\(?:\\.\\(?:rbw?\\|ru\\|rake\\|thor\\|axlsx\\|jbuilder\\|rabl\\|gemspec\\|podspec\\)\\|/\\(?:Gem\\|Rake\\|Cap\\|Thor\\|Puppet\\|Berks\\|Brew\\|Fast\\|Vagrant\\|Guard\\|Pod\\)file\\)\\'" . ruby-mode) ("\\.re?st\\'" . rst-mode) ("/\\(?:Pipfile\\|\\.?flake8\\)\\'" . conf-mode) ("\\.py[iw]?\\'" . python-mode) ("\\.m\\'" . octave-maybe-mode) ("\\.less\\'" . less-css-mode) ("\\.scss\\'" . scss-mode) ("\\.cs\\'" . csharp-mode) ("\\.awk\\'" . awk-mode) ("\\.\\(u?lpc\\|pike\\|pmod\\(\\.in\\)?\\)\\'" . pike-mode) ("\\.idl\\'" . idl-mode) ("\\.java\\'" . java-mode) ("\\.m\\'" . objc-mode) ("\\.ii\\'" . c++-mode) ("\\.i\\'" . c-mode) ("\\.lex\\'" . c-mode) ("\\.y\\(acc\\)?\\'" . c-mode) ("\\.h\\'" . c-or-c++-mode) ("\\.c\\'" . c-mode) ("\\.\\(CC?\\|HH?\\)\\'" . c++-mode) ("\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\'" . c++-mode) ("\\.\\(cc\\|hh\\)\\'" . c++-mode) ("\\.\\(bat\\|cmd\\)\\'" . bat-mode) ("\\.[sx]?html?\\(\\.[a-zA-Z_]+\\)?\\'" . mhtml-mode) ("\\.svgz?\\'" . image-mode) ("\\.svgz?\\'" . xml-mode) ("\\.x[bp]m\\'" . image-mode) ("\\.x[bp]m\\'" . c-mode) ("\\.p[bpgn]m\\'" . image-mode) ("\\.tiff?\\'" . image-mode) ("\\.gif\\'" . image-mode) ("\\.png\\'" . image-mode) ("\\.jpe?g\\'" . image-mode) ("\\.webp\\'" . image-mode) ("\\.te?xt\\'" . text-mode) ("\\.[tT]e[xX]\\'" . tex-mode) ("\\.ins\\'" . tex-mode) ("\\.ltx\\'" . latex-mode) ("\\.dtx\\'" . doctex-mode) ...) nil nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" (14180533 64513))
  find-file-noselect("/home/andcor03/test.org")
  command-line-1(("-eval" "(setq native-comp-jit-compilation t)" "/home/andcor03/test.org"))
  command-line()
  normal-top-level()
==============

Why are we setting 'font-lock-keywords' on test.org if the last major
mode activation we have on the stack is for
'emacs-lisp-compilation-mode'?  IOW why the current buffer is test.org
if 'emacs-lisp-compilation-mode' is called wrapped by
'with-current-buffer' on '*Async-native-compile-log*'?

Also is the value of 'font-lock-keywords' we are setting on test.org the
expected one or are we mixing up things?

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

> If I remove the invocations of 'emacs-lisp-compilation-mode' from
> 'comp-run-async-workers' my org file gets fontified correctly.
> ...
>   k-variable-watcher(font-lock-keywords ... set #<buffer test.org>)
> ...
>   global-font-lock-mode-enable-in-buffers()
>   run-hooks(after-change-major-mode-hook)
>   run-mode-hooks(emacs-lisp-compilation-mode-hook)
>   emacs-lisp-compilation-mode()
>   comp-run-async-workers()
>   native--compile-async("/home/andcor03/emacs2/lisp/net/dbus.el" nil late)
> ...
>   require(dbus)
> ...
>   org-load-modules-maybe()
>   org-mode()
> ...
>   find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" (14180533 64513))

IMHO, it looks like bug#58888 - global font-lock-mode is enabled in the
middle of major mode initialization and messes things up.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Ihor Radchenko <yantar92@posteo.net> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> If I remove the invocations of 'emacs-lisp-compilation-mode' from
>> 'comp-run-async-workers' my org file gets fontified correctly.
>> ...
>>   k-variable-watcher(font-lock-keywords ... set #<buffer test.org>)
>> ...
>>   global-font-lock-mode-enable-in-buffers()
>>   run-hooks(after-change-major-mode-hook)
>>   run-mode-hooks(emacs-lisp-compilation-mode-hook)
>>   emacs-lisp-compilation-mode()
>>   comp-run-async-workers()
>>   native--compile-async("/home/andcor03/emacs2/lisp/net/dbus.el" nil late)
>> ...
>>   require(dbus)
>> ...
>>   org-load-modules-maybe()
>>   org-mode()
>> ...
>>   find-file-noselect-1(#<buffer test.org> "~/test.org" nil nil "~/test.org" (14180533 64513))
>
> IMHO, it looks like bug#58888 - global font-lock-mode is enabled in the
> middle of major mode initialization and messes things up.

Finally we start to see the light :)

What I see is that 'global-font-lock-mode-enable-in-buffers' when
executed iterates over 'global-font-lock-mode-buffers' to do things.
AFAIS when two major modes are being activated at the same time on the
stack it mess things up.

With the following patch installed on my reproducer both the org buffer
and both '*Async-native-compile-log*' are fontified correctly.

diff --git a/lisp/emacs-lisp/comp-run.el b/lisp/emacs-lisp/comp-run.el
index 5cc61579030..d83ea1f514e 100644
--- a/lisp/emacs-lisp/comp-run.el
+++ b/lisp/emacs-lisp/comp-run.el
@@ -297,7 +297,8 @@ comp-run-async-workers
                                          (get-buffer-create
                                           comp-async-buffer-name)
                                        (unless (derived-mode-p 'compilation-mode)
-                                         (emacs-lisp-compilation-mode))
+                                         (let (global-font-lock-mode-buffers)
+                                           (emacs-lisp-compilation-mode)))
                                       (current-buffer))
                              :command (list
                                        (expand-file-name invocation-name
@@ -332,7 +333,8 @@ comp-run-async-workers
     (with-current-buffer (get-buffer-create comp-async-buffer-name)
       (save-excursion
         (unless (derived-mode-p 'compilation-mode)
-          (emacs-lisp-compilation-mode))
+          (let (global-font-lock-mode-buffers)
+            (emacs-lisp-compilation-mode)))
         (let ((inhibit-read-only t))
           (goto-char (point-max))
           (insert "Compilation finished.\n"))))

I'd like to have Stefan opinion if this is okay or we have a better way
to fix this.  If this approach is okay I'll install it with some
commenting.

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  69431@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  hirofumi@mail.parknet.co.jp
> Date: Sun, 07 Apr 2024 13:53:13 +0300
> 
> For me the bug is still present after the patch.

That's infinite recursion, a different problem.

And please in the future do NOT send such large attachments
uncompressed.  Anything above 1MB should be compressed (this
attachment was 12MB).

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Ihor Radchenko <yantar92@posteo.net>,  Stefan Monnier
>>  <monnier@iro.umontreal.ca>,  69431@debbugs.gnu.org,  Eli Zaretskii
>>  <eliz@gnu.org>,  hirofumi@mail.parknet.co.jp
>> Date: Sun, 07 Apr 2024 13:53:13 +0300
>> 
>> For me the bug is still present after the patch.
>
> That's infinite recursion, a different problem.
>

Is there already a bug for this issue or should I open a new one?

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> For me the bug is still present after the patch.

What do you mean with "the bug is still present"?  Which are the actions
that produced the following backtrace?

The patch seems to work here (bootstrap from scratch + some normal use).

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
> Date: Sun, 07 Apr 2024 15:01:24 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Björn Bidar <bjorn.bidar@thaodan.de>
> >> Cc: Ihor Radchenko <yantar92@posteo.net>,  Stefan Monnier
> >>  <monnier@iro.umontreal.ca>,  69431@debbugs.gnu.org,  Eli Zaretskii
> >>  <eliz@gnu.org>,  hirofumi@mail.parknet.co.jp
> >> Date: Sun, 07 Apr 2024 13:53:13 +0300
> >> 
> >> For me the bug is still present after the patch.
> >
> > That's infinite recursion, a different problem.
> >
> 
> Is there already a bug for this issue or should I open a new one?

It depends, I think.  What is the recipe for what you see?

bug#69431: 30.0.50; Strange fontificaion behavior

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

> I'd like to have Stefan opinion if this is okay

It's an ugly workaround, so it would need some comment.

> or we have a better way to fix this.

Yes, it's a problem in `easy-mmode.el`.  I think the patch below should
fix it (it'll need recompiling those files which define globalized
minor modes before it gets effective).

Actually, nowadays modes that don't use `run-mode-hooks` should be
vanishingly rare and I think we could "drop support" for them, which
would significantly simplify that macro.


        Stefan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: globalized-modes.patch --]
[-- Type: text/x-diff, Size: 2883 bytes --]

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index 4fa05008dd8..55cda4c5aea 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -493,6 +493,8 @@ define-globalized-minor-mode
 	 (extra-keywords nil)
          (MODE-variable mode)
 	 (MODE-buffers (intern (concat global-mode-name "-buffers")))
+	 (MODE-enable-in-buffer
+	  (intern (concat global-mode-name "-enable-in-buffer")))
 	 (MODE-enable-in-buffers
 	  (intern (concat global-mode-name "-enable-in-buffers")))
 	 (MODE-check-buffers
@@ -559,10 +561,10 @@ define-globalized-minor-mode
 	 (if ,global-mode
 	     (progn
 	       (add-hook 'after-change-major-mode-hook
-			 #',MODE-enable-in-buffers)
+			 #',MODE-enable-in-buffer)
 	       (add-hook 'find-file-hook #',MODE-check-buffers)
 	       (add-hook 'change-major-mode-hook #',MODE-cmhh))
-	   (remove-hook 'after-change-major-mode-hook #',MODE-enable-in-buffers)
+	   (remove-hook 'after-change-major-mode-hook #',MODE-enable-in-buffer)
 	   (remove-hook 'find-file-hook #',MODE-check-buffers)
 	   (remove-hook 'change-major-mode-hook #',MODE-cmhh))
 
@@ -609,6 +611,22 @@ define-globalized-minor-mode
        ;; List of buffers left to process.
        (defvar ,MODE-buffers nil)
 
+       ;; The function that calls TURN-ON in the current buffer.
+       (defun ,MODE-enable-in-buffer ()
+         (setq ,MODE-buffers (delq (current-buffer) ,MODE-buffers))
+         (unless ,MODE-set-explicitly
+           (unless (eq ,MODE-major-mode major-mode)
+             (if ,MODE-variable
+                 (progn
+                   (,mode -1)
+                   (funcall ,turn-on-function))
+               (funcall ,turn-on-function))))
+         (setq ,MODE-major-mode major-mode))
+       (put ',MODE-enable-in-buffer 'definition-name ',global-mode)
+
+       ;; All the functions below are trying to handle those
+       ;;  major modes which don't use `run-mode-hooks'.
+
        ;; The function that calls TURN-ON in each buffer.
        (defun ,MODE-enable-in-buffers ()
          (let ((buffers ,MODE-buffers))
@@ -618,15 +636,8 @@ define-globalized-minor-mode
            (setq ,MODE-buffers nil)
            (dolist (buf buffers)
              (when (buffer-live-p buf)
-               (with-current-buffer buf
-                 (unless ,MODE-set-explicitly
-                   (unless (eq ,MODE-major-mode major-mode)
-                     (if ,MODE-variable
-                         (progn
-                           (,mode -1)
-                           (funcall ,turn-on-function))
-                       (funcall ,turn-on-function))))
-                 (setq ,MODE-major-mode major-mode))))))
+              (with-current-buffer buf
+                (,MODE-enable-in-buffer))))))
        (put ',MODE-enable-in-buffers 'definition-name ',global-mode)
 
        (defun ,MODE-check-buffers ()

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
> Date: Sun, 07 Apr 2024 18:00:26 +0300
> 
> >> Is there already a bug for this issue or should I open a new one?
> 
> > It depends, I think.  What is the recipe for what you see?
> 
> I can only trigger the bug when I load enough packages to trigger the bug
> First I thought the bug is triggered when I modus themes but it also
> happens without, I just have to load enough packages.
> 
> 
> I attach my init.el (with private information removed) and
> the logs I had from  earlier and now.

It is some kind of recursive call:

  face-attribute->face-attribute-merged-with->face_attribute->...

Looks like a separate problem to me.  It is important to understand
what face causes this, and what is that face's spec.

Also, please make a point of loading the src/.gdbinit file from the
Emacs source tree before running Emacs under GDB, so that the
backtrace includes also the Lisp backtrace, and shows Lisp objects in
human-readable format, for easier reading.

> I tried to find which package exactly triggers the bug but I did not
> manage to do that. I only know that it is triggered through the use of
> faces.

Both backtraces are almost identical, and in both the problem seems to
be triggered by loading and enabling a theme.  So I don't think I
understand what you say here about "enough packages" -- I don't
suppose all of the packages you load are themes, are they?  IOW, can
you show a backtrace from a crash that is not caused by loading a
theme?  E.g., what happens if you remove all theme loading and related
stuff from your init files?

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
>> Date: Sun, 07 Apr 2024 18:00:26 +0300
>>
>> >> Is there already a bug for this issue or should I open a new one?
>>
>> > It depends, I think.  What is the recipe for what you see?
>>
>> I can only trigger the bug when I load enough packages to trigger the bug
>> First I thought the bug is triggered when I modus themes but it also
>> happens without, I just have to load enough packages.
>>
>>
>> I attach my init.el (with private information removed) and
>> the logs I had from  earlier and now.
>
> It is some kind of recursive call:
>
>   face-attribute->face-attribute-merged-with->face_attribute->...
>
> Looks like a separate problem to me.  It is important to understand
> what face causes this, and what is that face's spec.
>
> Also, please make a point of loading the src/.gdbinit file from the
> Emacs source tree before running Emacs under GDB, so that the
> backtrace includes also the Lisp backtrace, and shows Lisp objects in
> human-readable format, for easier reading.

The backtrace was with src/.gdbinit loaded however the lisp wasn't
included the backtace I suspect it is because:
Cannot access memory at address 0x7fffff66ff7f

>> I tried to find which package exactly triggers the bug but I did not
>> manage to do that. I only know that it is triggered through the use of
>> faces.
>
> Both backtraces are almost identical, and in both the problem seems to
> be triggered by loading and enabling a theme.  So I don't think I
> understand what you say here about "enough packages" -- I don't
> suppose all of the packages you load are themes, are they?  IOW, can
> you show a backtrace from a crash that is not caused by loading a
> theme?  E.g., what happens if you remove all theme loading and related
> stuff from your init files?

What do you mean by related?
If I don't load a theme Emacs doesn't crash but if I start Emacs with -Q
and load the theme it's not enough to crash Emacs that's why I mean by
enough packages essentially.

Eventually I isolated the exact problem what caused the bug:
1. (setq max-lisp-eval-depth 32768)
2. load-theme modus-vivendi (any modus theme works as a trigger)

With the Emacs ref c59c8db98a1d031a20ec7850978653657e394baa  
this Emacs doesn't crash with the same settings.

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
> Date: Sun, 07 Apr 2024 21:02:08 +0300
> 
> > Both backtraces are almost identical, and in both the problem seems to
> > be triggered by loading and enabling a theme.  So I don't think I
> > understand what you say here about "enough packages" -- I don't
> > suppose all of the packages you load are themes, are they?  IOW, can
> > you show a backtrace from a crash that is not caused by loading a
> > theme?  E.g., what happens if you remove all theme loading and related
> > stuff from your init files?
> 
> What do you mean by related?
> If I don't load a theme Emacs doesn't crash but if I start Emacs with -Q
> and load the theme it's not enough to crash Emacs that's why I mean by
> enough packages essentially.
> 
> Eventually I isolated the exact problem what caused the bug:
> 1. (setq max-lisp-eval-depth 32768)
> 2. load-theme modus-vivendi (any modus theme works as a trigger)

Are you saying that an init file with only those two lines causes the
crash on your system?

> With the Emacs ref c59c8db98a1d031a20ec7850978653657e394baa  
> this Emacs doesn't crash with the same settings.

OK, but lots of water under the bridge since then...

bug#69431: 30.0.50; Strange fontificaion behavior

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
>> Date: Sun, 07 Apr 2024 21:02:08 +0300
>>
>> > Both backtraces are almost identical, and in both the problem seems to
>> > be triggered by loading and enabling a theme.  So I don't think I
>> > understand what you say here about "enough packages" -- I don't
>> > suppose all of the packages you load are themes, are they?  IOW, can
>> > you show a backtrace from a crash that is not caused by loading a
>> > theme?  E.g., what happens if you remove all theme loading and related
>> > stuff from your init files?
>>
>> What do you mean by related?
>> If I don't load a theme Emacs doesn't crash but if I start Emacs with -Q
>> and load the theme it's not enough to crash Emacs that's why I mean by
>> enough packages essentially.
>>
>> Eventually I isolated the exact problem what caused the bug:
>> 1. (setq max-lisp-eval-depth 32768)
>> 2. load-theme modus-vivendi (any modus theme works as a trigger)
>
> Are you saying that an init file with only those two lines causes the
> crash on your system?

Yes exactly

>> With the Emacs ref c59c8db98a1d031a20ec7850978653657e394baa
>> this Emacs doesn't crash with the same settings.
>
> OK, but lots of water under the bridge since then...

Of course but it's the last ref I know the bug does not trigger with
these settings.

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'd like to have Stefan opinion if this is okay
>
> It's an ugly workaround,

Lets say it's not beautifully 😇

> so it would need some comment.
>
>> or we have a better way to fix this.
>
> Yes, it's a problem in `easy-mmode.el`.  I think the patch below should
> fix it (it'll need recompiling those files which define globalized
> minor modes before it gets effective).

I confirm that with your patch applied the problem is fixed on my
reproducer.  Please apply it (I would have done it for you but I'm not
sure about the Changelog entry).

Thanks

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Andrea Corallo]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>>> Cc: acorallo@gnu.org,  yantar92@posteo.net,  monnier@iro.umontreal.ca,
>>>   69431@debbugs.gnu.org,  hirofumi@mail.parknet.co.jp
>>> Date: Sun, 07 Apr 2024 18:00:26 +0300
>>>
>>> >> Is there already a bug for this issue or should I open a new one?
>>>
>>> > It depends, I think.  What is the recipe for what you see?
>>>
>>> I can only trigger the bug when I load enough packages to trigger the bug
>>> First I thought the bug is triggered when I modus themes but it also
>>> happens without, I just have to load enough packages.
>>>
>>>
>>> I attach my init.el (with private information removed) and
>>> the logs I had from  earlier and now.
>>
>> It is some kind of recursive call:
>>
>>   face-attribute->face-attribute-merged-with->face_attribute->...
>>
>> Looks like a separate problem to me.  It is important to understand
>> what face causes this, and what is that face's spec.
>>
>> Also, please make a point of loading the src/.gdbinit file from the
>> Emacs source tree before running Emacs under GDB, so that the
>> backtrace includes also the Lisp backtrace, and shows Lisp objects in
>> human-readable format, for easier reading.
>
> The backtrace was with src/.gdbinit loaded however the lisp wasn't
> included the backtace I suspect it is because:
> Cannot access memory at address 0x7fffff66ff7f
>
>>> I tried to find which package exactly triggers the bug but I did not
>>> manage to do that. I only know that it is triggered through the use of
>>> faces.
>>
>> Both backtraces are almost identical, and in both the problem seems to
>> be triggered by loading and enabling a theme.  So I don't think I
>> understand what you say here about "enough packages" -- I don't
>> suppose all of the packages you load are themes, are they?  IOW, can
>> you show a backtrace from a crash that is not caused by loading a
>> theme?  E.g., what happens if you remove all theme loading and related
>> stuff from your init files?
>
> What do you mean by related?
> If I don't load a theme Emacs doesn't crash but if I start Emacs with -Q
> and load the theme it's not enough to crash Emacs that's why I mean by
> enough packages essentially.
>
> Eventually I isolated the exact problem what caused the bug:
> 1. (setq max-lisp-eval-depth 32768)
> 2. load-theme modus-vivendi (any modus theme works as a trigger)

I tried the following recipe on latest master but can't reproduce.

BTW this is different bug from the one being treated here, ideally would
be better to have a dedicated bug.

  Andrea

bug#69431: 30.0.50; Strange fontificaion behavior

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  yantar92@posteo.net,
>   monnier@iro.umontreal.ca,  69431@debbugs.gnu.org,
>   hirofumi@mail.parknet.co.jp
> Date: Mon, 08 Apr 2024 03:15:23 -0400
> 
> Björn Bidar <bjorn.bidar@thaodan.de> writes:
> 
> > Eventually I isolated the exact problem what caused the bug:
> > 1. (setq max-lisp-eval-depth 32768)
> > 2. load-theme modus-vivendi (any modus theme works as a trigger)
> 
> I tried the following recipe on latest master but can't reproduce.

Thanks.  Can someone else reproduce with the latest master branch?

> BTW this is different bug from the one being treated here, ideally would
> be better to have a dedicated bug.

Yes.

bug#69431: 30.0.50; Strange fontificaion behavior

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I confirm that with your patch applied the problem is fixed on my
> reproducer.  Please apply it (I would have done it for you but I'm not
> sure about the Changelog entry).

Thanks, pushed, closing,


        Stefan