From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?SmFyb3PFgmF3IFJ6ZXN6w7N0a28=?= Newsgroups: gmane.emacs.devel Subject: Re: Making debugging possible on expressions executed from ielm Date: Tue, 16 Jan 2018 07:42:57 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113bddf48faa800562df0a31" X-Trace: blaine.gmane.org 1516084905 28921 195.159.176.226 (16 Jan 2018 06:41:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 Jan 2018 06:41:45 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 16 07:41:40 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebKwF-000795-09 for ged-emacs-devel@m.gmane.org; Tue, 16 Jan 2018 07:41:39 +0100 Original-Received: from localhost ([::1]:42024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebKyE-0006H8-Ht for ged-emacs-devel@m.gmane.org; Tue, 16 Jan 2018 01:43:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebKxY-0006Gr-Bl for emacs-devel@gnu.org; Tue, 16 Jan 2018 01:43:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebKxW-0007be-Rm for emacs-devel@gnu.org; Tue, 16 Jan 2018 01:43:00 -0500 Original-Received: from mail-yb0-x232.google.com ([2607:f8b0:4002:c09::232]:33932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ebKxW-0007bV-KA for emacs-devel@gnu.org; Tue, 16 Jan 2018 01:42:58 -0500 Original-Received: by mail-yb0-x232.google.com with SMTP id u35so571035ybi.1 for ; Mon, 15 Jan 2018 22:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nv+liv3EMvakcHhEXFDMN0x30HiBtYhQImYjdomOrXw=; b=OYq32JxG6KmnD0H7vGjQCnjk/QIQl+bIym+MEefk+Sbcw9Bjg+A0uG9bCJXdhJAd8X w3uPMTi8DUSwquKO8CycZoN+fnh+EOoAjln236SEGtYnqxS4pmPdH5lSVbIC4KqlYd9S D289sCmtibKVNUXq6F6pNba64IUMpQbn6CK0kfByUZdLin7wuDxMb/C5YAboYvJKAs7w rLkcsOvnluQYul9YJEYW+aZdPUFXeLomXTfOb0g2acnokaFqiJ09K0uGwHwc/a+BUPx7 p67+dodVlX2QrUxamC+QPXMPRieN76/kP335kbIs8CBMIumIIdgmKW49gG6+mUm1TBbv 4dPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nv+liv3EMvakcHhEXFDMN0x30HiBtYhQImYjdomOrXw=; b=rVi1l5/GwFiezPlbwbhWZenLPNq//t585VBXNj7zmsspLs/557e/DEGmtZUUrMvG3o Spq56F3lwMpOdbjcXPUXB4o+jvL+Zv1cK0r3Mkl6roZ81xFx+ih7sVjPuvcLHJ0XyZcJ Wsxeh+tpD8susvzpJcQZdz3RE+L/JrP0EQGzvH9fODC9twe+XeKvK1I2oBExbRmmojnN vRslMuQJvuOEt38TdxzG8XlojxVY9LJHabKbiv8rZ8+VxW7PjAP6lysJ8hwoZ63hk1Ik G/vHjmKUhj3mu8SrmiCzW3kKL3WKjtwMnl92pfFa0mB7pcIEmvEz910kOgbSdrCWqS9k TPBQ== X-Gm-Message-State: AKwxytdBjjrKCLDpE3UGlnRumcFyWr8jKIW4G6lyChFCJbNzIybJn+sU nH7mH+vLVZ62F2BpwrE3r1cijmp7wG/f0kNkBnuwaQ== X-Google-Smtp-Source: ACJfBovJV2LXv2Lc2GiagYEYWEonyiWugrAiblgkdDHvc9j8/ormLmIL/94qxKHAZS6Qk2Fgl9oVrhfNBds7I8QJXyw= X-Received: by 10.37.77.6 with SMTP id a6mr9936899ybb.410.1516084977967; Mon, 15 Jan 2018 22:42:57 -0800 (PST) Original-Received: by 10.37.9.17 with HTTP; Mon, 15 Jan 2018 22:42:57 -0800 (PST) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4002:c09::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:222002 Archived-At: --001a113bddf48faa800562df0a31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 15, 2018 at 10:59 PM, Stefan Monnier wrote: > > I did not know about condition-case-unless-debug, it indeed does make > > debugging possible with a simpler change and without any side effects. > > I attach the patch. > > Have you verified that IELM stays usable after such an error? > In the tests I was able to invent, yes. If you press c from the debugger to continue execution the IELM error message and a new prompt appear as usually, and evaluating new expressions in IELM still works fine. I was mostly interested in seeing the stack trace in the debugger, and I am not a power user of the Emacs debugger, but I did also try evaluating some expressions from the debugger, stepping through etc., it all seemed to work fine. You do see all the ielm internal functions in the stack trace, with the stack trace of your expression on top. This is no different from e.g. evaluating an expression with M-: though, where you also enter the debugger in the context of some Emacs internals. I tried to find some trace in the version control history of why the limitation of not respecting debug-on-error could possibly be there, I did not find anything though. The comment about not respecting debug-on-error and debug-on-quit is in ielm.el from 1994: https://github.com/emacs-mirror/emacs/commit/813f532d2f0d18dcda7d93be2c6cd8= 41815ff8b8#diff-63abff285057c34e375ed9bb9f2f0199R302 > Are all 3 hunks necessary? > The middle one is the most important as it covers evaluation of the form that was read in. However in the other two cases, of an read error and a pretty printing error, IELM also will show an error before emitting next prompt, and I think you plausibly could be willing to debug the error, or at least examine the stack trace. I was giving some thought to having ielm-debug-on-error and ielm-debug-on-quit variables, initializing them to debug-on-error and debug-on-quit default values, and having the ielm-* versions take precedence, so that you can customize ielm to behave differently than the rest of Emacs. Personally though I think it only would make sense if there were some pitfalls or quirks in debugging from IELM, and right now I don't see any. Cheers, Jaros=C5=82aw Rzesz=C3=B3tko --001a113bddf48faa800562df0a31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jan 15, 2018 at 10:59 PM, Stefan Monnier <monnier@iro.umontrea= l.ca> wrote:
> I did not know about condition-case-unless= -debug, it indeed does make
> debugging possible with a simpler change and without any side effects.=
> I attach the patch.

