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

[Stephen J. Turnbull]

Drew Adams writes:

 > Right, but my real point is not about the names but about freeing
 > up the two pass-through behaviors (one for specific commands, the
 > other for `C-u') from their coupling to scrolling.

Alan's point is that this is a YAGNI.  It's incumbent on you to show
it's actually a YIDNI ("yes, I *do* need it" in this concrete use
case).

[Perhaps you've already done that, but with all the repetition and
philosophical BS, and disingenuous claims about not wanting to belabor
dead horses that were bred and born earlier in your own post before
you beat them into submission with freshly cooked linguine, I don't
remember any more, and tl;wr2x ("too long; won't read two times").]

 > And even if that were also the case, nothing in fact prevents using
 > an inappropriate command this way.

There are lots of inappropriate things that can be done with Emacsen.
Most are in the class "you did WHAT? (mutter mutter you idiot)", most
of the rest are "oh; well, don't do that, then", and a few are in the
class of "attractive nuisance".  Only the last class should be checked
for.

 > Dunno.  That would probably be OK for me, but I can imagine RMS or
 > others chiming in that they are used to having `C-u' immediately
 > exit Isearch.  Having an option means not disturbing the general,
 > traditional behavior.

Despite what I wrote above, this is not on the face of it a YAGNI.  On
the other hand, it doesn't need to be a customization at first.  Only
once it appears that there are many users who do like the behavior, and
many who don't, does it need to be a visible customization.

 > Currently, it is all or nothing: all scroll commands plus any
 > others that might have property `isearch-scroll' or else none of
 > them.

Er, isn't that precisely why this is enabled via a property?

If you really need flexible control, you could turn the value into a
context descriptor (in XEmacs, a "specifier"; more generally, an alist
with keys some kind of test and values boolean).  (See above for
"YAGNI and YIDNI", though.)

 > Especially if we open this up to intentionally be about
 > pass-through in general and not just scrolling, users should have a
 > way to easily pick and choose which commands are affected by it.

Not so fast.  "Easy pick-and-choose" for users is definitely a YAGNI
on the face of it.  Use case?

 > > > Instead of a Boolean option (`isearch-allow-scroll'), users 
 > > > should have an option that specifies the affected commands.

Bad idea.  You already have the property, and this proposed option
requires developers of custom scroll commands (etc) to know about
isearch, which really would be unfortunate.

 > > > This means that if someone adds property `scroll-command' 
 > > > for some command then it automatically acts as if s?he
 > > > also added property `isearch-scroll'.  Why couple these
 > > > two things?  Why assume that every `scroll-command' command
 > > > is also one for which Isearch should allow scrolling.
 > > 
 > > Pretty much all standard commands that can be "scrolling" commands
 > > already are.  Let me know if there are any I have missed.
 > 
 > I know.  My question was why.

Because the feature really *is* about scrolling, not just about some
scroll commands inter alia.  Some users use isearch in a way that is
facilitated by scrolling commands which don't exit[1] isearch mode.  It
would be really really annoying if *some* of your (perhaps custom)
scrolling commands worked but *others* did not.  *This is a general
property of scrolling commands*: they're all useful, or not, in the
same sets of contexts for any given user.  Rather than force users to
add their custom commands to all such contexts, the 'scroll-command
property makes it possible to get scrolling command behavior in all
contexts, including ones you don't know about and haven't been written
yet anyhow.

 > IOW, instead of having Isearch automatically recognize property
 > `scroll-command', just use property `isearch-scroll' for all
 > pertinent commands (even if they already have property
 > `scroll-command').

To belabor that point, that's a bad idea.  *If* there are other
classes like scrolling commands that the user really thinks of as a
single parametrized command (ie, (defun scroll-command (direction
distance target-of-point) ...)), they should get their own property so
that users can set that property on custom commands in that class and
automatically get appropriate behavior in any context that respects
that property.

Then for the miscellaneous commands, the `isearch-scroll' property is
useful (it should be renamed to something like `isearch-inhibit-exit').


Footnotes: 
[1]  Please don't call this "pass-through" in the code.  It's not
clear what is being "passed" or what it goes "through" or what
"catches" it once it "gets through".