Re: how-many/count-matches for non-interactive use

[Richard Stallman <rms@gnu.org>]

    It would definitely seem to be a lot better to change existing
    "incorrect" (whatever that means, it seems to be completely
    subjective) uses than to change `interactive-p'.  This way we will
    not break any currently correct code in the Emacs distribution, third
    party packages, user Elisp functions and, most importantly, user
    defined keyboard macros.

If most of the uses in Emacs are wrong, and expect interactive-p
to have the other meaning, I would expect that the same is true
for most uses of interactive-p outside Emacs.  After all, those
installed in Emacs have received more scrutiny by Emacs developers.

      The current behavior has been in place for a
    long time and users have defined (and saved) their keyboard macros to
    work with that behavior.

Sorry, I do not understand.  In what way would a keyboard macro be
defined "to work with" the current behavior?  How would anyone have
defined any keyboard macro differently if interactive-p worked the
other way.  I do not see it.  This change would cause certain commands
to work differently in keyboard macros, yes, but there is nothing you
can do in a keyboard macro to select the other behavior.  And there
still will be nothing if this change is made.

       The first step in fixing this is to take inventory.  Which uses of
       interactive-p are correct with the current definition of
       interactive-p?  Which would be correct with the modified definition of
       interactive-p that would not check for macros?

    I doubt that many uses are going to be obviously "correct" or
    "incorrect".

We can judge each of them by some predecided criteria of what is
right.

    In as far as the current example is concerned, it would seem _wrong_
    to _try_ to show the how-many/count-matches messages in an executing
    keyboard macro, like it is wrong to _try_ to show _any_ message in a
    keyboard macro.

I don't agree at all.

    Maybe the above could be considered a bug that should be fixed.  But
    even if this "bug" would be fixed, then if the macro is executed with
    `C-x e', the "(Type e to repeat macro)" message will still overwrite
    any message that the macro would try to print.

Investigating the reason for this, I found that message3_nolog tests
INTERACTIVE, which is 0 when executing a macro.  Thus, calls to
`message' never display a message while in a keyboard macro.  They
write into the *Messages* buffer, and that's all they do.  So all
calls to interactive-p to decide whether to call `message' should be
judged based on whether we want to put the message into *Messages*.

Anything but a progress message should go into *Messages*.

Would someone like to start checking the code that uses interactive-p
and judge them?  You could put each instance into one of these four
categories:

* Needs the current definition of interactive-p to be correct.
* Needs the changed definition of interactive-p to be correct.
* Is correct either way.
* You're not sure.

If you do that for even 10 of the uses, we should start to get a
picture.