Rob Browning wrote: > Peter S Galbraith <[EMAIL PROTECTED]> writes: > > > What is the intent behind running `load-file' if debug-on-error > > is true? `load-file' differs from `load' in that it does not > > search the load-path; the full file path must be specified, which > > is not the case here. > > > > If others agree, I'll file a bug report against emacsen-common. > > > > It shouldn't be an issue, except that the emacs21 prerelease I > > have always thinks debug-on-error is true even when it isn't and > > I always get the following error when running: > > Though I don't know that we shouldn't change it, I'm wondering why I > didn't have any problems when building/running emacs21. I haven't > changed emacsen-common yet, but it doesn't appear to have been a > problem. ?
It turns out that I stumbled on this quite by accident... I originally thought that the following was enough to setup Debian elisp addons on an unpackaged emacs21: (add-to-list 'load-path "/usr/share/emacs/site-lisp/") (load "debian-startup") (debian-startup 'emacs) It turns out that I needed to defconst debian-emacs-flavor first. Without it, `(debian-startup 'emacs)` would run but exit early without actually setting stuff up. So I ran it by hand, e.g. : M-: (debian-startup 'emacs) And _this_ lead to the error on load-file because of an emacs21 (mis-)feature (from NEWS): *** The commands to evaluate Lisp expressions, such as C-M-x in Lisp modes, C-j in Lisp Interaction mode, and M-:, now bind the variables print-level, print-length, and debug-on-error based on the new customizable variables eval-expression-print-level, eval-expression-print-length, and eval-expression-debug-on-error. So debug-on-error evaluates to `t even when it's unset. - Any timeline for an emacs21 package? (We certainly need it by the time woody freezes). Peter
