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: Mon, 15 Jan 2018 20:22:48 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="001a114739902f12aa0562d58a9a" X-Trace: blaine.gmane.org 1516044068 29369 195.159.176.226 (15 Jan 2018 19:21:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 19:21:08 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 15 20:21:04 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 1ebAJU-0006pW-Vt for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 20:20:57 +0100 Original-Received: from localhost ([::1]:56741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebALU-0000Gl-TZ for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 14:23:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebALL-0000Fj-Q8 for emacs-devel@gnu.org; Mon, 15 Jan 2018 14:22:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebALK-0003US-Gz for emacs-devel@gnu.org; Mon, 15 Jan 2018 14:22:51 -0500 Original-Received: from mail-yw0-x22a.google.com ([2607:f8b0:4002:c05::22a]:46245) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ebALK-0003TM-9V for emacs-devel@gnu.org; Mon, 15 Jan 2018 14:22:50 -0500 Original-Received: by mail-yw0-x22a.google.com with SMTP id c78so5809222ywb.13 for ; Mon, 15 Jan 2018 11:22:50 -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; bh=d1mmWvv3s7qvULGR7ApXErfkHMMhTuAZRB1Kd/e6GYk=; b=fVEoRaGuhcGmJyHINDJQF3smFLV1zQRdysorEDa5KIYltmZQnkg/sd1W6Yxa05geMF yhEHy085kSLvlFDXjcCjxvvAFG5DpDyD/92ytVhQzKDbdnBDWJY1fMmSHhs18/u8LzLF DyzkGxX7vggUuOh8OZUIZjOjPDKlfvi2WQr8douxpOusxi9L6UZEREvDFLid/ozh5rOG aFxocOLu2pQmH9sDQulGCtekDbi/LMGtwx0RNzlkvIBAAz+gHSaqI+0EYvkZNjVg4YKJ H4HJ8H1yRRQ1f8OrZTfC0A6xkqlPgq6E9mVSMyu8Vuuc6i/s69phR2WrmLFZNqd//ESa yHDw== 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; bh=d1mmWvv3s7qvULGR7ApXErfkHMMhTuAZRB1Kd/e6GYk=; b=Lb465iNP6chmp0/LU7Z1jqKgqHQAuk02tWZrBkPaAFPlXwuYFF4fWCGVWmhdr5gUqy Jd1BIeiROhAOGYIrsf4TBbiq45uBFrfVck1Ynm3Jd7U+lSRym4denknyFHeGtcPtMJw2 JDnJn2uP0Wq4702hSdAKlJptIwNJ3OdUU4zc+IyPoV19R9W15+YUr8gOTsHa0DktZLYm tGlMZ37auwH93f5CgrbeCEQYPXlWpDMOBxBSmKDflWHr4+o/zci5ky8vCPM2e25nq2x1 Ju7oXt66ZuJtXlTNwx9MAKrERSNDeio2VbFidmlLgUEQvvtNVkEaIoMrdkwET3/7OTi8 BzJA== X-Gm-Message-State: AKGB3mLXae+ee7U8iorhG0FWO7D2c4BP4Lonkq9XMpe54G4zek3t5UVk egeH5HuYUEpGoVNYggJkbYcNwdj3ZZibQAXHcqg= X-Google-Smtp-Source: ACJfBoubhrO3tESKjqQfzC43fWmHHlYfI/mYeGDoJ5VZ+Ea8JDc65NWf1GYgif3VDddAa4n+QprxK0rf2omC9j7AUxw= X-Received: by 10.129.116.8 with SMTP id p8mr22814669ywc.386.1516044169438; Mon, 15 Jan 2018 11:22:49 -0800 (PST) Original-Received: by 10.37.205.71 with HTTP; Mon, 15 Jan 2018 11:22:48 -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:c05::22a 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:221982 Archived-At: --001a114739902f12aa0562d58a9a Content-Type: multipart/alternative; boundary="001a114739902f12a50562d58a98" --001a114739902f12a50562d58a98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stefan, 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. Cheers, Jaros=C5=82aw Rzesz=C3=B3tko On Sat, Jan 13, 2018 at 10:22 AM, Jaros=C5=82aw Rzesz=C3=B3tko wrote: > I attach a patch for ielm.el that makes it possible to enter the debugger > when executing expressions in ielm, and that makes ielm respect the > debug-on-error and debug-on-exit flags. > > I guess that possibly the reason that was not originally done is that it > is not obvious how to restore ielm to a usable state after the debugger h= as > been entered. My patch makes use of the fact that unwind-protect unwind > forms are still executed when user resumes execution from the debugger > after an error. > > Without the patch, ielm wraps the evaluation of the expression given by > the user in a condition case, and in case of an error, or exit, displays = an > appropriate message in its buffer, right under the evaluated expression, > regardless of debug-on-error and debug-on-exit. > > With the patch, the message that ielm displays in its buffer will be a > generic error message regardless if there was an error in the evaluated > form, or a quit. However: > > - if debug-on-error is t, emacs will enter the debugger and show a stack > trace, just like with almost any other evaluation method. When the user > continues the execution from the debugger, ielm will correctly resume > execution > > - if debug-on-error is nil, emacs will display the specific error in the > minibuffer anyway > > Similar things are true for debug-on-quit. > > I think this is an improvement over the current state of affairs. Of > course ideally I would like to preserve the "nice" message in ielm buffer > and make the improvements I made, but emacs does not seem to make it > possible to do some handling of an error and then to re-raise it while > preserving the original stack trace. > > Cheers, > Jaros=C5=82aw Rzesz=C3=B3tko > > > --001a114739902f12a50562d58a98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stefan,

I did not know about cond= ition-case-unless-debug, it indeed does make debugging possible with a simp= ler change and without any side effects. I attach the patch.

=
Cheers,
Jaros=C5=82aw Rzesz=C3=B3tko

On Sat, Jan 13, 2018 at 10:= 22 AM, Jaros=C5=82aw Rzesz=C3=B3tko <jrzeszotko@gmail.com> wrote:
I attach a patc= h for ielm.el that makes it possible to enter the debugger when executing e= xpressions in ielm, and that makes ielm respect the debug-on-error and debu= g-on-exit flags.=C2=A0

I guess that possibly the reason = that was not originally done is that it is not obvious how to restore ielm = to a usable state after the debugger has been entered. My patch makes use o= f the fact that unwind-protect unwind forms are still executed when user re= sumes execution from the debugger after an error.

<= /div>
Without the patch, ielm wraps the evaluation of the expression gi= ven by the user in a condition case, and in case of an error, or exit, disp= lays an appropriate message in its buffer, right under the evaluated expres= sion, regardless of debug-on-error and debug-on-exit.=C2=A0

<= /div>
With the patch, the message that ielm displays in its buffer will= be a generic error message=C2=A0 regardless if there was an error in the e= valuated form, or a quit. However:

- if debug-on-e= rror is t, emacs will enter the debugger and show a stack trace, just like = with almost any other evaluation method. When the user continues the execut= ion from the debugger, ielm will correctly resume execution

<= /div>
- if debug-on-error is nil, emacs will display the specific error= in the minibuffer anyway

Similar things are true = for debug-on-quit.

I think this is an improvement = over the current state of affairs. Of course ideally I would like to preser= ve the "nice" message in ielm buffer and make the improvements I = made, but emacs does not seem to make it possible to do some handling of an= error and then to re-raise it while preserving the original stack trace.

Cheers,
Jaros=C5=82aw Rzesz=C3=B3tko



--001a114739902f12a50562d58a98-- --001a114739902f12aa0562d58a9a Content-Type: text/plain; charset="US-ASCII"; name="ielm-with-debugger.el.diff" Content-Disposition: attachment; filename="ielm-with-debugger.el.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jcgliji61 ZGlmZiAtLWdpdCBhL2xpc3AvaWVsbS5lbCBiL2xpc3AvaWVsbS5lbAppbmRleCBmYjI4NWU4MGY2 Li4zMGQ2NTE1ZTY5IDEwMDY0NAotLS0gYS9saXNwL2llbG0uZWwKKysrIGIvbGlzcC9pZWxtLmVs CkBAIC0zNTQsNyArMzU0LDcgQEAgbm9uZW1wdHksIHRoZW4gZmx1c2hlcyB0aGUgYnVmZmVyLiIK ICAgICAgICAgKHdidWYgaWVsbS13b3JraW5nLWJ1ZmZlcikgICA7IGN1cnJlbnQgYnVmZmVyIGFm dGVyIGV2YWx1YXRpb24KICAgICAgICAgKHBtYXJrIChpZWxtLXBtKSkpCiAgICAgKHVubGVzcyAo aWVsbS1pcy13aGl0ZXNwYWNlLW9yLWNvbW1lbnQgc3RyaW5nKQotICAgICAgKGNvbmRpdGlvbi1j YXNlIGVycgorICAgICAgKGNvbmRpdGlvbi1jYXNlLXVubGVzcy1kZWJ1ZyBlcnIKICAgICAgICAg ICAobGV0ICgocm91dCAocmVhZC1mcm9tLXN0cmluZyBzdHJpbmcpKSkKICAgICAgICAgICAgIChz ZXRxIGZvcm0gKGNhciByb3V0KQogICAgICAgICAgICAgICAgICAgcG9zIChjZHIgcm91dCkpKQpA QCAtMzg0LDcgKzM4NCw3IEBAIG5vbmVtcHR5LCB0aGVuIGZsdXNoZXMgdGhlIGJ1ZmZlci4iCiAg ICAgICAgICAgICAgICAgKHNldC1tYXRjaC1kYXRhIGllbG0tbWF0Y2gtZGF0YSkKICAgICAgICAg ICAgICAgICAoc2F2ZS1leGN1cnNpb24KICAgICAgICAgICAgICAgICAgICh3aXRoLXRlbXAtYnVm ZmVyCi0gICAgICAgICAgICAgICAgICAgIChjb25kaXRpb24tY2FzZSBlcnIKKyAgICAgICAgICAg ICAgICAgICAgKGNvbmRpdGlvbi1jYXNlLXVubGVzcy1kZWJ1ZyBlcnIKICAgICAgICAgICAgICAg ICAgICAgICAgICh1bndpbmQtcHJvdGVjdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7 IFRoZSBuZXh0IGxldCBmb3JtIGNyZWF0ZXMgZGVmYXVsdAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDs7IGJpbmRpbmdzIGZvciAqLCAqKiBhbmQgKioqLiAgQnV0CkBAIC00MzYsNyArNDM2 LDcgQEAgbm9uZW1wdHksIHRoZW4gZmx1c2hlcyB0aGUgYnVmZmVyLiIKIAogICAgICAgKGdvdG8t Y2hhciBwbWFyaykKICAgICAgICh1bmxlc3MgZXJyb3ItdHlwZQotICAgICAgICAoY29uZGl0aW9u LWNhc2UgbmlsCisgICAgICAgIChjb25kaXRpb24tY2FzZS11bmxlc3MtZGVidWcgbmlsCiAgICAg ICAgICAgICA7OyBTZWxmLXJlZmVyZW50aWFsIG9iamVjdHMgY2F1c2UgbG9vcHMgaW4gdGhlIHBy aW50ZXIsIHNvCiAgICAgICAgICAgICA7OyB0cmFwIHF1aXRzIGhlcmUuIE1heSBhcyB3ZWxsIGRv IGVycm9ycywgdG9vCiAgICAgICAgICAgICAodW5sZXNzIGZvci1lZmZlY3QKQEAgLTUxNyw5ICs1 MTcsNiBAQCBjYXVzZXMgb3V0cHV0IHRvIGJlIGRpcmVjdGVkIHRvIHRoZSBpZWxtIGJ1ZmZlci4K IHNldCB0byBhIGRpZmZlcmVudCB2YWx1ZSBkdXJpbmcgZXZhbHVhdGlvbi4gIFlvdSBjYW4gdXNl IChwcmluYwogVkFMVUUpIG9yIChwcCBWQUxVRSkgdG8gd3JpdGUgdG8gdGhlIGllbG0gYnVmZmVy LgogCi1FeHByZXNzaW9ucyBldmFsdWF0ZWQgYnkgSUVMTSBhcmUgbm90IHN1YmplY3QgdG8gYGRl YnVnLW9uLXF1aXQnIG9yCi1gZGVidWctb24tZXJyb3InLgotCiBUaGUgYmVoYXZpb3Igb2YgSUVM TSBtYXkgYmUgY3VzdG9taXplZCB3aXRoIHRoZSBmb2xsb3dpbmcgdmFyaWFibGVzOgogKiBUbyBz dG9wIGJlZXBpbmcgb24gZXJyb3IsIHNldCBgaWVsbS1ub2lzeScgdG8gbmlsLgogKiBJZiB5b3Ug ZG9uJ3QgbGlrZSB0aGUgcHJvbXB0LCB5b3UgY2FuIGNoYW5nZSBpdCBieSBzZXR0aW5nIGBpZWxt LXByb21wdCcuCg== --001a114739902f12aa0562d58a9a--