Wilfred/helpful

helpful-key void-variable error

mclearc opened this issue · 9 comments

mclearc commented

I'm on emacs-master branch and am seeing the following error whenever I input a key to helpful-key:

...path to *.el package related to coomand...: (void-variable read-symbol-positions-list)

Not sure what `read-symbol-positions-list is, but it seems to only happen with helpful-key (describe-key works fine).

Current emacs version is: GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.3.0, NS appkit-2113.30 Version 12.2 (Build 21D49), git sha1 d4c2f5b524) of 2022-02-02.

EDIT: Actually I am seeing this with all the helpful functions now. Not sure what the issue is, but it may be related to recent change in master.

precompute commented

Encountering similar issues : help-fns--autoloaded-p accepts only one argument now, instead of the previous two.

https://github.com/emacs-mirror/emacs/commits/master/lisp/help-fns.el

  • 👍7
baracunatana commented

As mentioned in Wilfred/elisp-refs#35, it seems to be a problem with a recently removed function and variable in emacs head. The (temporary) solution in https://github.com/snuffop/doom-emacs/commit/deb2bf0d63526b1416e507c5c4f87140fd146c59 (running (defvar read-symbol-positions-list nil)) fixes de issue for me.

  • 👍5
meliache commented

@baracunatana Your workaround works for me and fixes the void-variable error for helpful-variable, but with that fix I now get wrong-number-of-arguments errors for helpful-callable, helpful-command and helpful-key. E.g.

(helpful-function #'next-line)

results in:

Debugger entered--Lisp error: (wrong-number-of-arguments (1 . 1) 2)
  help-fns--autoloaded-p(next-line "/usr/share/emacs/29.0.50/lisp/simple.el")
  helpful--autoloaded-p(next-line #<buffer simple.el>)
  helpful--summary(next-line t #<buffer simple.el> 290402)
  helpful-update()
  helpful--update-and-switch-buffer(next-line t)
  helpful-function(next-line)
  (progn (defvar bootstrap-version) (helpful-function 'next-line))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)

I'm not sure if it's a result of read-symbol-positions-list being nil or something totally unrelated, but tbh I don't see where something got two arguments instead of 1, so if you see it, it would be a great help. Also I'd be happy to know whether others using the fix by @baracunatana also see it.

  • 👍1
kguidonimartins commented

I'm not sure if it's a result of read-symbol-positions-list being nil or something totally unrelated, but tbh I don't see where something got two arguments instead of 1, so if you see it, it would be a great help. Also I'd be happy to know whether others using the fix by @baracunatana also see it.

I can confirm, @meliache. I'm getting the same error as you after the proposed fix.

  • 👍1
dakra commented

@meliache @kguidonimartins I just removed the file-name parameter here.
This works for me but I'm not sure what's the proper fix.

  • 🎉1
baracunatana commented

I'm not sure if it's a result of read-symbol-positions-list being nil or something totally unrelated, but tbh I don't see where something got two arguments instead of 1, so if you see it, it would be a great help. Also I'd be happy to know whether others using the fix by @baracunatana also see it.

True. Another temporary fix can be found on this pull request (#283). You can add this to your init file and it works (at least for me)

(defun helpful--autoloaded-p (sym buf)
  "Return non-nil if function SYM is autoloaded."
  (-when-let (file-name (buffer-file-name buf))
    (setq file-name (s-chop-suffix ".gz" file-name))
    (help-fns--autoloaded-p sym)))

(defun helpful--skip-advice (docstring)
  "Remove mentions of advice from DOCSTRING."
  (let* ((lines (s-lines docstring))
         (relevant-lines
          (--take-while
           (not (or (s-starts-with-p ":around advice:" it)
                    (s-starts-with-p "This function has :around advice:" it)))
           lines)))
    (s-trim (s-join "\n" relevant-lines))))

Do keep in mind that this most likely won't work in versions of emacs prior to 29.0.50 and that you'll have to remove this code once the pull request is accepted or this bug is fixed in any other way.

  • 👍2
mclearc commented

Yeah I've been using PR #283 with no problems on recent nightly builds of emacs 29.

  • 👍1
ZacJoffe commented

Can also confirm that the fix from #283 works on my desktop running Arch. My emacs-version for my desktop:

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4) of 2022-02-17

Edit: Just tested it quickly on my work laptop (2021 MBP with Emacs 29 built on arm using this) and it works there too.

  • 👍2