bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp): Let-bind `default' to the first

["Drew Adams" <drew.adams@oracle.com>]

> > Let the command decide its own defaulting.  Individual 
> > commands that read the minibuffer should control such defaulting,
> > at the point of call.
> 
> Since when the command commands the user, and not other way round?

Straw man.  No one proposed that the command command the user.

It is normal, typical, and traditional, for a command that calls a function to
read input, to provide whatever defaults are appropriate.  Appropriate for that
particular command.  And of course appropriate for a user who chooses to invoke
that command.

> Perhaps you missed the whole thread, but see what the users 
> are forced to use
>
http://stackoverflow.com/questions/15161592/make-emacs-rgrep-default-to-last-sea
rch-term-rather-than-word-at-point
> in the absence of customizable options.

Did you hear me propose to get rid of customizable options?  FWIW, I see nothing
wrong with the request of that user.

What I suggested would be a misguided approach is to have an option that tries
to configure defaulting for a whole slew of possibly unrelated commands.  That's
all.

I pointed to an alternative approach that provides an option specific to a
command or to a group of related commands, the option value being a
default-value-providing function.  All commands in the group use the same
defaulting function.

I even mentioned that if some user wanted to be more specific about defaulting
behavior within the group of related commands, s?he could always do so by
providing as the option value a function that dispatches among the commands -
just like option `minibuffer-defaults'.  The design would not encourage that,
but it would anyway allow for it.

E.g., in the code I cited, if a user does not want the same defaulting behavior
for commands `occur', `how-many', etc., she can set option
`search/replace-default-fn' to a function that distinguishes them (e.g., using
`this-command', as Jambunathan suggested).

But a priori (according to the developer of replace+.el), a user would want the
same defaulting behavior for such commands, and that's why they were grouped to
use a common option.  If it was thought that most users would want separate
defaulting behavior here, then the design would reflect that, providing separate
options.

The point is to keep things narrowed in focus, promoting modularity.

I would group some commands together for convenience in customizing their
defaulting behavior, but only if such grouping (common behavior) made sense.

You would apparently group any and all commands - across the entire Emacs
spectrum, providing a single option (`minibuffer-defaults') that dispatches
according to the given command.

IMO, that's not the best approach; that's all.

> > FWIW, in my code I do something that I'm guessing might be 
> > similar to the _effect_ you want, but I stay completely away
> > from command lookup/dispatching.
> 
> There is no command lookup/dispatching since Jambunathan implements
> the third variant, and not the second cited above.

Sorry, dunno what that means.  I was writing only in reaction to the (your?)
proposed `minibuffer-defaults' option that is an alist of (COMMAND . FUNCTION)
entries and that seemed to me to dispatch defaulting based on the COMMAND.

> > I have a user option, `search/replace-default-fn', whose 
> > value (a function) provides the default value(s) for functions 
> > `query-replace', `occur', `how-many', `flush-lines',...
> 
> Your `search/replace-default-fn' is exactly the same thing as
> `occur-read-regexp-defaults-function', so why do you object?

See above.

1. I admitted that I did not follow the thread.

2. I made clear that I was commenting only on the proposal of a
`minibuffer-defaults' option that dispatches defaulting according to the
command.

3. Wrt that proposal I suggested an alternative approach.
If such an alternative is what is really being used, wunderbar.