Stefan Monnier writes: > When eldoc is activated in the minibuffer and uses the elisp backend > because we're reading an elisp expression, then the syntax-table should > also be set accordingly, indeed (not only for eldoc but also for > forward-sexp, ...). > > Looks like a bug in the corresponding function (`read-expression` or nearby). OK, I've attached another patch for that function. >>> For one, the elisp-mode.el function `elisp--current-symbol' isn't >>> wrapped in a `with-syntax-table', unlike other similar definitions >>> in the same file. I think anyone invoking this function could >>> reasonably expect it to observe elisp syntax, so that's what my tiny >>> patch addresses. > > It's probably OK to do it as in your patch, yes. > If you change `read--expression', I don't know whether you'll think it makes sense to add the extra overhead to `elisp--current-symbol'. It does have a silent dependency on the syntax table, which is arguably an inherent bug. But it's an internal function which only (right now) gets called in one place. > I'm pretty sure just calling the major will break something. > I can't offhand tell you what, tho. Writing the comment was faster than > trying it out and then seeing how to fix the corresponding problems. I can confirm that it suffers from the fairly significant drawback of not working at all. Since the major replaces the minibuffer-specific keymap, nothing ends up bound to `exit-minibuffer', so you can't even enter an expression (or do anything else, like history paging). You could bind `overriding-local-map' at the top of the function, but with that and the syntax table you're getting close to implementing a de facto new mode inside the de jure old one. At that point it might as well be a real custom major mode, as you suggested. And then there's the possibility that some people's `emacs-lisp-mode-hook' might contain code that assumes it's in a real buffer and misbehaves in the minibuffer. On the other hand, you could do what eshell does for `eshell-command' and turn on its major mode in the minibuffer while selectively binding C-j, C-m, M-p, etc., inside the setup hook. I don't like this design at all: if I were to make changes to my `minibuffer-local-map' bindings, eshell would silently ignore them. Any custom mode for minibuffer input should inherit an existing minibuffer keymap, in my book at least. Daniel