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

[Drew Adams]

> some people like pass-through for some set of commands
> but not for others

Exactly the point I made.

> so isearch-allow-scroll is meant 
> to control that for scrolling commands.

Doesn't follow ("so").  "Some set of commands" vs "others" is more general than
"scrolling commands" vs "others".

Well, you can certainly say that it was "meant" to control this only for
scrolling commands, but that's not what it does.  It controls it for any
command.  Turn on the option, `put' the property on the command symbol - and
Bob's your uncle.

Again, I don't really care much whether the existing, general code is recognized
as being in fact general and not scrolling-specific.  I don't really care much
whether the names, doc strings, and comments get changed to reflect this
reality.  That "misnomer" part of the `Subject:' was really mentioned in
passing, in case you do want to do something about it - an FYI.

My real wish is that `C-u' be separated out.  The rest I don't really care much
about.  I do not have any particular commands, scrolling or otherwise, in my
back pocket that I want Isearch to allow without necessarily exiting.

But I can certainly see that, as you say, "some people [might] like pass-through
for some set of commands but not for others".  And today (a) this some-vs-others
is couched as scrolling-vs-others.  And more importantly, (b) the only way for
users ("some people") to specify which commands they want in each camp is to put
or remove a symbol property (the only two properties for this act the same wrt
Isearch).

> We all agree that the fact that C-u got folded into it is definitely
> a misfeature in this respect.

Good to hear.  That's really the misfeature I'd like to see fixed.  Consider the
rest an FYI, if you like.

> Maybe what you want is a new option `isearch-pass-through-categories',
> which would be a list of symbol properties, so any command who has
> a non-nil value for one of those properties is allowed to run without
> exiting isearch.
> 
> Then `scroll-command' becomes one possible element of
> isearch-pass-through-categories.

OK by me.  Doesn't really change too much, though.  We already have such a list
(`scroll-command', `isearch-scroll'); it just isn't customizable/extensible.

But yes, that is along the lines of what I suggested (in my point #3).  My
suggestion was to not use only symbol properties for this - to have a user
option that specifies the allowed commands.  Grouping into categories would be
fine too.  But in that case, why not let users do their own grouping (and not
just by using symbol properties).

If you do open up to different symbol properties, then that would allow a bit
more flexibility, I suppose.  But a user who wants one category (e.g. foobar
commands) but not another (e.g. scrolling commands) still needs to go around
removing the unwanted property from one set of commands (e.g. scrolling) and
adding the wanted property for another set of commands.

Anyway, again, I don't really care much one way or the other about this part.
My real concern is to allow `C-u' pass-through to be separate from command
pass-through.

And preferably to allow users (separate) control over `C-u' pass-through (for
any users who might prefer the current behavior of `C-u' exiting Isearch).  I
personally don't need such control, but I think it would be good for Emacs to
give users that choice.

_If_ no changes are made wrt command pass-through (not `C-u' pass-through), then
a secondary concern/FYI is to make the doc and names reflect the current
reality, which is that the feature _in fact_, even if not by intention, is _not_
limited to scrolling.

> > It is true, AFAICT.  Nothing prevents you from putting property
> > `isearch-scroll' on *any* command, to get Isearch to pass through
> > to it.
> 
> But you still only have one boolean value to control what commands to
> pass through.  So what would you name this boolean option?
> `isearch-a-few-more-commands-run-within-isearch'?
> What if people want pass-through for scrolling commands but 
> not for your new command?

That was precisely my point (point #3, again).  Users should be able to control
(fine-tune) which commands are passed through, and preferably using Customize,
not just symbol properties.  Currently it is all-or-none: all commands that have
the property or none of them.  Option `isearch-allow-scroll' is a Boolean.

It would be better for it to list (specify) the allowed commands.  You could
still let libraries etc. use symbol properties, and have the default value of
the option pick up all such (loaded or autoloaded) command symbols.  So no,
"developers of custom scroll commands [need not] know about isearch" [ST].  They
would just do what they do now: add property `scroll-command'.  The option
default value would pick them all up.

Yes, if a user does customize the option then s?he will not pick up any such
default commands added afterward, but that is an inherent problem with option
default values. (There are ways around that problem, but probably not worth
using here.)

What is important is that such a fine-grained option lets users opt out of some
such commands without tracking down every symbol having `scroll-command' or
`isearch-allow-scroll' and changing property values to fit.

Anyway, if no change is made, so that we still have only a Boolean option, then
yes, about the only improvement available without changing the
design/implementation would be to rename things, including the Boolean option,
to be a bit clearer.

That option is just a general command pass-through, not a scrolling command
pass-through.  If renaming is the only change you want to make, then call it
`isearch-allow-command', `isearch-command-pass-through', `isearch-inhibit-exit'
[ST] (but it does _not_ prevent the command from exiting isearch),
`isearch-allow-no-exit', or some such.  Even such a vague name would be better
than giving the impression that it is only about scrolling.

Because several issues and possibilities have been discussed, let me repeat one
more time which one I really care about: separating (a) `C-u' pass-through from
(b) command pass-through.

Today these are hard-coupled in the (misnamed) single option
`isearch-allow-scroll'.  I would be OK with either always allowing `C-u'
pass-through or giving users the option (a separate option or option value from
allowing command pass-through).