bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Dima Kogan]

Hi. Currently when the user invokes any gud-based mode ('M-x pdb' for
instance) the minibuffer pops up with a suggested command. This command
tries to guess what you're trying to debug based on some pretty
arbitrary heuristics. This is in 'gud-query-cmdline' in gud.el

These heuristics include looking at each file in the current directory
to find the most recent executable file. In my experience this almost
never is what I want. If I'm doing remote debugging with tramp and the
current directory has many files in it, then emacs can sit there for a
very long time before opening the minibuffer, while it looks at all the
files in the remote directory. I think this delay changes this behavior
from not-useful to harmful, and I think it should be removed. Thoughts?

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Sun, 20 Sep 2015 19:50:21 -0700
> 
> Hi. Currently when the user invokes any gud-based mode ('M-x pdb' for
> instance) the minibuffer pops up with a suggested command. This command
> tries to guess what you're trying to debug based on some pretty
> arbitrary heuristics. This is in 'gud-query-cmdline' in gud.el
> 
> These heuristics include looking at each file in the current directory
> to find the most recent executable file. In my experience this almost
> never is what I want. If I'm doing remote debugging with tramp and the
> current directory has many files in it, then emacs can sit there for a
> very long time before opening the minibuffer, while it looks at all the
> files in the remote directory. I think this delay changes this behavior
> from not-useful to harmful, and I think it should be removed. Thoughts?

Removing it altogether, based on your personal and very specific use
case, would be too drastic, IMO.  Can you propose some less drastic
measure?  If nothing smarter could be done automatically, a defcustom
to control this should be a stopgap, I think.

And while at that: the search for executables could bypass certain
files, like shell scripts, for example.

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> If I'm doing remote debugging with tramp and the current directory
>> has many files in it, then emacs can sit there for a very long time
>> before opening the minibuffer, while it looks at all the files in the
>> remote directory. I think this delay changes this behavior from
>> not-useful to harmful, and I think it should be removed. Thoughts?
>
> Removing it altogether, based on your personal and very specific use
> case, would be too drastic, IMO.

Completely agree that my opinion should play only a small role. Let me
push that argument a tiny bit more, and I'll leave it alone.

The current heuristic assumes that both

1. The program we're debugging lives in the current directory
2. The program is executable

Both of those could be true, but probably not all that often. Especially
the "program is executable part" easily fails for interpreted languages.



OK. Now for better solutions. The current logic is:

  (dolist (f (directory-files default-directory) file)
    (if (and (file-executable-p f)
             (not (file-directory-p f))
             (or (not file)
                 (file-newer-than-file-p f file)))
        (setq file f)))

With tramp each of the file system calls above are a separate tramp
call, and the overhead becomes very significant. I don't know enough
about tramp to know if consolidating these would be possible.

The heuristic could be more useful be filtering on file extensions. So
for instance looking at only .py files for pdb could be good, but this
could be wrong, and wouldn't really speed up the above code.

Finally as currently written, perldb doesn't run that code at all, but
simply tries to debug the script in the current buffer. This could easly
apply to python too, if we decide.

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 21528@debbugs.gnu.org
> Date: Mon, 21 Sep 2015 00:39:13 -0700
> 
> The current heuristic assumes that both
> 
> 1. The program we're debugging lives in the current directory
> 2. The program is executable
> 
> Both of those could be true, but probably not all that often. Especially
> the "program is executable part" easily fails for interpreted languages.

How about bypassing this search in 2 situations:

 . the debuggee is on a remote system
 . the debugger being invoked is for an interpreted language

Would that be "good enough"?

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

> How about bypassing this search in 2 situations:
>
>  . the debuggee is on a remote system
>  . the debugger being invoked is for an interpreted language
>
> Would that be "good enough"?

That would be fine by me. What do you want to do with perldb? Currently
it always bypasses this search.

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: 21528@debbugs.gnu.org
> Date: Mon, 21 Sep 2015 02:03:53 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How about bypassing this search in 2 situations:
> >
> >  . the debuggee is on a remote system
> >  . the debugger being invoked is for an interpreted language
> >
> > Would that be "good enough"?
> 
> That would be fine by me. What do you want to do with perldb? Currently
> it always bypasses this search.

Perldb is of the "interpreted language" type, isn't it?

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > How about bypassing this search in 2 situations:
>> >
>> >  . the debuggee is on a remote system
>> >  . the debugger being invoked is for an interpreted language
>> >
>> > Would that be "good enough"?
>> 
>> That would be fine by me. What do you want to do with perldb? Currently
>> it always bypasses this search.
>
> Perldb is of the "interpreted language" type, isn't it?

Yep. Just making sure that you're proposing touching that too. Works for
me. Thanks.

bug#21528: 25.0.50; gud tries to guess what file we're debugging, which can take a long time

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Both of those could be true, but probably not all that often. Especially
>> the "program is executable part" easily fails for interpreted languages.
>
> How about bypassing this search in 2 situations:
>
>  . the debuggee is on a remote system
>  . the debugger being invoked is for an interpreted language
>
> Would that be "good enough"?

I don't think it's all that useful to separate interpreted vs compiled
here -- it'll be slow (or not) in any case (and interpreted files are
normally executable).

So I've just made it not do the loop if it's on a remote system, and
there's a lot of files there in Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no