Subject: bug#78851: 30.1.50; fileloop-continue should have autoload cookie

From: Howard Melman <[email-masked]>
Date: Sun, 20 Jul 2025 11:46:40 -0400

On Jul 19, 2025, at 3:09 AM, Eli Zaretskii <[email-masked]> wrote:

> No further comments, so I'm now closing this bug, as the preferred
> solution seems to be to load the package manually when this function
> is needed.

Just to be clear, it isn't my "preferred solution"

I also think it's a bug that if I look at the docstring of
project-search (or several other autoloaded commands) it refers me to
the command fileloop-continue but since it's not autoloaded I can't
look at its docstring or even describe-command on it (yes I can find
it in the manual).  I find this annoying because it's left up to the
user to find a convenient keybinding for this command.

I think it's an odd api that has you call two functions
(fileloop-initialize-* and fileloop-continue) to use it, the first of
which is autoloaded (in fact all three variants of it) and the second
(which is the only interactive command in the package) requires you to
use declare-function to quiet the compiler.

I still don't understand what mistake "the previous maintainers made"
that warrants this.  To me the intended clever logic that
fileloop-continue will be loaded when fileloop-initialize-* is loaded
is a new mistake with known inconveniences for the api caller and
unintended (help and transient binding) consequences for the user.

All to save a little memory space in loaddefs?  If that's the case I
think the autoload cookie on fileloop-initialize can be removed since
it's only called from tags--compat-initialize which already does
(require 'fileloop) and any third party caller can do the same.

Since tags-loop-continue's key was repurposed, it looks like
discussion was coalescing on binding fileloop-continue to M-* but
ended abruptly.  FWIW, I think M-g , would be a reasonable binding.

Howard