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

[Jambunathan K]

Drew

You are beating a dead horse and the first line clearly says it is a
DEAD HORSE.  The mail only stated why I KILLED the horse.

It is my way of saying my earlier patch to hi-lock and the previous
patch to occur stands and is useful.  I will definitely look in to
comments that you may have to offer with the patch that introduces
`occur-read-regexp-defaults-function'.

Grouping - I don't know why you are beating on it - will now be user's
responsibility not that of Emacs.

Jambunathan K.



"Drew Adams" <drew.adams@oracle.com> writes:

>> EXPERIMENTAL and ABANDONED PATCH
>
>> Use of `this-command' is very fragile and flaky.
>
> No, but it is somewhat fragile.
>
>> Consider `multi-occur-in-matching-buffers' which does multiple
>> `read-regexp' - one for the buffers and one for the actual
>> regexp.  It is not possible to return a two different regexps
>> for the same `this-command'.
>
> You don't need to.  If a user needs to test for
> `multi-occur-in-matching-buffers' via `this-command' then s?he can do that and
> act accordingly.  No need for general code that tries to second-guess things. 
>
>> Interestingly, I am attaching a long from *Messages* buffer 
>> and it looks like `this-command' is not reliable (Do you see 
>> `exit-minibuffer' in the logs.)
>
> See below.
>
>> So `this-command' could work for simple commands like highlighting
>> commands but will be flaky to be applied in general.
>> 
>> Anyways good to experiment and see where an idea takes us...
>
> As I said, we should not encourage this.  And yes, any use of `last-command' 
> or
> `this-command' is somewhat fragile, because some functions intentionally 
> change
> their values.
>
> And yes, comparing functions is also problematic in general.  No eta 
> reduction,
> for one thing: (equal (lambda (x) (car x)) 'car).
>
> See what I wrote earlier.  Let users choose any string-returning function they
> want to use for defaulting.  If a user wants to use a function that conditions
> its return value on `this-command', s?he can always do so.
>
> But there is no reason to encourage that.  Any set of commands that we design 
> to
> use the same defaulting choice (via the same user option) should be a cohesive
> group: the same choice should make sense across that set.
>
> If you have one or more commands that do not fit that, then give them their 
> own
> defaulting options (grouping again, where appropriate).
>
> There is nothing new here - just common sense.  The solution is simple, IMO.
>
>> Interestingly, I am attaching a long from *Messages* buffer 
>> and it looks like `this-command' is not reliable (Do you see 
>> `exit-minibuffer' in the logs.)
>>
>> cmd: exit-minibuffer defaults: nil
>
> Your code checks only (eq user-defaults t).  When `user-defaults' is nil, this
> returns nil.