Edebug: avoid messages on 'f' command

Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

In Edebug 'f' is bound to 'edebug-forward-sexp'. It can be seen as
"faster" space key, allowing you to step through function a whole sexp
at a time. However, there is an annoyance to it: each time I hit it,
echo area displays "Break" for about a second, which is only then
replaced by "Result: ...". By comparison, space displays result
immediately.

Request: improve Edebug to not print such intermediate message(s)
during 'f' and similar commands.

Paul

Re: Edebug: avoid messages on 'f' command

[Alan Mackenzie]

Hello, Paul.

On Tue, May 03, 2016 at 08:58:52PM +0200, Paul Pogonyshev wrote:
> In Edebug 'f' is bound to 'edebug-forward-sexp'. It can be seen as
> "faster" space key, allowing you to step through function a whole sexp
> at a time. However, there is an annoyance to it: each time I hit it,
> echo area displays "Break" for about a second, which is only then
> replaced by "Result: ...". By comparison, space displays result
> immediately.

Yes, this irritates me too.

> Request: improve Edebug to not print such intermediate message(s)
> during 'f' and similar commands.

Would you please try out the following patch.  It entirely cuts out the
one second pause on all "break commands" (whatever they might be).
Hopefully there aren't any unwanted side effects.

Just set the new customisable variable to nil, and off you go!

The patch is based on today's master branch.



diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index e8484fa..5d2e4e6 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -233,6 +233,11 @@ edebug-sit-for-seconds
   :type 'number
   :group 'edebug)
 
