bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp):


From: Drew Adams
Subject: bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp): Let-bind `default' to the first
Date: Sat, 9 Mar 2013 07:08:54 -0800

> 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.






reply via email to

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