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: Fri, 19 Jan 2018 20:14:15 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11427d82ef9567056325e287" X-Trace: blaine.gmane.org 1516389166 19506 195.159.176.226 (19 Jan 2018 19:12:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 19:12:46 +0000 (UTC) To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 19 20:12:42 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 1ecc5P-0003jU-7g for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 20:12:23 +0100 Original-Received: from localhost ([::1]:39161 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecc7P-0007is-9y for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 14:14:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecc7H-0007iV-It for emacs-devel@gnu.org; Fri, 19 Jan 2018 14:14:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecc7G-0006QM-71 for emacs-devel@gnu.org; Fri, 19 Jan 2018 14:14:19 -0500 Original-Received: from mail-yb0-x230.google.com ([2607:f8b0:4002:c09::230]:44405) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ecc7G-0006PS-0i for emacs-devel@gnu.org; Fri, 19 Jan 2018 14:14:18 -0500 Original-Received: by mail-yb0-x230.google.com with SMTP id z90so985028ybh.11 for ; Fri, 19 Jan 2018 11:14:16 -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=+0W7BEAKnxeX0Y4AEYRhcfbW1GsQk2cHyVXqm9uNO34=; b=THHX46qcOade4T+xSS8dH75mj6yDTk32UAqnbk5mHp9P+bRTjUQnV/kkxk7T0k6TVA kVRgIO8L6DP3MTAygBS9LgrriCxz3a9paxh0saZurLHFp7f6TpHy8o1chkzOetCzrNvH XHvk0hiKdN4xxNe8gMjxNr7Cdp8V0XJG5BQ04DHdix0oXpoGTA2idVhVPstGegc94pO6 TpL49xOoZ83rk0+qY7KACVO6NZ0lBw+urc25fd4q0DIG9HbX9V8/Z37CNszueZcnG4CA Iqz4MH7nji6NS6F6qgjJeu+J8kxnKFYx3TQ+DyhvNgGZymooK6F8+RsTxFUfs20wW8LB URGg== 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=+0W7BEAKnxeX0Y4AEYRhcfbW1GsQk2cHyVXqm9uNO34=; b=NS7CEaS39ibXpdqGg5BHKehY4NqXNdfjVX4qnBX5uE0dmtulZnZO5XuwvXlge44PUt iVcKGqEPF6baVlgszf5X9kIlEpdAu6k3XTURvdUNPJV7aMwnQvjLXS6GVu1pxuaytp2U Ny3MpSGLyhZzrkn/0CJSEr33sZLr8SekGg6uBhtndHA9CTPbmfpxVYlWdSnZY56cXR8q 5tQk0rEBAu18UkCA/WDOvX22FVe9JvzXX8+K3ihZYaGuZ6Xa8lmM8Puk3y4rov4aINd0 TutmIUaNPv/X5ObJIRYUJGAjp66M25VIR257ZAzAiOdmF/STGbyjozs+2CjR7SJmn+kJ usoQ== X-Gm-Message-State: AKwxytc8vYJGkEUChOuwKBYxeHq++zHIsEE1rvNFAlbc9sABj79lEsfH wKyTRbcej3lz6uPJbc36viOC2OSOnRH6fE2ipVc= X-Google-Smtp-Source: ACJfBovXGqdg2uEB1johA8VEr7Q4ZllqbL8RiCDw8tCBKfn75JGL01xrdO14nSIRXYCcQ/iwo/oUE9jJNezaGfVrpt4= X-Received: by 10.37.28.65 with SMTP id c62mr22910213ybc.372.1516389255843; Fri, 19 Jan 2018 11:14:15 -0800 (PST) Original-Received: by 10.37.107.14 with HTTP; Fri, 19 Jan 2018 11:14:15 -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::230 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:222095 Archived-At: --001a11427d82ef9567056325e287 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Any chances of getting this patch committed? Thanks and cheers, Jaros=C5=82aw Rzesz=C3=B3tko On Mon, Jan 15, 2018 at 8:22 PM, Jaros=C5=82aw Rzesz=C3=B3tko wrote: > 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 debugge= r >> 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 = has >> 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 buffe= r >> 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 >> >> >> > --001a11427d82ef9567056325e287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Any chances of getting this patch committed?

Thanks and cheers,
Jaros=C5=82aw Rzesz=C3=B3tko

On Mon, Jan 15, 2018 at 8= :22 PM, Jaros=C5=82aw Rzesz=C3=B3tko <jrzeszotko@gmail.com> wrote:
Stefan,

I did not know about condition-case-unless-debug, it ind= eed 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 <jrzeszotko@gmail.com>= ; wrote:
I attach= a patch for ielm.el that makes it possible to enter the debugger when exec= uting expressions in ielm, and that makes ielm respect the debug-on-error a= nd debug-on-exit flags.=C2=A0

I guess that possibly the = reason that was not originally done is that it is not obvious how to restor= e ielm to a usable state after the debugger has been entered. My patch make= s 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 expres= sion given by the user in a condition case, and in case of an error, or exi= t, displays an appropriate message in its buffer, right under the evaluated= expression, regardless of debug-on-error and debug-on-exit.=C2=A0

With the patch, the message that ielm displays in its buff= er will be a generic error message=C2=A0 regardless if there was an error i= n the evaluated form, or a quit. However:

- if deb= ug-on-error is t, emacs will enter the debugger and show a stack trace, jus= t 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 specifi= c error in the minibuffer anyway

Similar things ar= e true for debug-on-quit.

I think this is an impro= vement over the current state of affairs. Of course ideally I would like to= preserve the "nice" message in ielm buffer and make the improvem= ents I made, but emacs does not seem to make it possible to do some handlin= g of an error and then to re-raise it while preserving the original stack t= race.

Cheers,
Jaros=C5=82aw Rzesz=C3=B3t= ko




--001a11427d82ef9567056325e287--