Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid read syntax: "]" #270

Open
patrolli opened this issue Jul 6, 2021 · 14 comments
Open

Invalid read syntax: "]" #270

patrolli opened this issue Jul 6, 2021 · 14 comments

Comments

@patrolli
Copy link

patrolli commented Jul 6, 2021

When I use helpful-function to search org-toggle-inline-images, I got an error: "Invalid read syntax: "]", 1, 125". I found some other functions will also cause this problem, e.g. python-mark-defun.

I also found the problem occurs when the el.gz file will be opened, for example, I search org-toggle-inline-image, it failed, and the org.el.gz file will be opened.

The backtrace screeshot are here:

capture_2021_07_06_18_05_06

@rogpld
Copy link

rogpld commented Oct 1, 2021

I'm having the same problem. Have been able to work around the issue?

@amno1
Copy link

amno1 commented Oct 5, 2021

I have just tested with 'org-toggle-inline-images', it worked without problem with helpful-callable, so it is probably something in your setup. Have you tried to run Emacs with -Q option and just load helpful.el and see if it works then?

I don't know which package defines python-mark-defun, I don't seem to have it installed, so I can't confirm that one. My Emacs is from the latest master:

GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, cairo version 1.17.4)
of 2021-10-05

But I don't think that matters.

I also suggest installing Emacs with sources uncompressed or to run it form the source directory, that speeds up helpful quite a bit.

@rogpld
Copy link

rogpld commented Oct 6, 2021

I have just tested with 'org-toggle-inline-images', it worked without problem with helpful-callable, so it is probably something in your setup. Have you tried to run Emacs with -Q option and just load helpful.el and see if it works then?

I'm actually using emacs from a snap, to avoid the compilation time. That might be the issue. emacs -q and requiring helpful does work. It is definitely something with my setup, sadly.

@amno1
Copy link

amno1 commented Oct 6, 2021

It is definitely something with my setup, sadly.

Those things happen.

Since you are two different persons, it might be some external package doing something. You will have to debug your setup, like uncomment half, run Emacs, then uncomment half of the half and so, if you can't guess what might cause the syntax error.

@rogpld
Copy link

rogpld commented Oct 6, 2021

It is definitely something with my setup, sadly.

Those things happen.

Since you are two different persons, it might be some external package doing something. You will have to debug your setup, like uncomment half, run Emacs, then uncomment half of the half and so, if you can't guess what might cause the syntax error.

The issue seems to be on helpful. The syntax error comes when calling something like helpful-function. Removing the helpful configuration from the init and rolling back to emacs original describe-function works. I'm not sure what the problem is. The snap I'm using does have the source files compressed though. Check the backtrace.

