I am sure some of you may have gathered (from my recent barrage of questions) that I am setting up org-mode on emacs and walking through Brent Hansen's impressive org set up. He is a clocking fanatic, and I like a lot of the stuff he does to track time spent on projects.
I (think) haven't messed up in setting things up, but whenever I try to clock in our out of a task I get an error with a lot of gibberish (reported below). I've tried to see if there are some patterns to how the error emerges but am unable to discover them. They seem to happen pretty often but not all the time which makes debugging them an even bigger pain.
Typically, when I clock out of a task (but sometime when I clock in too), I get a message like this
save-excursion: Wrong number of arguments: #[(drawer pos) "rÂ!
Ã!pq~bÄÅ ÆQÇ\"$ÈÉ!+" [pos drawer markerp marker-buffer org-in-regexp "^[ ]*:" ":[ ]*
[ ]*:END:[ ]*
?" 2 replace-match ""] 4 ("/Users/krishnan/.emacs.d/elpa/org-20140210/org.elc" . 450779)], 1
[a-z..]:Set [SPC]:clear [2 times]
As always, I am happy to follow up to questions that might help discover the source of the error. I have not been able to discern if it standard practice to include my entire .emacs etc, but am happy to post follow up information as is needed.
Many thanks in advance!
edit 1: Following #iqbal-ansari , I did M-x toggle-debug-on-error which produces the following gunk:
Debugger entered--Lisp error: (wrong-number-of-arguments #[(drawer pos) "r\302!\203
\303!\202pq\210\212\214~\210b\210\304\305 \306Q\307\"\205$\310\311!+\207" [pos drawer markerp marker-buffer org-in-regexp "^[ ]*:" ":[ ]*
[ ]*:END:[ ]*
?" 2 replace-match ""] 4 ("/Users/krishnan/.emacs.d/elpa/org-20140210/org.elc" . 450779)] 1)
org-remove-empty-drawer-at(307)
(save-excursion (beginning-of-line 0) (org-remove-empty-drawer-at (point)))
bh/remove-empty-drawer-on-clock-out()
#[(f) " \207" [f] 1](bh/remove-empty-drawer-on-clock-out)
mapc(#[(f) " \207" [f] 1] (org-clock-remove-empty-clock-drawer bh/remove-empty-drawer-on-clock-out bh/clock-out-maybe))
byte-code("\306 \204\307\310\" \311 \210\203\312\313\314\"\210\202\315\316!\210\f\2035\317\320r\321
!q\210#)\322\314\323%\2027A\324B!\322\211\211\211\211\211CDEFGHIAIJ\212\325 q\210\214~\210
b\210\326\327!\210\330\331KP!\203~\332\327!L\232\203~\332\333!H\202\216\203\212\312\313\322\"\210\202\216\334\335!\210\336\225b\210`\337 |\210\340c\210\341M\206\242I\342\343#G\344\345\346\347G!\"!\344\345\346\347H!\"!ZF\350F\351\245!EFE\351_ZF\350F\352\245!DF\211\352_ZF\353\354\355ED#\261\210N\205\364ED\\\336U\211C\203\326\327!\210`\337 |\210\330\356!\203d`TV\203\357\327!\210
\322\211\223\210O\322\211\223\210P\2033\360\361\322\211\211\211\362\363\314!\364Q&\210Q\203#\365Q!\210\322QR\203M\365R!\210\322R\307\310\" A\203\234\212\366\314!\210\314\322ST\367A!\203\205\330U!\210A\332\333!!\211V\203\201\370V!\210)\202\233A\203\233\330W\331A\371R!\204\233\370A!\210+\311 \210\372\373\374E\352_D\\!\375QGC\203\267\376\202\270\377#\210XEYZ\232\203\335[\201]=\203\335S\203\335\307\201^E\"E\201_\201`E\"\210)\306 ?\205\362\322\211\\.\n\207" [global-mode-string org-frame-title-format-backup frame-title-format fail-quietly switch-to-state org-clock-marker org-clocking-p delq org-mode-line-string force-mode-line-update throw exit t user-error "No active clock" completing-read "Switch to state: " marker-buffer nil "DONE" org-current-time org-clocking-buffer beginning-of-line 1 looking-at "[ ]*" match-string 2 error "Clock start time is gone" 0 point-at-eol "--" org-insert-time-stamp with-hm inactive org-float-time apply encode-time org-parse-time-string floor 3600 60 " => " format "%2d:%02d" "\n" delete-char org-add-log-setup clock-out ...] 10)
org-clock-out()
org-clock-out-if-current()
run-hooks(org-after-todo-state-change-hook)
byte-code("\306\307!\210\310\311P!\203\312 \210\307\310\n!\203\313\225Sb\210\310\314\315Q!\204)\310\316!\210\304 \317 \304 #\320\216\321\322\323\307\211$*ABBCCDDE\313\232\203X\322E\324\202ZFF\325\326!G\313\224H\327G!I\330IJ\"\211KA#L\331K8M\332K8NG\206\212\333O\307PGQ\235\211RAST\203\303E\334\232\203\255U\335=\204\276E\204\303U\203\303U\335=\204\303\336 \202E\337\232\203\341U\203\324T\204\341\340\341\342\343Q\"\322\307$\202E\344=\203\376G\203\370S\205S#\202Q#\202E\345=\203/RQ\232?\205G\203\"\346QGSG\347#Q8\202Q#\350#!#)\202U\307=\203DE\351\232\203D\322\211E\206E\203\310E\333\232\203T\322\202E\352=\203_\322\202E\353=\203qM\206V#\202E\354=\203\210IW\235A#\206W#\202E\355=\203\246\356W!WIW\235A#\206\242W#)\202EQ\235#\206E;\203\275\357\360E\"\202\361E!SQ8\202R\204\330I\206Q#\202GN\232\203\344\322\202S\204\355\322\202L\362>\203XY=\203S#\202SG\313V\205M\206V#\202S#Z\363\364ZO#\206&Z\211Z\2034\365Z\365Q\2025\365[\366\367\370G\371Z\372
\257\\\322\211]^=\203\230GV\235?_\212\304 #\373\216\212\214~\210\374\375\\\"-\204\230\376\377!\203\201\357\201jGZ`$\210\202\230\201k\201jGZ`$\210\201l\201m\322\"\210\201n\f!\210\201o[\307\211#\210\201pH!\204\276\201k\201q\201r[!\"\210I\204\342\327Z!I\330IJ\"\211KA#L\331K8M\332K8NE\201s>\203\201k\201t\346aG\201u\330Za\"a>G#aG\201v\201w\330Za\"\365#$\210ZV\235?_ZV\235\205,GV\235?^A\203:\201xA!\210D\204DB\203\357F\307=\204\357E\201y>\204\357\330ZD\"A#\206g\347\330GD\"8\211]\324=\203{F\324=\203{\201z]Z\204\205b\203\232Z\203\244Zc\235\203\244Gc\235\204\244\201{\322\211\201|#\210^\203\324B\203\324\201{\201|\201} \"\210]\204\324B\324=\203\324\201~\353ZG\201\324%\210Z\203\357]\203\357\201~\201\200ZG\201]%\210\201\201Z!\210d\203e\204\201\202\322\307\"\210f\203\201\203 \210\201\204\201\205!\210E\203,ZV\235\204,\327Z!I\201\206\317 \201\207 \201\210I$\210^\203a\201\211\201g!\203Z\304 #\201\212\216\201\213 g*\201\214Z!\210\201\215 \203\235n\204\235\212\201\216\326!\210\310h!)\203\235`\347\211\225\206\204\326\225\\W\203\235\347\225\206\220\326\225b\210\310\365!\203\235\201\217 \210i\203\256\212\201\220\201i\\\"\210) \205\264\312 .\207" [org-comment-string commentp org-outline-regexp org-todo-regexp match-data startpos org-back-to-heading t looking-at "^\\*+ " org-toggle-comment 0 " +" "\\( +\\|[ ]*$\\)" "\\(?: *\\|[ ]*$\\)" point-at-bol ((byte-code "\301\302\"\207" [save-match-data-internal set-match-data evaporate] 3)) org-entry-get nil "LOGGING" note match-string 1 org-get-todo-sequence-head assoc 3 4 "" (4) prefix org-fast-todo-selection (4) org-icompleting-read "State: " mapcar list right left - 2 last (4) none done nextset previousset reverse user-error "State `%s' not valid in this file" prefix-numeric-value ...] 10)
org-todo(nil)
call-interactively(org-todo)
org-agenda-todo(nil)
call-interactively(org-agenda-todo nil nil)
The issue is caused by the line (org-remove-empty-drawer-at (point)) in the function bh/remove-empty-drawer-on-clock-out. If you read the documentation of the function org-remove-empty-drawer-at (do C-hforg-remove-empty-drawer-atRET, it says that the function accepts two arguments drawer and point while the function bh/remove-empty-drawer-on-clock-out passes only one argument (point). This causes the error you reported. It seems the code was written for an older version of org-mode.
This is a temporary solution, remove the line
(add-hook 'org-clock-out-hook 'bh/remove-empty-drawer-on-clock-out 'append)
from your init file (and restart emacs). This will get rid of the error.
UPDATE
I got (I think) a permanent solution to the problem. The first argument to the function org-remove-empty-drawer-at is the name of the drawer to remove, from Brent Hansen's setup it seems he wants to remove empty 'LOGBOOK' drawers, in this case the modify the function bh/remove-empty-drawer-on-clock-out as follows
(defun bh/remove-empty-drawer-on-clock-out ()
(interactive)
(save-excursion
(beginning-of-line 0)
(org-remove-empty-drawer-at "LOGBOOK" (point))))
Note that the argument "LOGBOOK" has been added to the call to function org-remove-empty-drawer-at. Also now you do not need to remove the line
(add-hook 'org-clock-out-hook 'bh/remove-empty-drawer-on-clock-out 'append)
from your init file.
Faced this issue after updating to Org-mode version 8.3.3 (8.3.3-51-g30bcff-elpa). Before the update, it was already working on my Emacs 24.4 (Linux OS, built from sources), thanks to the answer from user2053036.
Looks like the extra parameter is no longer needed in this version. My working init file now looks like:
(defun bh/remove-empty-drawer-on-clock-out ()
(interactive)
(save-excursion
(beginning-of-line 0)
(org-remove-empty-drawer-at (point))))
(add-hook 'org-clock-out-hook 'bh/remove-empty-drawer-on-clock-out 'append)
Related
The following code fails to highlight 23's in 23-23 if pasted and evaluated in the scratch buffer, but not if done in a text buffer.
;; Example 1
'(1234 23 23-23 end)
(progn
(font-lock-add-keywords nil
`(("\\b23\\b"
(0 'success))
"end"))
(font-lock-fontify-buffer))
Why does it fail when M-x isearch-forward-regexp RET \b23\b still matches 23's in 23-23?
Even if I change to the following code, only the first 23 in 23-23 gets highlighted.
;;; Example 2
'(1234 23 23-23 end)
(progn
(font-lock-add-keywords nil
`((,(rx (or word-boundary
"-")
(group "23")
(or word-boundary
"-"))
(1 'success))
"end"))
(font-lock-fontify-buffer))
Side note: "end" is there so that I can detect if the highlighter for 23 is ill formed. If it is ill formed or signals errors silently, end won't get highlighted.
;;; Example 3 (with xy instead of 23. also passing t and 'append.)
;;; if evaluated in the scratch buffer, it doesn't highlight xy in xy-xy
'(wxyz xy xy-xy end)
(progn
(font-lock-add-keywords nil
`(("\\bxy\\b"
(0 'success t))
"end")
'append)
(font-lock-fontify-buffer))
The fact that it does not in buffer *scratch* suggests that it is a problem with the current mode. There are two main possibilities:
What #wvcvw suggested: check what the syntax class of chars 2 and 3 is.
The font-lock-keywords already defined for the mode interact with your code -- e.g., they override it. Try adding 'APPEND as a third arg to font-lock-add-keywords. Try adding t as a HIGHLIGHT expression to your highlighter sexp (see the doc). That should let your highlighting override any that might already be there otherwise.
BTW, you say it does not work in a "text buffer", but what does that mean? From emacs -Q, evaluating your code in a buffer in text-mode shows that it does work. Investigate what your "text buffer" mode is and try the suggestions above (both bullets if necessary, but try the second one first).
I'm new to elisp, so please forgive me if the following approach is totally clumsy.
In the team I'm currently working with, there is an usual convention of closing python blocks with a pass statement (if they aren't ended by closing keywords like else or except or such). While unusual, this has the advantage that one can always recover the original indentation of the program if it is unintentionally changed (using emacs indent-region).
To get existing code in line with this convention, I wrote a small elisp function:
(defun python-check-indent ()
"Check if automatic indentation changes current indent, insert pass keyword if it does."
(interactive)
(move-beginning-of-line 1)
(skip-chars-forward " ")
(if
(< 0
(let (original)
(setq original (point))
(indent-for-tab-command)
(- (point) original)
)
)
(progn
(insert "pass")
(newline)
(indent-for-tab-command)
)
)
(next-line)
)
(global-set-key (kbd "C-`") 'python-check-indent)
The idea is simply to test whether hitting TAB would change the indentation, and insert a pass statement in that case. To facilitate processing longer blocks of code, it then advances to the next line.
When I run it using M-x python-check-indent, it does what I want (except that it moves around empty lines slightly), also when running it repeatedly to process several lines. However, when I run it repeatedly using the C-` keybinding, it starts messing up the code from the second invocation on.
So here are my questions: What is the difference between invoking a command with M-x ... and using its keybinding? And how could I change the function to be not affected by this difference?
emacs-version: GNU Emacs 23.3.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-03-10 on black.porkrind.org
(edit) current workaround: I'm now wrapping it inside a keyboard-macro, so it's "bound" to C-x e, and behaves properly.
The general rule is that it is best to avoid complex interactive
commands in your functions because they could be affected by all sorts
of options.
(defun python-check-indent ()
"Check if automatic indentation changes current indent, insert pass keyword if it does."
(interactive)
(goto-char (line-beginning-position))
(skip-chars-forward " ")
(when (< 0
(let (original)
(setq original (point))
(python-indent-line)
(- (point) original)))
(insert "pass\n")
(python-indent-line))
(forward-line))
However, even this is probably not good because python-indent-line's behavior depends on last-command and python-indent-trigger-commands. I think it would be best if you replaced the first invocation of python-indent-line with the code which computes the target indentation instead of actually indenting, something like (nth python-indent-current-level python-indent-levels).
PS. If you still have problems, I suggest that you use edebug and step through the function.
I'm using GNU Emacs 23.3 on Windows. I work in a very large codebase for which I generate a TAGS file (using the etags binary supplied with Emacs). The TAGS file is quite large (usually hovers around 100MB). I rarely need to use any functionality beyond find-tag, but there are times when I wish I could do completion out of the TAGS table.
Calling complete-tag causes Emacs to make a completion table automatically. The process takes quite a bit of time, but my problem isn't in the amount of time it takes, but rather the fact that right at the end (around 100% completion), I get a stack overflow (sorry about the unprintable chars):
Debugger entered--Lisp error: (error "Stack overflow in regexp matcher")
re-search-forward("^\\(\\([^]+[^-a-zA-Z0-9_+*$:]+\\)?\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:]*\\)\\(\\([^\n]+\\)\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n" nil t)
etags-tags-completion-table()
byte-code(...)
tags-completion-table()
Has anyone else run into this? Know of a way to work around it?
EDIT: Stack output after turning on debug-on-error
EDIT: Removed stack, since I now know what the failing entries look like:
^L
c:\path\to\some\header.h,0
^L
c:\path\to\some\otherheader.h,0
My tags file contains quite a few entries in this format. Looking at the headers involved, it's clear that they couldn't be correctly parsed by etags. This is fine, but I'm surprised that tags-completion-table doesn't account for this format in its regex. For reference, here's what a real entry looks like:
^L
c:\path\to\some\validheader.h,115
class CSomeClass ^?12,345
bool SomeMethod(^?CSomeClass::SomeMethod^A67,890
The regexp in question is used to match a tag entry inside the TAGS file. I guess that the error can occur if the file is incorrectly formatted (e.g. using non-native line-endings), or if an entry simply is really, really large. (An entry is typically a line or two, which should not be a problem for the regexp matcher.)
One way of tracking down the problem is go to the TAGS buffer and see where the point (cursor) is, after the error has occurred. Once you know which function it is, and you could live without tags for it, you could simply avoid generating TAGS entries for it.
If the problem is due to too complex entry, I would suggest that you should send bug report to the Emacs team.
If you load the tags table (open the TAGS table with Emacs, then bury-buffer), try M-x dabbrev-expand (bound to M-/). If the present prefix is very common, you might end up running through many possible completions before reaching the desired one.
I don't use Windows, but on the Mac and Linux machines I use, I have not faced this issue.
This looks like a bug in Emacs, see:
https://groups.google.com/d/msg/gnu.emacs.help/Ew0sTxk0C-g/YsTPVEKTBAAJ
https://debbugs.gnu.org/db/20/20703.html
I have applied the suggested patch to etags-tags-completion-table (copied below in completeness for your convenience) and trapped an error case.
I'm triggering the error in an extremely long line of code (46,000 characters!). I presume somebody programmatically generated the line and pasted it into the source. A workaround could be to simply filter such lines at the ctag building or loading stage, just something that deletes "long" lines, whatever that may mean. Probably 500 characters is long enough!
I could also look at adding maximum sizes to my regexes in ctags, but that really isn't a general solution because many ctags patterns do not have such limits.
(defun etags-tags-completion-table () ; Doc string?
(let ((table (make-vector 511 0))
(progress-reporter
(make-progress-reporter
(format "Making tags completion table for %s..." buffer-file-name)
(point-min) (point-max))))
(save-excursion
(goto-char (point-min))
;; This monster regexp matches an etags tag line.
;; \1 is the string to match;
;; \2 is not interesting;
;; \3 is the guessed tag name; XXX guess should be better eg DEFUN
;; \4 is not interesting;
;; \5 is the explicitly-specified tag name.
;; \6 is the line to start searching at;
;; \7 is the char to start searching at.
(condition-case err
(while (re-search-forward
"^\\(\\([^\177]+[^-a-zA-Z0-9_+*$:\177]+\\)?\
\\([-a-zA-Z0-9_+*$?:]+\\)[^-a-zA-Z0-9_+*$?:\177]*\\)\177\
\\(\\([^\n\001]+\\)\001\\)?\\([0-9]+\\)?,\\([0-9]+\\)?\n"
nil t)
(intern (prog1 (if (match-beginning 5)
;; There is an explicit tag name.
(buffer-substring (match-beginning 5) (match-end 5))
;; No explicit tag name. Best guess.
(buffer-substring (match-beginning 3) (match-end 3)))
(progress-reporter-update progress-reporter (point)))
table))
(error
(message "error happened near %d" (point))
(error (error-message-string err)))))
table))
I would like to translate the following function from vim script to emacs elisp (I use it to set the email recipients when writing emails).
My question is mainly how to get and set line contents in emacs, because with quick googling I could not find this out (probably I just did not know the right terms to google for, "getline" and "setline" in any case did show any results).
function! G_set_to()
let address = system('my-address-script') "shell command to choose addresses
let line = getline (2)
if strlen(line) == 4
call setline(2, line . address)
else
call setline(2, line . "; " . address)
endif
endfunction
Sorry if the answer is obvious, I am am completely new to emacs and don't even know how to use its in-built help system.
Cheers
Arian
Give this a shot, obviously customizing the variable G-address-script to suit your needs.
(require 'sendmail)
(defvar G-address-script "echo hi#google.com")
(defun G-set-to ()
"execute script in G-address-script and populate the To: line with the results"
(interactive)
(save-excursion
(mail-to)
(unless (= (current-column) 4)
(insert "; "))
(insert (shell-command-to-string G-address-script))
(when (looking-at "^$") ; when shell command has extra newline, delete it
(delete-backward-char 1))))
As far as using the help, there's a reasonable introduction to Emacs lisp here. But the quick intro is:
C-h i (that's control-h then i to see the info pages, there is one for Emacs and one for Emacs Lisp.
M-x apropos searches for terms
C-h f gives you help on a function
C-h v gives you help on a variable
In the *scratch* buffer, C-j will evaluate the expression right before the point (cursor)
M-x edebug-defun when the point is in a emacs lisp function will turn the debugger on, and the next time a function is run you'll step through it (M-x eval-defun in the function will turn the debugger off)
M-x eldoc-mode will turn on automatic documentation for emacs lisp functions and variables as you type them, read more here.
I took Trey's code and changed a few things and now it seems to work:
(defvar G-address-script "goobook_dmenu_with_cache")
(defun G-set-to ()
"execute script in G-address-script and populate the To: line with the results"
(interactive)
(save-excursion
(goto-line 2)
(re-search-forward "$")
(unless (= (current-column) 4)
(insert "; "))
(insert (shell-command-to-string G-address-script))))
Some remaining questions:
The bit where Trey's code checks if the string returned from G-address-script is empty doesn't work at the moment, what do I have to change?
Is there really no function to get the content of a specified line as a string?
Is there a better/more elegant way to do this? The vim script solution looks so much simpler, surely I am missing something.
Anyway, I'll mark this as solved in a day or so if there are no more answers as Trey solution basically does what I wanted. Thank you Trey!
I've been randomly getting the following error in emacs:
Variable binding depth exceeds max-specpdl-size
...and I've been getting it at very random moments. After researching this, it seems as though some elisp somewhere is recursing too deeply. Are there any strategies for tracking this down? I'm totally at a loss as far as what is actually causing this.
I've gotten some errors indicating something along the lines of infinite recursion with ropemacs (but these are usually Python errors). Could something be misconfigured with ropemacs?
Update: Interestingly enough, I've found that I always get this error if I do a "C-h a" for "speedbar" but not for "rope-".
To track the problem down, you can try this:
(setq max-specpdl-size 5) ; default is 1000, reduce the backtrace level
(setq debug-on-error t) ; now you should get a backtrace
C-h a ; in speedbar
You should get a backtrace upon the error, and at that point, you can track down the offending routine.
I'd also try loading emacs w/out your configuration file (emacs -q), to see if there's something in your .emacs that is affecting things. (I don't get the infinite loop using C-h a). And if it is your .emacs, then the best way I've found to track that down is either binary search (put an error (error "frog") or somesuch in the middle of your .emacs, load, test, if no problems, put the error at 3/4, otherwise at 1/4, repeat...), or manually evaluate your .emacs line by line (region by region), testing after each portion. Those settings should help.
For me too it did not work. I found with C-h+v that actually max-specpdl-size was not changed to 5 at all by the setq. I then tried to set it interactively with M-x set-variable. That too did not change its value. Finally I managed to set it with M-x customize-variable.
Btw, on my system max-specpdl-size was 140 and thus to small. I had to increase it to 1000, not in order to get a backtrace and debug it, but to make it work.
The kind of bug still exists 10 years after the report, in XEmacs 21.4 (patch 24) "Standard C" [Lucid] (x86_64-linux-gnu, Mule). I get it from M-x vm (trying to read my e-mail, which I do many times every day).
Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
signal(error ("Variable binding depth exceeds max-specpdl-size"))
byte-code("..." [buf data kill-buffer signal] 3)
find-file-noselect("/home/brech/mail/folders/INBOX")
byte-code("..." [f full-startup access-method remote-spec buffer-file-coding-system folder string-match imap pop bufferp nil vm-pop-find-spec-for-name error "No such POP folder: %s" vm-pop-make-filename-for-spec t file-exists-p (rename-file f-pass f-nospec) ((error)) (rename-file f-nopass f-nospec) ((error)) 3 vm-imap-parse-spec-to-list vm-imap-make-filename-for-spec expand-file-name file-directory-p "%s is a directory" vm-get-file-buffer no-conversion raw-text message "Reading %s..." find-file-noselect "Reading %s... done" (pop imap) buffer-name rename-buffer set-buffer-multibyte get-coding-system no-conversion-unix no-conversion-dos no-conversion-mac binary buffer-modified-p ((set-buffer-modified-p omodified)) encode-coding-region set-buffer-file-coding-system decode-coding-region coding-system-base raw-text-unix ...] 9)
ad-Orig-vm(nil nil nil)
(setq ad-return-value (ad-Orig-vm folder read-only access-method))
(let (ad-return-value) (if (and ... mail-archive-file-name folder ... ...) (setq read-only ...)) (setq ad-return-value (ad-Orig-vm folder read-only access-method)) ad-return-value)
(lambda (&optional folder read-only access-method) "$ad-doc: vm$" (interactive (list nil current-prefix-arg)) (let (ad-return-value) (if ... ...) (setq ad-return-value ...) ad-return-value))(nil nil)
call-interactively(vm)
command-execute(vm t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
A crude work-around is quitting XEmacs and starting all over. Only quitting and re-starting vm does not help.