+(defcustom edebug-sit-on-break t
+  "Whether or not to pause for `edebug-sit-for-seconds' on reaching a break"
+  :type 'boolean
+  :group 'edebug)
+
 ;;; Form spec utilities.
 
 (defun get-edebug-spec (symbol)
@@ -2489,6 +2494,7 @@ edebug--display-1
                 (progn
                   ;; Display result of previous evaluation.
                   (if (and edebug-break
+                           edebug-sit-on-break
                            (not (eq edebug-execution-mode 'Continue-fast)))
                       (sit-for edebug-sit-for-seconds)) ; Show message.
                   (edebug-previous-result)))


> Paul

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

Yes, it works fine for me. Thank you.

Paul

On 5 May 2016 at 15:10, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Paul.
>
> On Tue, May 03, 2016 at 08:58:52PM +0200, Paul Pogonyshev wrote:
>> In Edebug 'f' is bound to 'edebug-forward-sexp'. It can be seen as
>> "faster" space key, allowing you to step through function a whole sexp
>> at a time. However, there is an annoyance to it: each time I hit it,
>> echo area displays "Break" for about a second, which is only then
>> replaced by "Result: ...". By comparison, space displays result
>> immediately.
>
> Yes, this irritates me too.
>
>> Request: improve Edebug to not print such intermediate message(s)
>> during 'f' and similar commands.
>
> Would you please try out the following patch.  It entirely cuts out the
> one second pause on all "break commands" (whatever they might be).
> Hopefully there aren't any unwanted side effects.
>
> Just set the new customisable variable to nil, and off you go!
>
> The patch is based on today's master branch.
>
>
>
> diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
> index e8484fa..5d2e4e6 100644
> --- a/lisp/emacs-lisp/edebug.el
> +++ b/lisp/emacs-lisp/edebug.el
> @@ -233,6 +233,11 @@ edebug-sit-for-seconds
>    :type 'number
>    :group 'edebug)
>
> +(defcustom edebug-sit-on-break t
> +  "Whether or not to pause for `edebug-sit-for-seconds' on reaching a break"
> +  :type 'boolean
> +  :group 'edebug)
> +
>  ;;; Form spec utilities.
>
>  (defun get-edebug-spec (symbol)
> @@ -2489,6 +2494,7 @@ edebug--display-1
>                  (progn
>                    ;; Display result of previous evaluation.
>                    (if (and edebug-break
> +                           edebug-sit-on-break
>                             (not (eq edebug-execution-mode 'Continue-fast)))
>                        (sit-for edebug-sit-for-seconds)) ; Show message.
>                    (edebug-previous-result)))
>
>
>> Paul
>
> --
> Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

By the way, here are some other things that I miss with Edebug. Maybe
you could find time to do something about these.

* Highlight breakpoints with overlays and/or on fringe.

* When setting a breakpoint in a non-instrumented form, instrument it
for me rather than printing an error.

* When C-M-x a definition that has breakpoints, try to preserve them,
rather than resetting. It's especially annoying to lose conditional
breakpoints. Might be hard to implement, though, as it's not clear how
to compare old and new definitions to decide where to move
breakpoints.

* Some way to list active breakpoints.

* Add analogue of 'f' (maybe bind to 'F') that temporary disables all
breakpoints until its destination is reached. Maybe also add a command
to "go to point ignoring all breakpoints".

Paul


On 5 May 2016 at 23:44, Paul Pogonyshev <pogonyshev@gmail.com> wrote:
> Yes, it works fine for me. Thank you.
>
> Paul
>
> On 5 May 2016 at 15:10, Alan Mackenzie <acm@muc.de> wrote:
>> Hello, Paul.
>>
>> On Tue, May 03, 2016 at 08:58:52PM +0200, Paul Pogonyshev wrote:
>>> In Edebug 'f' is bound to 'edebug-forward-sexp'. It can be seen as
>>> "faster" space key, allowing you to step through function a whole sexp
>>> at a time. However, there is an annoyance to it: each time I hit it,
>>> echo area displays "Break" for about a second, which is only then
>>> replaced by "Result: ...". By comparison, space displays result
>>> immediately.
>>
>> Yes, this irritates me too.
>>
>>> Request: improve Edebug to not print such intermediate message(s)
>>> during 'f' and similar commands.
>>
>> Would you please try out the following patch.  It entirely cuts out the
>> one second pause on all "break commands" (whatever they might be).
>> Hopefully there aren't any unwanted side effects.
>>
>> Just set the new customisable variable to nil, and off you go!
>>
>> The patch is based on today's master branch.
>>
>>
>>
>> diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
>> index e8484fa..5d2e4e6 100644
>> --- a/lisp/emacs-lisp/edebug.el
>> +++ b/lisp/emacs-lisp/edebug.el
>> @@ -233,6 +233,11 @@ edebug-sit-for-seconds
>>    :type 'number
>>    :group 'edebug)
>>
>> +(defcustom edebug-sit-on-break t
>> +  "Whether or not to pause for `edebug-sit-for-seconds' on reaching a break"
>> +  :type 'boolean
>> +  :group 'edebug)
>> +
>>  ;;; Form spec utilities.
>>
>>  (defun get-edebug-spec (symbol)
>> @@ -2489,6 +2494,7 @@ edebug--display-1
>>                  (progn
>>                    ;; Display result of previous evaluation.
>>                    (if (and edebug-break
>> +                           edebug-sit-on-break
>>                             (not (eq edebug-execution-mode 'Continue-fast)))
>>                        (sit-for edebug-sit-for-seconds)) ; Show message.
>>                    (edebug-previous-result)))
>>
>>
>>> Paul
>>
>> --
>> Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 306 bytes --]

On 2016-05-06 06:52, Paul Pogonyshev wrote:
> Might be hard to implement, though, as it's not clear how
> to compare old and new definitions to decide where to move
> breakpoints.

Although if breakpoints are shown as overlays as you suggested the new position of these overlays could help, maybe?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Edebug: avoid messages on 'f' command

[Eli Zaretskii]

> Date: Fri, 6 May 2016 12:52:13 +0200
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> By the way, here are some other things that I miss with Edebug. Maybe
> you could find time to do something about these.

How about filing a feature-request bug for these, so that they aren't
forgotten?

Thanks.

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

On 6 May 2016 at 14:51, Eli Zaretskii <eliz@gnu.org> wrote:
> How about filing a feature-request bug for these, so that they aren't
> forgotten?

Frankly, it would help to have a visual bugtracker like Bugzilla or
Jira.  I sent one feature request with M-x report-emacs-bug now, and I
have no idea if it arrived there at all and where to look at it. It's
probably better when you use Emacs for mailing in general, but I
don't. And thus I'm not even sure if the mail was sent or silently
dropped.

If you google for "PROGRAM-NAME bugtracker", 99% of time you get a
page with the form where you can just fill in fields and hit "submit".
With Emacs it's not like that.

Paul

Re: Edebug: avoid messages on 'f' command

[Eli Zaretskii]

> Date: Fri, 6 May 2016 16:25:07 +0200
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
> 
> On 6 May 2016 at 14:51, Eli Zaretskii <eliz@gnu.org> wrote:
> > How about filing a feature-request bug for these, so that they aren't
> > forgotten?
> 
> Frankly, it would help to have a visual bugtracker like Bugzilla or
> Jira.

I usually find myself lost in Bugzilla, but that's me.

> I sent one feature request with M-x report-emacs-bug now, and I
> have no idea if it arrived there at all and where to look at it.

What was the subject?  (The bug-tracker search engine returns almost
200 hits for "Pogonyshev", so it's hard to know which of those you
mean.)

Usually, when you file a bug report, you get a response mail from the
bug tracker with the details and the bug number, so I don't understand
why you are unsure whether the report arrived.

Anyway, I'd still urge you to file a feature request.  What can you
possibly lose?

Thanks.

Re: Edebug: avoid messages on 'f' command

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

>
> > I sent one feature request with M-x report-emacs-bug now, and I
> > have no idea if it arrived there at all and where to look at it.
>

I find it handy to bookmark:
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1

If you send email using report-emacs-bug, it should be in that latest bugs
list within like 5 minutes.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 764 bytes --]

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

On 6 May 2016 at 17:01, Eli Zaretskii <eliz@gnu.org> wrote:
> What was the subject?  (The bug-tracker search engine returns almost
> 200 hits for "Pogonyshev", so it's hard to know which of those you
> mean.)

By now I can tell that the mail got nowhere.

> Usually, when you file a bug report, you get a response mail from the
> bug tracker with the details and the bug number, so I don't understand
> why you are unsure whether the report arrived.

I had no reply, but also no error from M-x report-emacs-bug. I didn't
know if reply would just arrive 20 minutes later or never.

> Anyway, I'd still urge you to file a feature request.  What can you
> possibly lose?

I will. I just know now it's pointless to use M-x report-emacs-bug
unless you use Emacs to handle your mail in general.

Paul

Re: Edebug: avoid messages on 'f' command

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

>
>  I just know now it's pointless to use M-x report-emacs-bug
> unless you use Emacs to handle your mail in general.
>

I wouldn't say that it is pointless. M-x report-emacs-bug creates a buffer
with appropriate To: email, subject, and body with useful info about your
emacs version and environment.

I cannot send emails from within emacs because of the way the ports are set
by my company sysadmin.

But I still do M-x report-emacs-bug, copy everything and email everything
out using Gmail.

An example: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23460

> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1101 bytes --]

RE: Edebug: avoid messages on 'f' command

[Drew Adams]

> I just know now it's pointless to use M-x report-emacs-bug
> unless you use Emacs to handle your mail in general.

FWIW - I use `M-x report-emacs-bug', and I don't let Emacs
handle my mail - at all.

For me, `M-x report-emacs-bug' works well.  My mail client
is MS Outlook.  I use `M-x report-emacs-bug' to compose the
message and record session information (e.g. Emacs build).
Then I use `C-c C-c' and paste the copied message into a new
mail-client message that pops up, addressed and ready to send.

Easy.

Re: Edebug: avoid messages on 'f' command

[Alan Mackenzie]

Hello, Paul.

On Thu, May 05, 2016 at 11:44:17PM +0200, Paul Pogonyshev wrote:
> Yes, it works fine for me. Thank you.

I've committed the change to master at savannah (together with updates to
Edebug's documentation).

One thing's puzzling me - who would ever want that one second of "Break"
in the echo area?  It's annoying, and it's scarcely useful information.
Maybe I should just have ripped out that bit of code entirely.

> Paul

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

On 7 May 2016 at 08:57, Alan Mackenzie <acm@muc.de> wrote:
> One thing's puzzling me - who would ever want that one second of "Break"
> in the echo area?  It's annoying, and it's scarcely useful information.
> Maybe I should just have ripped out that bit of code entirely.

I wouldn't mind. And judging by the quite poor usability of Edebug in
general, I think others wouldn't care.

Paul

Re: Edebug: avoid messages on 'f' command

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Using git blame, you can find the original author who add that 1 second
delay. You can then copy them in this thread asking why they added that.

I use edebug but have never used the breakpoints (next thing to try out on
my list now). But I think that removing that delay permanently would be
fine too, unless there was a specify reason to add it in the first place.

On Sat, May 7, 2016, 7:55 AM Paul Pogonyshev <pogonyshev@gmail.com> wrote:

> On 7 May 2016 at 08:57, Alan Mackenzie <acm@muc.de> wrote:
> > One thing's puzzling me - who would ever want that one second of "Break"
> > in the echo area?  It's annoying, and it's scarcely useful information.
> > Maybe I should just have ripped out that bit of code entirely.
>
> I wouldn't mind. And judging by the quite poor usability of Edebug in
> general, I think others wouldn't care.
>
> Paul
>
> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1303 bytes --]

Re: Edebug: avoid messages on 'f' command

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

Wouldn't setting edebug-execution-mode to 'Continue-fast also remove this
pause, even before this commit was made?

On Sat, May 7, 2016, 9:40 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Using git blame, you can find the original author who add that 1 second
> delay. You can then copy them in this thread asking why they added that.
>
> I use edebug but have never used the breakpoints (next thing to try out on
> my list now). But I think that removing that delay permanently would be
> fine too, unless there was a specify reason to add it in the first place.
>
> On Sat, May 7, 2016, 7:55 AM Paul Pogonyshev <pogonyshev@gmail.com> wrote:
>
>> On 7 May 2016 at 08:57, Alan Mackenzie <acm@muc.de> wrote:
>> > One thing's puzzling me - who would ever want that one second of "Break"
>> > in the echo area?  It's annoying, and it's scarcely useful information.
>> > Maybe I should just have ripped out that bit of code entirely.
>>
>> I wouldn't mind. And judging by the quite poor usability of Edebug in
>> general, I think others wouldn't care.
>>
>> Paul
>>
>> --
>
> --
> Kaushal Modi
>
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1827 bytes --]

Re: Edebug: avoid messages on 'f' command

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Sat, May 7, 2016, 9:45 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Wouldn't setting edebug-execution-mode to 'Continue-fast also remove this
> pause, even before this commit was made?
>
Copying RMS on this. Looks like this pause at braekpoint was (sit-for 1)
from the very beginning (circa 1993-1996).

> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 808 bytes --]

Re: Edebug: avoid messages on 'f' command

[Eli Zaretskii]

> Date: Sat, 7 May 2016 06:57:45 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> On Thu, May 05, 2016 at 11:44:17PM +0200, Paul Pogonyshev wrote:
> > Yes, it works fine for me. Thank you.
> 
> I've committed the change to master at savannah (together with updates to
> Edebug's documentation).

Thanks.

Please also mark the new option with the appropriate :version
attribute.

Re: Edebug: avoid messages on 'f' command

[Alan Mackenzie]

Hello, Eli.

On Sat, May 07, 2016 at 05:21:56PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 7 May 2016 06:57:45 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > On Thu, May 05, 2016 at 11:44:17PM +0200, Paul Pogonyshev wrote:
> > > Yes, it works fine for me. Thank you.

> > I've committed the change to master at savannah (together with updates to
> > Edebug's documentation).

> Thanks.

> Please also mark the new option with the appropriate :version
> attribute.

Done.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Wouldn't setting edebug-execution-mode to 'Continue-fast also remove this
  > > pause, even before this commit was made?
  > >
  > Copying RMS on this. Looks like this pause at braekpoint was (sit-for 1)
  > from the very beginning (circa 1993-1996).

I don't remember anything about that call to sit-for from 20 years ago.
But I have a guess why it is there: because without it, execution would
be so fast you couldn't even see things scroll past.  So you might as well
proceed at full speed.

If that mode is useful for you, I have nothing against supporting it.
I think it would not be very useful in general, so I would not make
it the default.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Edebug: avoid messages on 'f' command

[Alan Mackenzie]

Hello, Richard.

On Sat, May 07, 2016 at 02:40:32PM -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > > Wouldn't setting edebug-execution-mode to 'Continue-fast also remove this
>   > > pause, even before this commit was made?

>   > Copying RMS on this. Looks like this pause at braekpoint was (sit-for 1)
>   > from the very beginning (circa 1993-1996).

> I don't remember anything about that call to sit-for from 20 years ago.
> But I have a guess why it is there: because without it, execution would
> be so fast you couldn't even see things scroll past.  So you might as well
> proceed at full speed.

The commands `t' (`edebug-trace-mode') and `c' (`edebug-continue-mode'),
which pause 1 second at, respectively, each stop point and each
breakpoint, are unaffected by this setting - they use one or more
different instances of `sit-for' which are on other code paths.

> If that mode is useful for you, I have nothing against supporting it.
> I think it would not be very useful in general, so I would not make
> it the default.

The setting at issue affects only the `f', `o', 'h' and `g' commands,
all of which stop at the next breakpoint and wait for another command.
When they do so, they display "Break" for one second and only then do
they display the result of the form just evaluated.  This is irritating.

I'm not unconvinced that removing this 1 second pause by default would
be the Right Thing.

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Edebug: avoid messages on 'f' command

[Marcin Borkowski]

On 2016-05-07, at 21:08, Alan Mackenzie <acm@muc.de> wrote:

> I'm not unconvinced that removing this 1 second pause by default would
> be the Right Thing.

+1.

FWIW, I use Edebug quite often and I don't consider its usability bad -
quite the opposite.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Edebug: avoid messages on 'f' command

[Paul Pogonyshev]

On 9 May 2016 at 15:55, Marcin Borkowski <mbork@mbork.pl> wrote:
> FWIW, I use Edebug quite often and I don't consider its usability bad -
> quite the opposite.

I recently submitted a bunch of feature requests for specific things
that can be improved. 6 or 7 just about breakpoints. I also see a lot
of problems with it that I have no idea how to improve at all.

For example, how do you check value of a variable in non-current scope
of execution?

What to do if you have 20 levels of nested lists/vectors of 100
elements each and backtrace buffers or even "Result: ..." message
simply take forever to display?

It's annoying that the debugger cannot debug without instrumenting
first. When I debug Java or JavaScript code at work, I don't have to
think if I instrumented all the functions I _potentially_ might want
to debug in advance, I just set a breakpoint and continue with step in
/ step over commands from it. With Edebug you can in principle
instrument not-yet-evaluated forms, but you have no way of stepping
out if the caller was not instrumented. And SPC result depends on
something you don't easily see: whether the function was instrumented
(then it works as "step in") or not ("step over").

It is frustratingly difficult to find the caller chain from backtrace
buffer, especially if complicated macros are involved.

Paul