From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Fri, 27 Apr 2012 10:49:19 +0200 Message-ID: <87d36tblv4.fsf@gnuvola.org> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <87ty06nnxp.fsf@catnip.gol.com> <87vckmm2z7.fsf@catnip.gol.com> <87ehr9vp0r.fsf@destructor.i-did-not-set--mail-host-address--so-tickle-me> <87ehr9n8nh.fsf@catnip.gol.com> <87y5phu8o3.fsf@destructor.i-did-not-set--mail-host-address--so-tickle-me> <878vhhn6oq.fsf@catnip.gol.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: dough.gmane.org 1335516578 9449 80.91.229.3 (27 Apr 2012 08:49:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2012 08:49:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 10:49:36 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SNgrv-0004ol-EC for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 10:49:35 +0200 Original-Received: from localhost ([::1]:56936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNgru-0001MR-Su for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 04:49:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNgrq-0001MG-I6 for emacs-devel@gnu.org; Fri, 27 Apr 2012 04:49:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNgrj-000365-Od for emacs-devel@gnu.org; Fri, 27 Apr 2012 04:49:29 -0400 Original-Received: from smtp207.alice.it ([82.57.200.103]:53891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNgrj-00032m-DB for emacs-devel@gnu.org; Fri, 27 Apr 2012 04:49:23 -0400 Original-Received: from ambire (87.13.1.249) by smtp207.alice.it (8.6.023.02) id 4F05A6650D005352 for emacs-devel@gnu.org; Fri, 27 Apr 2012 10:49:21 +0200 Original-Received: from ttn by ambire with local (Exim 4.72) (envelope-from ) id 1SNgrg-0001Kf-25 for emacs-devel@gnu.org; Fri, 27 Apr 2012 10:49:20 +0200 In-Reply-To: <878vhhn6oq.fsf@catnip.gol.com> (Miles Bader's message of "Fri, 27 Apr 2012 13:24:05 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.103 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150084 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Miles Bader () 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 =E2=80=98load-in-progress=E2=80=99 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 =E2=80=98--debug-init=E2=80=99 machinery, as well= . On second thought (after glancing at lread.c =E2=80=98readevalloop=E2=80=99), = even more direct would be simply to record the "position of the current top-level form". From *Backtrace* (invoking with =E2=80=98--debug-init=E2= =80=99), 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 =E2=80=98(load-file "/tmp/bad")=E2=80=99 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: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=debug.el.diff 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)) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This distinguishes between =E2=80=98read=E2=80=99-related and other errors,= but i'm unsure if the way of discernment is correct. (Too, it could be reworked to use =E2=80=98pcase=E2=80=99...) --=-=-=--