GNU bug report logs - #13687
24.3.50; `read-regexp' should provide regex for symbol at point as defaults

Previous Next

Package: emacs;

Reported by: Jambunathan K <kjambunathan <at> gmail.com>

Date: Mon, 11 Feb 2013 06:30:02 UTC

Severity: wishlist

Found in version 24.3.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Jambunathan K'" <kjambunathan <at> gmail.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 13687 <at> debbugs.gnu.org
Subject: bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp): Let-bind `default' to the first
Date: Fri, 8 Mar 2013 10:53:54 -0800
> > 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).
> 
> Interesting suggestion there.
> 
> This makes me think that there is no need for multiple
> `hi-lock-read-regexp-defaults-function' and a separate
> `occur-read-regexp-defaults-function' etc.  But a single
> `read-regexp-defaults-function' that cases on `this-command'.

The question, as I said, is whether it makes sense, for the particular commands
that we group to use the same option, to provide the default regexp (or other
string) in the same way.

I can't speak to whether that is the case for hi-lock, occur, etc.  But if it is
true, then yes, a single option for such a group of commands makes sense.

> The function can return a symbol token like `t' for
> `this-command's which it doesn't want to meddle with but
> return nil or a regexp or list of regexps for commands it
> wants to insinuate.

That is not what I suggested.  I suggested that the option value be a function
that returns a string to use as the default value when reading user input.

What I said in the passage you cite is that that function (the value of the
option) could, if the user so wants, itself test `this-command' and provide a
different string depending on the current command.

> Is there any problem with this 
> `read-regexp-defaults-function' approach?

I think you're suggesting that the option value be a function that returns t or
nil, instead of returning a default-value string.  It's not clear to me how a
given command such as `occur' would make use of that Boolean return value.

As I noted before, I would not _encourage_ users to use a dispatching function
as the option value, but that would not (could not) be prevented.  They can do
anything they want using any function they want.

The out-of-the-box design should make a reasonable assumption about which
commands to group (i.e., which should use the same option).

If it is expected that some command that reads a regexp would generally be
better off with a different defaulting behavior, then that command should not
use the group option.  It could use its own, similar option, with a different
default option value (a different default-value-providing function).  Or it
could hard-code its defaulting, or whatever.

The use of a function to dispatch according to the current command should be
exceptional, IMO - only a fallback possibility and not something to be
encouraged.





This bug report was last modified 12 years and 69 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.