* bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers
@ 2014-12-02 9:50 Ivan Shmakov
2014-12-03 18:23 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Ivan Shmakov @ 2014-12-02 9:50 UTC (permalink / raw)
To: 19250
[-- 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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers
2014-12-02 9:50 bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers Ivan Shmakov
@ 2014-12-03 18:23 ` Stefan Monnier
2014-12-03 19:39 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2014-12-03 18:23 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 19250
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers
2014-12-03 18:23 ` Stefan Monnier
@ 2014-12-03 19:39 ` Stefan Monnier
0 siblings, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2014-12-03 19:39 UTC (permalink / raw)
To: Ivan Shmakov; +Cc: 19250-done
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-03 19:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-02 9:50 bug#19250: elisp-mode.el: completion-at-point fails at M-: for some buffers Ivan Shmakov
2014-12-03 18:23 ` Stefan Monnier
2014-12-03 19:39 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.