bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers

bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers

[Ivan Shmakov]

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

Package:  emacs
Severity: minor

	With a recently-built Emacs (287740d6; 2014-11-29 13:56:59Z),
	the following sequence results in the backtrace MIMEd
	(redacted.)  I do not observe the issue with 24.3.1, so it
	appears to be a regression.

$ emacs -Q 
C-x b *xxx* RET
(#
M-: xx TAB

	This seems to happen because elisp--local-variables tries to
	gather variable names for completion from the contents of the
	buffer M-: is invoked from, while such buffer does not
	necessarily hold any (valid) Emacs Lisp code.

	My suggestion would be to either make elisp--local-variables
	fail more gracefully (say, using with-demoted-errors), or to
	introduce a (derived-mode-p 'emacs-lisp-mode) guard to the code.

	As a workaround, the following seems to help:

(setq elisp--local-variables-completion-table nil)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

[-- Attachment #2: Type: text/plain, Size: 1573 bytes --]

Debugger entered--Lisp error: (invalid-read-syntax "#")
  read-from-string("(#elisp--witness--lisp)")
  elisp--local-variables()
  #[257 …]("xx")
  #[771 …]("xx" nil nil)
  try-completion("xx" #[771 …] nil)
  #[257 …](#[771 …])
  mapcar(#[257 …] (#[771 …] (closure (t) (&rest args) (apply (quote completion-table-with-predicate) …))))
  #[771 …]("xx" nil nil)
  try-completion("xx" #[771 …] nil)
  completion-basic-try-completion("xx" #[771 …] nil 2)
  #[257 …](basic)
  completion--some(#[257 …] (basic partial-completion emacs22))
  completion--nth-completion(1 "xx" #[771 …] nil 2 (metadata))
  completion-try-completion("xx" #[771 …] nil 2 (metadata))
  completion--do-completion(#<marker at 7 in  *Minibuf-1*> 9)
  completion--in-region-1(#<marker at 7 in  *Minibuf-1*> 9)
  #[1028 …](#<marker at 7 in  *Minibuf-1*> … nil)
  apply(#[1028 …] (#<marker at 7 in  *Minibuf-1*> … nil))
  #[771 …](nil nil (#<marker at 7 in  *Minibuf-1*> … nil))
  completion--in-region(#<marker at 7 in  *Minibuf-1*> 9 #[771 …] nil)
  completion-in-region(#<marker at 7 in  *Minibuf-1*> 9 #[771 …] nil)
  completion-at-point()
  funcall-interactively(completion-at-point)
  call-interactively(completion-at-point nil nil)
  command-execute(completion-at-point)
  read-from-minibuffer("Eval: " nil (keymap …) t read-expression-history)
  read--expression("Eval: ")
  byte-code(… [current-prefix-arg read--expression "Eval: "] 2)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)

bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers

[Stefan Monnier]

> 	This seems to happen because elisp--local-variables tries to
> 	gather variable names for completion from the contents of the
> 	buffer M-: is invoked from, while such buffer does not
> 	necessarily hold any (valid) Emacs Lisp code.

Indeed we have two bugs: we gather the local vars from the wrong buffer,
and we don't ignore invalid-read-syntax errors (which can happen in
various other legitimate cases).

The second bug is trivial to fix, the first is a bit more delicate
because the buffer-switching is done by completion-table-dynamic and I'm
pretty sure it's done for a good reason (i.e. while it's undesirable
here, it's desirable in some other case(s)), so we'll first have to
figure out which are those other cases and how to fix this case
without breaking those others.


        Stefan

bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers

[Stefan Monnier]

> The second bug is trivial to fix, the first is a bit more delicate
> because the buffer-switching is done by completion-table-dynamic and I'm
> pretty sure it's done for a good reason (i.e. while it's undesirable
> here, it's desirable in some other case(s)), so we'll first have to

It looks like all the cases where buffer-switching was needed happened
to be going through lazy-completion-table, so I incompatibly changed the
behavior of completion-table-dynamic and adjusted
lazy-completion-table accordingly.

Crossing fingers,


        Stefan