[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kim F. Storm
Subject: Re: how-many/count-matches for non-interactive use
Date: Mon, 18 Oct 2004 10:39:18 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]