Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
I can confirm that trashing the eln-cache and restarting emacs with `markdown` in the block list works. -- Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu. Usenet dans ces conditions, c'est comme le web avec lynx, on prend trop conscience du vide, c'est déprimant. - JLC dans le Guide du linuxien pervers: "Coup de cafard..."
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Antoine Beaupré writes: > On 2023-06-11 14:45:19, Nicholas D. Steeves wrote: >> >> Here is a way to work around this bug (whether in Emacs or in markdown-toc). [snip] > > Oh wow, thanks! You're welcome! > That said it doesn't actually work! I have tried both the `--eval` and > the `setq` and neither fix the crash. > > I'm not sure this is related to native compilation, is it really? When I 'rm -rf ~/.emacs.d/eln-cache, and restart Emacs, markdown-toc-generate-toc works correctly, but will eventually break again once various things are compiled again (sooner than later on a fast machine!). I'm not sure why the deny list hack works with an empty eln-cache, but not after a 'rm ~/.emacs.d/eln-cache/*/markdown-toc*'. > I thought it was some imenu thing, maybe it doesn't get autoloaded properly? Based on your hunch, I tested removing each rdep from the eln-cache, and I found that the (wrong-type-argument consp nil) bug occurs in markdown-mode-toc when markdown-mode is native compiled. markdown-toc-generate-toc succeeds for me when ~/.emacs.d/eln-cache/*/markdown-mode-*.eln and ~/.emacs.d/eln-cache/*/markdown-toc-*.eln and ~/.emacs.d/eln-cache/*/imenu-*.eln are removed, and emacs is started with this minimal workaround: emacs --eval="(setq native-comp-deferred-compilation-deny-list '(\"markdown-mode\"))" Yes, markdown-mode, no "toc". For this hack to work long-term for most users, it seems like imenu would probably need to be added to that list...but here's the strange thing: Logically, markdown-toc-generate-toc uses imenu, so it seems like it should trigger native-comp of imenu at L261. Neither markdown-mode, nor markdown-mode-toc explicitly (require 'imenu), so yes, I think you're right that one or both of them is depending on autoloads. Markdown-toc ends up native-compiled using this method, markdown-mode and imenu don't, and for reasons that aren't yet clear, this allows markdown-toc to function correctly. I also wonder if there may be a dash.el+native comp bug in play. 'hope this band-aid does the trick until the root of the problem can be identified. Nicholas signature.asc Description: PGP signature
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
On 2023-06-11 14:45:19, Nicholas D. Steeves wrote:
> Hi,
>
> Here is a way to work around this bug (whether in Emacs or in markdown-toc).
>
> To test:
> emacs --eval="(setq native-comp-deferred-compilation-deny-list
> '(\"markdown-toc\"))"
>
> To make permanent:
> (setq native-comp-deferred-compilation-deny-list '("markdown-toc"))
>
> That said, I'm not convinced that a workaround like this should be
> inserted into Debian's markdown-toc (or any package)...
Oh wow, thanks!
That said it doesn't actually work! I have tried both the `--eval` and
the `setq` and neither fix the crash.
Debugger entered--Lisp error: (wrong-type-argument consp nil)
markdown-imenu-create-nested-index()
markdown-toc-generate-toc(nil)
funcall-interactively(markdown-toc-generate-toc nil)
command-execute(markdown-toc-generate-toc record)
execute-extended-command(nil "markdown-toc-generate-toc" nil)
funcall-interactively(execute-extended-command nil
"markdown-toc-generate-toc" nil)
command-execute(execute-extended-command)
I'm not sure this is related to native compilation, is it really?
I thought it was some imenu thing, maybe it doesn't get autoloaded properly?
a.
--
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Hi,
Here is a way to work around this bug (whether in Emacs or in markdown-toc).
To test:
emacs --eval="(setq native-comp-deferred-compilation-deny-list
'(\"markdown-toc\"))"
To make permanent:
(setq native-comp-deferred-compilation-deny-list '("markdown-toc"))
That said, I'm not convinced that a workaround like this should be
inserted into Debian's markdown-toc (or any package)...
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Antoine Beaupré writes: > You seem to have pasted a link to the TPA GitLab wiki here... Did you > mean to paste some other bug report or link there? That's confirmation that I tested with the link to the file that you were noted (in an earlier post) that you were testing with. > I think I'm okay with the package being removed from bookworm if we > can't find a quick fix here. The release date is just too close. We can > always fix this in a point release or get a backport going. > > Interestingly, it's not marked as autoremoval here though: > > https://tracker.debian.org/pkg/markdown-toc-el Interesting, maybe someone has faith that we'll fix this in a point release! > Alternatively, I wonder if there's a way to make a simpler module that > would defer the TOC generation to an external command... > > Is there something out there that takes a markdown doc as input and > outputs a TOC? I saw your note on python3-md-doc, and it made me think about more generic TOC and endnotes functions that call an external parser. This one might be a viable alternative, with a slightly more active upstream than markdown-toc: https://github.com/snosov1/toc-org#markdown-support Cheers, Nicholas signature.asc Description: PGP signature
