Symbol's function definition is void: ## when repeating previous function #21

demon386 opened this Issue Aug 28, 2012 · 17 comments

4 participants


Say if I first call a command with M-x, then after a while I need to call the same command. I would press M-x and end RET, but an error would appear:

smex-read-and-run: Symbol's function definition is void: ##


I started seeing this too with the 20120825 release.


Which command did you call? Was the command still defined when the error occured?


I've noticed on multiple commands, e.g., rgrep, helm, perhaps others. I'm pretty sure the commands were still defined because the error comes and goes for each command within a single session. How can I confirm whether a command is still defined? (I normally invoke commands through smex.)


If it shows up in regular M-x it's still defined. (rgrep should be always defined, anyway.)

Is there a chance you could figure out a set of steps that reproduce the bug?


Does the error reappear on subsequent calls to the command?

Please also try the following:
1. Run M-x toggle-debug-on-error
2. A backtrace buffer will now pop up when an Emacs error occurs. Post the backtrace for this specific error.


I can consistently reproduce this. Steps.

  1. Launch emacs.
  2. M-x query-replace (for example) (specific command doesn't seem to matter)
  3. M-x query-replace (repeat the same command).


Debugger entered--Lisp error: (void-function ##)
  command-execute(## record)
  smex-read-and-run(("query-replace" "toggle-debug-on-error" "rgrep" "balance-windows" "cua-mode" "comment-or-uncomment-region" "kill-buffer" "helm" "clojure-jack-in" "mo-git-blame-current" "whitespace-cleanup" "swap-windows" "shell" "auto-fill-mode" "size-and-position-frame" "dired-do-byte-compile" "package-list-packages-no-fetch" "query-replace-regexp" "emacs-uptime" "align-regexp" "eval-expression" "clean-buffer-list" "paredit-mode" "disable-theme" "flyspell-mode" "load-theme" "package-list-packages" "presentation-mode" "byte-compile-file" "undo-tree-redo" "ruby-mode" "indent-region" "indent-buffer" "fill-paragraph" "list-processes" "revert-buffer" "find-dired" "inferior-lisp" "ediff" "org-mode" "html-mode" "clojure-mode" "dired" "linum-mode" "print-buffer" "htmlfontify-buffer" "enable-theme" "describe-theme" "fundamental-mode" "bookmark-jump" ...))
  call-interactively(smex nil nil)

And yes, the same error occurs on subsequent calls to the same command. Executing a different command seems to reset the problem. In other words, executing a different command will work, and then the original command (query-replace in the example) will work again.


Not sure if this is important, but I'm running Emacs 24.2.1. I upgraded Emacs and smex (from 20120812 to 20120825) (and of course several other packages) at the about the same time and started seeing the problem right after that.


I have this problem since some upgrade of smex in Emacs 24.1.

For me the problem can be reproduced in every command, with the procedure I described in the post.

Here is the step and output:

  1. M-x toggle-debug-on-error --> OK
  2. M-x RET --> error

The error information is:

Debugger entered--Lisp error: (void-function ##)
command-execute(## record)
smex-read-and-run(("toggle-debug-on-error" "quickrun" "package-list-packages-no-fetch" "list-packages" "package-install" "org-version" "clojure-jack-in" "comment-or-uncomment-region" "auto-complete-mode" "replace-string" "ein:notebooklist-open" "byte-recompile-directory" "up-list" "indent-region" "package-list-packages" "slime-connect" "slime" "byte-compile-file" "auto-complete" "maximize-frame" "org-archive-subtree" "nxml-mode" "line-number-mode" "occur" "apropos" "flymake-mode" "eval-last-sexp" "imenu" "mmm-mode" "org-mode" "autopair-mode" "light" "python-mode" "dark" "idomenu" "yas/minor-mode" "js2-mode" "speedbar" "eval-buffer" "semantic-mode" "slime-eval-buffer" "org-add-note" "cua-selection-mode" "hungry-delete-mode" "linum-mode" "follow-mode" "restore-frame" "revert-buffer" "browse-current-file" "ediff" ...))
call-interactively(smex nil nil)


I can't reproduce this neither with my Emacs config nor on vanilla Emacs 24.1.1 (with only Smex installed).

Please share your config. I'm assuming you have an .emacs.d that includes init.el:
1. Copy your .emacs.d to .emacs.d.bug
2. Remove all confidential, non-public stuff from .emacs.d.bug
3. Start an Emacs instance with the debug config: emacs -q -l ~/.emacs.d.bug/init.el
4. Check if the bug is still reproducable.
5. Upload .emacs.d.bug along with your .smex-items file.
Post your Emacs version and all steps that reproduce the bug after Emacs has started.


I try to reproduce the problem with a minimal setting.

I guess the problem has something todo with ido-ubiquitous



Great, thanks!

The bug always occurs when you press enter right after running Smex, while ido-ubiquitous is enabled.
It's independent of the Smex version used.

I'll cook up a fix over the weekend.


I guess I've figured out the problem. After inspecting ido-ubiquitous.el, I found that the following lines of code make the problem (feature?):

Line 259 -- 280 of ido-ubiquitous.el:

(defadvice ido-exit-minibuffer (around required-allow-empty-string activate)
  "Emulate a quirk of `completing-read'.

Apparently, in the past `completing-read' used to request the
default item by returning an empty string when RET was pressed
with an empty input. This forces `ido-completing-read' to do the
same (instead of returning the first choice in the list),
allowing the default to be properly selected.

This has no effect when ido is completing buffers or files.

This behavior is disabled by setting
`ido-ubiquitous-enable-compatibility' to nil."
  (if (and ido-ubiquitous-enable-compatibility
           (eq ido-cur-item 'list)
           (null ido-default-item)
           (not current-prefix-arg)
           (string= ido-text "")
           (string= (car ido-cur-list)

ido-ubiquitous-enable-compatibility is set to t by default. Setting it to nil would solve the problem. However, I don't know what this variable exists for. You might consider setting it to nil locally in the smex functions.


Yes. This commit, released 6 days ago, introduced the bug.

You might revert it until further notice.


I've filed a bug report for ido-ubiquitous.


I thought this was a bug in smex, and solved it by setting the default value to (car choices) in ido-completing-read. Like so:

(defun smex-completing-read (choices initial-input)
(let ((ido-completion-map ido-completion-map)
(ido-setup-hook (cons 'smex-prepare-ido-bindings ido-setup-hook))
(ido-enable-prefix nil)
(ido-enable-flex-matching smex-flex-matching)
(ido-max-prospects 10))
(ido-completing-read (smex-prompt-with-prefix-arg) choices nil t initial-input nil (car choices))))

This seems like a sensible fix to me. Why not set the default to the first item in choices?


Thanks, ahyatt.

I've added a fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment