emacs-devel
[Top][All Lists]
Advanced

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

Re: `isearch-allow-scroll' - a misnomer and a bad design


From: Alan Mackenzie
Subject: Re: `isearch-allow-scroll' - a misnomer and a bad design
Date: Sat, 10 Sep 2011 11:10:54 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi, Drew.

A bit of clarification:

On Fri, Sep 09, 2011 at 04:07:02PM -0700, Drew Adams wrote:

> That's my point.  Like those commands, I want to make use of this `C-u' 
> feature.
> But I do not want to also allow scrolling during Isearch.

[ .... ]

> > What would you suggest?  What does the option really do, in your
> > judgement?  Scrolling is an essential part of the option.

> AFAICT, it does two things:

> 1. It invokes any command that has property `isearch-scroll' or 
> `scroll-command'
> on its symbol - without necessarily exiting Isearch.

NO NO NO!!!  A "scrolling command" is a command which MOST DEFINITELY
DOESN'T exit the isearch.  This is the definition of "scrolling command"
in isearch.  With this in mind, please think through everything you've written.

[ .... ]

> 2. It passes a prefix arg through to any key (its command) that follows it.

Bear in mind that C-u `universal-argument' is a scrolling command in its
own right.  So we can construe what you're asking for thusly: to have an
option for a subset of scrolling commands to be executable in isearch

> Neither of these has anything to do with scrolling, necessarily.  Change the
> names to remove `scroll' and you will see that.

[ .... ]

> (And the code that gives the scrolling commands their Isearch behavior should
> not even be in isearch.el, IMO.)

I'm not sure what you mean by this.  Their "isearch behaviour" is part of
isearch.  These commands operate precisely the same way, regardless of
whether they're called from isearch or not.

[ .... ]

> > > 1b. For another thing (i.e., forgetting about `C-u'), *any* 
> > >     command can benefit from the same Isearch feature as a
> > >     scrolling command.  It suffices to put a non-nil
> > >     `isearch-scroll' property on the command symbol.

> > This isn't true.

> It is true, AFAICT.  Nothing prevents you from putting property 
> `isearch-scroll'
> on *any* command, to get Isearch to pass through to it.

The current isearch, with isearch-allow-scroll set, will pass a C-u
through to the next command regardless of whether that command is a
scrolling command.

> > Only commands which don't foul up the isearch can be
> > permitted to use the feature.  Only a few commands meet the criteria.
> > `universal-argument' is such a command.

> (It would be up to the command they are passed through to to decide whether to
> exit.

That would be something entirely new.  It might involve such a command
returning t/nil to instruct isearch to exit or not.  But that would be a
horrible kludge.  (Every command being adjusted to do this?  What about
other uses of the return value?  There are an awful lot of commands)

> Granted that users might not want to mess around with the scrolling commands
> (whether via `put' or Customize), perhaps you will recognize that a user might
> want to not have Isearch pass through to some command that library `foo' 
> thinks
> it is a great idea to pass through to by default.

You mean "pass through a C-u"?  I don't see this at all.  Perhaps you
have a specific use case in mind.

> > Again, familiarise yourself with just how restricted the permissible
> > commands are.  There's a list of criteria in isearch.el 
> > ~L1760 (think - number of yards in a mile :-).

> I read that comment, and I read the code.

You haven't given any hint that you've really understood these
restrictions.  Imagine a quasi-scrolling command that breaks one of them.
Say, for example, it moves point.  You would then be in the middle of an
isearch with point not at the head of the current search string.

I'm not saying that it wouldn't be possible to extend the semantics of
isearch to make this valid, but it would be difficult.  At least it might
be technically possible but it most assuredly wouldn't be politically
possible.

> That said, I don't want to belabor this part.  My main interest is in freeing 
> up
> `C-u', which you have already agreed to.

[ .... ]

> I would like to see `C-u' passed through - that's the main point.  Either
> systematically or optionally, but if optionally then separately from allowing
> scrolling.

Try out this patch; I think it does what you want.  (It's obviously very
rough code, in desperate need of refactoring, but it might work.)


*** isearch.el~ 2011-09-04 15:31:05.000000000 +0000
--- isearch.el  2011-09-10 10:58:02.000000000 +0000
***************
*** 1966,1976 ****
           (apply 'isearch-unread keylist)
           (isearch-edit-string))
            ;; Handle a scrolling function.
!           ((and isearch-allow-scroll
!                 (progn (setq key (isearch-reread-key-sequence-naturally 
keylist))
!                        (setq keylist (listify-key-sequence key))
!                        (setq main-event (aref key 0))
!                        (setq scroll-command (isearch-lookup-scroll-key key))))
             ;; From this point onwards, KEY, KEYLIST and MAIN-EVENT hold a
             ;; complete key sequence, possibly as modified by function-key-map,
             ;; not merely the one or two event fragment which invoked
--- 1966,1985 ----
           (apply 'isearch-unread keylist)
           (isearch-edit-string))
            ;; Handle a scrolling function.
!           ((or
!           (and isearch-allow-scroll
!                (progn (setq key (isearch-reread-key-sequence-naturally 
keylist))
!                       (setq keylist (listify-key-sequence key))
!                       (setq main-event (aref key 0))
!                       (setq scroll-command (isearch-lookup-scroll-key key))))
!           (progn
!             (setq key (isearch-reread-key-sequence-naturally keylist)
!                   keylist (listify-key-sequence key)
!                   main-event (aref key 0)
!                   scroll-command (key-binding key))
!             (or (eq scroll-command 'universal-argument)
!                 (eq scroll-command 'negative-argument)
!                 (eq scroll-command 'digit-argument))))
             ;; From this point onwards, KEY, KEYLIST and MAIN-EVENT hold a
             ;; complete key sequence, possibly as modified by function-key-map,
             ;; not merely the one or two event fragment which invoked

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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