Debugger entered--Lisp error: (invalid-read-syntax "]" 1 81)
  read(#<buffer subr.el.gz>)
  find-function--search-by-expanding-macros(#<buffer subr.el.gz> with-current-buffer nil)
  #<subr find-function-search-for-symbol>(with-current-buffer nil "/var/lib/snapd/snap/emacs/1268/usr/share/emacs/28....")
  ad-Advice-find-function-search-for-symbol(#<subr find-function-search-for-symbol> with-current-buffer nil "/var/lib/snapd/snap/emacs/1268/usr/share/emacs/28....")
  apply(ad-Advice-find-function-search-for-symbol #<subr find-function-search-for-symbol> (with-current-buffer nil "/var/lib/snapd/snap/emacs/1268/usr/share/emacs/28...."))
  find-function-search-for-symbol(with-current-buffer nil "/var/lib/snapd/snap/emacs/1268/usr/share/emacs/28....")
  helpful--definition(with-current-buffer t)
  helpful-update()
  helpful-function(with-current-buffer)
  eval-expression((helpful-function 'with-current-buffer) nil nil 127)
  funcall-interactively(eval-expression (helpful-function 'with-current-buffer) nil nil 127)
  command-execute(eval-expression)

@amno1
Copy link

amno1 commented Oct 6, 2021

The issue seems to be on helpful.

I don't think so; you said you tested with -Q option, and it worked, so it is probably something else.

Looking at the stack trace:

read(#<buffer subr.el.gz>)

read is a built-in function. I don't know myself if it handles compressed files internally, or they have to be passed in uncompressed before passed to read. Docs for 'read' mention nothing about compressed streams, so no idea tbh. But if it works for you with -Q option, then it is not that.

@rogpld
Copy link

rogpld commented Oct 6, 2021

I've built from source and it works like a charm. So the issue must be the combination of the snap package build with my config.

@amno1
Copy link

amno1 commented Oct 6, 2021

Ok, great it works. Tbh, I have no idea what "snap package" is, but great it works when you build from the source. I recommend also running Emacs from the src directory instead of installing; that removes delays caused by decompressing sources to display Helpful buffers. It least what I have experienced on my computer.

@rogpld
Copy link

rogpld commented Oct 7, 2021

Emacs snap with native compilation comes from here. It seems to be way faster when run from the source folder. Good to know.

@buhtz
Copy link

buhtz commented Nov 7, 2021

I am not sure what it is but I have this in my message buffer

helpful--find-by-macroexpanding: Invalid read syntax: ")"

when I try

C-h display-graphic-p

EDIT:
I do not know the details but I would assume this is not helpful related. With this init.el I can reproduce my problem

;;;;;; Set file-name-handler-alist
;; see: https://emacs.stackexchange.com/a/34367/12999
;; see: https://www.reddit.com/r/emacs/comments/3kqt6e/2_easy_little_known_steps_to_speed_up_emacs_start/
(setq file-name-handler-alist-original file-name-handler-alist)
(setq file-name-handler-alist nil)

;; === Package setup ===
(require 'package)
(setq package-archives '(("melpa" . "https://melpa.org/packages/")
			 ("org" . "https://orgmode.org/elpa/")
			 ("elpa" . "https://elpa.gnu.org/packages/")))
;; Initializes the package infrastructure
(package-initialize)

;; === use-package ==
;; use-package to simplify the config file
(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

(require 'use-package)
(setq use-package-always-ensure 't)

;; === improving help output and emacs intern docu
(use-package helpful
  :custom
  (counsel-describe-function-function #'helpful-callable)
  (counsel-describe-variable-function #'helpful-variable)
  :bind
  ([remap describe-function] . counsel-describe-function)
  ([remap describe-command] . helpful-command)
  ([remap describe-variable] . counsel-describe-variable)
    ([remap describe-key] . helpful-key))

When you remove the file-name-handler-alist part on top of the code. The problem is not reproducable.
Or if you remove the :custom and :bind lines from the use-package helpful section.

I do not know why. Just want to report here.

@amno1
Copy link

amno1 commented Nov 7, 2021

I can't reproduce this in my Emacs, so it is definitely your setup.

When you remove the file-name-handler-alist part on top of the code. The problem is not reproducable.

So have you restored 'file-name-handler-alist' at the end of your setup? People usually set this to nil at the start of their init file and restore to its old value at the end.

Somewhere at the end of your init file, or in 'after-init-emacs' hook, you should have:

(setq file-name-handler-alist file-name-handler-alist-original )

I don't think it has to do with your problem, but you should certainly restore it back.

What might be a problem in your setup is a missing parenthesis:

:bind
  ([remap describe-function] . counsel-describe-function)
  ([remap describe-command] . helpful-command)
  ([remap describe-variable] . counsel-describe-variable)
    ([remap describe-key] . helpful-key))

Try this:

:bind
  (([remap describe-function] . counsel-describe-function)
  ([remap describe-command] . helpful-command)
  ([remap describe-variable] . counsel-describe-variable)
    ([remap describe-key] . helpful-key)))

@buhtz
Copy link

buhtz commented Nov 8, 2021

So have you restored 'file-name-handler-alist' at the end of your setup? People usually set this to nil at the start of their init file and restore to its old value at the end.

Yes and no I do but forgot the code. It is done when emacs goes to idle. When I wait after startup the C-h f works without the error. This indicates that it has something to do with file-name-handler-alist.

;; === Reset values for startup optimzation
;; see: https://emacs.stackexchange.com/a/34367/12999
;; It is run-with-idle-timer instead of after-init-hook because "that would
;; run immediately after initialization, which might make the user wait for
;; GC. By using an idle timer, it can run when the user's not using Emacs."
(run-with-idle-timer
 5 nil
 (lambda ()
   (setq file-name-handler-alist file-name-handler-alist-original)
   (makunbound 'file-name-handler-alist-original)
   (message "file-name-handler-alist restored")))

You can not reproduce this with my init.el?

I don't think it has to do with your problem, but you should certainly restore it back.

It does.

What might be a problem in your setup is a missing parenthesis:

Can you please check my original code. I do not see a missing paranthesis. I would assume that this would case an error when starting emacs and my rainbow-delemiter package also do not see a missing one.

@amno1
Copy link

amno1 commented Nov 10, 2021

I do not see a missing paranthesis.

You do. Check use-package documentation for 'bind' keyword.

https://jwiegley.github.io/use-package/keywords/

@jhenahan
Copy link

For anyone else who finds this through a search engine, I found that I hit this when I neglected to restore my file-name-handler-alist in after-init-hook after setting it nil in early-init. This left me with the file handler for tarballs (jka-compr-handler) missing from the list, so when helpful tries to read the gzip'd source it has a bad time. early-init snippet for people who want to do as I do:

(defvar my--file-name-handler-alist file-name-handler-alist)
(setq-default file-name-handler-alist nil)

(add-hook 'after-init-hook
  (lambda ()
    (setq file-name-handler-alist my--file-name-handler-alist)))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants