Re: default value with interactive

[Michael Heerdegen]

Emanuel Berg <moasen@zoho.com> writes:

> What I have is two functions, one that
> searches, and one that "searches again" with
> the previous search string as input.
>
> When the function that searches is invoked, it
> asks for a search string, but if it isn't
> provided, the default (i.e., previous) string
> is used even tho the better way to do that is
> to invoke the function that searches
> again directly.
>
> I can extract into a function the code that
> fetches the previous search *but* how do I use
> that in the interactive form as well as outside
> it without computing twice? As was instructed
> here - (info "(elisp) Programming Tips") - only
> even in the provided example, it really didn't
> happen that way at all.

You are trying to solve a problem that doesn't exist.  The convention
does only speak about "region or position arguments" - right?  Maybe,
more generally, about arguments that the user specifies implicitly, like
having marked a region, having a certain position of point, positioning
the cursor over a certain url, or so.  Implicitly, because you don't
really enter the bounds of the region etc. when using a command that
operates on the region.

The rule you want to fulfill exists to make `repeat-complex-command'
behave convenient.  When you e.g. have a command `foo' that operates on
the current region (let's say, it query-replaces something in the
current region), `foo' will have arguments BEG, END, and a REGEXP etc.
The interactive form should return BEG and END as nil so that when I
have invoked the command, but want to redo it with a different region
(and just reuse the given input), I can just change the region and
invoke `repeat-complex-command' - without having to paste the actual
region bounds as numbers into the minibuffer.  I just can confirm the
default, because the command function had been invoked with BEG and END
nil, and that means "use the current region".

In your case, it makes no sense to use the "search again" command with
`repeat-complex-command' - when I want a new search, I should
`repeat-complex-command' the original search command (or just call it
itself), and the other one is already a redo command.

But even if you unite the two commands, it is still _useful_ to have the
last search pattern in the minibuffer to be able to reuse or edit it
(it's easy enough to replace it with something else) when using
`repeat-complex-command'.

It takes a bit of routine to learn how to design commands so that they
work well with `repeat-complex-command', but it's only sanity and reason
at the end.


Regards,

Michael.