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

[Kim F. Storm]

Luc Teirlinck <address@hidden> writes:

> Stefan Monnier wrote:
>
>    Sit-for doesn't wait when executed from a macro.  As for messages you might
>    be right in some (maybe even in many) cases but I doubt it matters much
>    since unless the message is the last in the macro it will just be
>    overwritten anyway.
>
> If the macro is called with M-1000 or M-0, then, if nothing else, all
> these messages might slow macro execution down.  Moreover, if there
> are at least two different messages printed during execution of the
> macro, it will also get rid of all previous info in *Messages*.

Another good point in favour of the current functionality!

>
> On the other hand, there also is the problem that `interactive-p'
> returns t while _defining_ a keyboard macro.  It would appear to be
> deceiving to the user to have different behavior while _defining_ the
> macro and while executing it.

I see this as a feature -- not a problem.  

I think it would be far more confusing if a command behaves
differently when defining a macro.


> I do not know what declaring a function obsolete _exactly_ means.  I
> believe that what we could do is keep the function around indefinitely
> in its current form, but discourage its use in new code meant for
> inclusion in Emacs.  

Or enhance it:

(interactive-p)    => current behaviour
(interactive-p t)  => interactive or executing macro

(interactive-p 1)  => interactive or executing macro ONCE


>                      If people write their own functions for private
> use, they might find interactive-p more convenient than the
> alternative.  It also would mean that we would not have to worry about
> checking all existing calls _right now_.
>
> We could then recommend the following in the Elisp manual:

This would be good.

>
>      (defun foo (&optional interactive-p)
>        (interactive "p")
>        (when interactive-p
>          (message "foo")))
>
> if the message needs to be printed even during keyboard
> macro-execution and:
>
>      (defun foo (&optional interactive-p)
>        (interactive "p")
>        (or (not interactive-p)
>          executing-kbd-macro
>            defining-kbd-macro
>          (message "foo")))
>  
> if not.
>
> Note that the behavior of the latter version of `foo' differs from the
> current behavior of `interactive-p' by not showing the message during
> macro definition either.
>
> Sincerely,
>
> Luc.
>
>
>
>

-- 
Kim F. Storm <address@hidden> http://www.cua.dk