Nick Dokos <nicholas.do...@hp.com> writes: > Nick Dokos <nicholas.do...@hp.com> wrote: > >> Eric Abrahamsen <e...@ericabrahamsen.net> wrote: >> >> > It was while trying to produce a backtrace (with edebug) that I >> > discovered that re-evaluating the code fixed the problem. I set >> > debug-on-error to t and reproduced the error, which gave me this: >> > >> > Debugger entered--Lisp error: (error "Cannot return from the debugger in >> > an error") >> > internal-temp-output-buffer-show(#<buffer *Org Export/Publishing Help*>) >> > org-export(nil) >> > call-interactively(org-export nil nil) >> > >> > Presumably this isn't really what's needed -- can you provide a pointer >> > to producing a more useful backtrace? >> > >> >> Only the usual suspects: you are loading uncompiled code I hope? I don't >> even have the function in either of my emacsen (24.0.50 and 23.1.1): >> does C-h f internal-temp-output-buffer-show RET show anything in yours? >> > > I see some messages about internal-temp-output-buffer-show when > googling: they seem related to Stefan Monnier's effort to make > with-output-to-temp-buffer a Lisp macro (rather than a special form in C > code, IIUC) - but this seems to be bleeding edge stuff, not 23.2. Are > you perhaps picking up emacs bits and pieces from places you shouldn't? > > Maybe Stefan (cc:ed) has some ideas. > > Nick
Aha, I did once try building emacs 24 on this machine, for the heck of it, and it's still hanging around under /usr/local/bin. I'm not sure how much work would be required to uproot it entirely, but I can give it a shot, particularly with the lisp libraries, and see if that makes a difference. Thanks for the hint, Eric