Have you verified that IELM stays usable after such an error?

In the tests I was able to invent, yes. If yo= u press c from the debugger to continue execution the IELM error message an= d a new prompt appear as usually, and evaluating new expressions in IELM st= ill works fine. I was mostly interested in seeing the stack trace in the de= bugger, and I am not a power user of the Emacs debugger, but I did also try= evaluating some expressions from the debugger, stepping through etc., it a= ll seemed to work fine. You do see all the ielm internal functions in the s= tack trace, with the stack trace of your expression on top. This is no diff= erent from e.g. evaluating an expression with M-: though, where you also en= ter the debugger in the context of some Emacs internals.=C2=A0

I tried to find some trace in the version control history = of why the limitation of not respecting debug-on-error could possibly be th= ere, I did not find anything though. The comment about not respecting debug= -on-error and debug-on-quit is in ielm.el from 1994:

https:/= /github.com/emacs-mirror/emacs/commit/813f532d2f0d18dcda7d93be2c6cd841815ff= 8b8#diff-63abff285057c34e375ed9bb9f2f0199R302
=C2=A0
Are all 3 hunks necessary?

The middle o= ne is the most important as it covers evaluation of the form that was read = in. However in the other two cases, of an read error and a pretty printing = error, IELM also will show an error before emitting next prompt, and I thin= k you plausibly could be willing to debug the error, or at least examine th= e stack trace.

I was giving some thought to having= ielm-debug-on-error and ielm-debug-on-quit variables, initializing them to= debug-on-error and debug-on-quit default values, and having the ielm-* ver= sions take precedence, so that you can customize ielm to behave differently= than the rest of Emacs. Personally though I think it only would make sense= if there were some pitfalls or quirks in debugging from IELM, and right no= w I don't see any.

Cheers,
Jaros=C5= =82aw Rzesz=C3=B3tko
--001a113bddf48faa800562df0a31--