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.