Re: proposal to make null string handling more emacs-y

[Thien-Thi Nguyen]

() Miles Bader <address@hidden>
() Fri, 27 Apr 2012 13:24:05 +0900

   To the extent his complaint is valid,
   it's a general issue, not a "startup issue."

   Moreover, if Emacs is clumsy at handling errors during startup
   (and I agree that it is), that's a problem that should be
   addressed generally in the startup mechanism, not by bandaids
   on only vaguely related areas.

   In other words, these these things look largely orthogonal.

   [If this particular bandaid were harmless maybe it should be
   added anyway, as a stop-gap to a more proper solution -- but it
   isn't harmless, at least when applied generally; in certain
   cases, it may be, of course.]

I have always longed for ‘load-in-progress’ to be, instead of a
simple boolean, a counter of top-level forms (from a particular
file/buffer).  This light-weight mechanism could speed debugging
by providing more specific information:

ok:
An error occurred while loading `/home/ttn/.emacs':

better:
An error occurred while loading `/home/ttn/.emacs' (Nth form):

This could be used by the ‘--debug-init’ machinery, as well.  On
second thought (after glancing at lread.c ‘readevalloop’), even
more direct would be simply to record the "position of the current
top-level form".  From *Backtrace* (invoking with ‘--debug-init’),
evaluating expression:

(with-current-buffer " *load*" (point))

yields related information, the "position just past the current
top-level form", so i suppose everything can be done in Lisp, by
providing:

(with-current-buffer " *load*"
  (save-excursion (forward-sexp -1) (point)))

in some non-expert-friendly way, after which, we can banish the
laconic "bisect ~/.emacs" to the /second/ advised step (when the
user realizes that it is not the current top-level form or its
progeny that is the Real Problem, but some bad interaction between
those and the other loosely-included cargo-cult copy-pasta).  :-/

But hey, one step at a time...

[To reproduce the above observations, create file /tmp/bad with
contents "zorg", and add ‘(load-file "/tmp/bad")’ somewhere in
~/.emacs (or other init file).]

Hmm, i just noticed that *Backtrace* now (as of 2005-07-10)
displays the "just past" position for all frames, so i suppose to
boil down this long post into something constructive, how about:

 lisp/emacs-lisp/debug.el |   24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index b0813ae..bda05ac 100644
*** a/lisp/emacs-lisp/debug.el
--- b/lisp/emacs-lisp/debug.el
***************
*** 333,351 ****
                  (cdr debugger-args) debugger-args)
              (current-buffer))
       (insert ?\n)))
!   ;; After any frame that uses eval-buffer,
    ;; insert a line that states the buffer position it's reading at.
    (save-excursion
!     (let ((tem eval-buffer-list))
        (while (and tem
                  (re-search-forward "^  eval-\\(buffer\\|region\\)(" nil t))
        (end-of-line)
!       (insert (format "  ; Reading at buffer position %d"
                        ;; This will get the wrong result
                        ;; if there are two nested eval-region calls
                        ;; for the same buffer.  That's not a very useful case.
                        (with-current-buffer (car tem)
!                         (point))))
        (pop tem))))
    (debugger-make-xrefs))

--- 333,367 ----
                  (cdr debugger-args) debugger-args)
              (current-buffer))
       (insert ?\n)))
!   ;; After any frame that uses eval-buffer, for `read'-related error,
    ;; insert a line that states the buffer position it's reading at.
+   ;; For other errors, state the buffer position of the offending form.
    (save-excursion
!     (let ((tem eval-buffer-list)
!           (read-related-error-p
!            (and
!             ;; A `read'-related error, if any, is always singular and 
innermost.
!             (eq 'error (car debugger-args))
!             (memq (car (cadr debugger-args))
!                   ;; This is from grep xsignal1 lread.c -- is that OK?
!                   '(end-of-file
!                     invalid-read-syntax
!                     overflow-error)))))
        (while (and tem
                  (re-search-forward "^  eval-\\(buffer\\|region\\)(" nil t))
        (end-of-line)
!       (insert (format "  ; Reading%s at buffer position %d"
!                       (if read-related-error-p "" " form")
                        ;; This will get the wrong result
                        ;; if there are two nested eval-region calls
                        ;; for the same buffer.  That's not a very useful case.
                        (with-current-buffer (car tem)
!                         (if read-related-error-p
!                               (point)
!                             (save-excursion
!                               (forward-sexp -1)
!                               (point))))))
!         (setq read-related-error-p nil)
        (pop tem))))
    (debugger-make-xrefs))

This distinguishes between ‘read’-related and other errors, but
i'm unsure if the way of discernment is correct.  (Too, it could
be reworked to use ‘pcase’...)