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

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

[Drew Adams]

1. The doc for this option, as well as its name, give the impression that it is
about allowing scrolling.  It is not.

1. For one thing, a non-nil value allows *any* command bound to a key in
`isearch-mode-map' to take advantage of a prefix arg.  That is, `C-u' is passed
through to the command if the option value is non-nil.  The command need not
have anything to do with scrolling.

And there are already at least two such vanilla commands:
`isearch-query-replace' and `isearch-query-replace-regexp' (`M-%', `C-M-%').  A
`C-u' changes the command behavior in a way that has nothing to do with
scrolling.

At a minimum, the doc should be adjusted.  The option name should also be
changed to fit what it really does.  Likewise, the functions (e.g.
`isearch-lookup-scroll-key') and other code and doc strings in isearch.el that
paint this feature as having to do with scrolling.

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.


2. I would like to see us separate the treatment of a prefix arg - whether it
gets passed it through to a command or it exits Isearch - from the other
uses/effects of this option.

IOW, I would like to be able to set some option to have Isearch pass `C-u'
through, and have that be independent of the setting of some other option that
controls whether scrolling (or some other behavior) is allowed.  Even if
allowing scrolling (or whatever) might also require the ability to pass through
`C-u', that does not mean that being able to pass through `C-u' should allow
scrolling.  It makes little sense to couple these two features.

The query-replace commands are a good example, and users (such as yours truly)
might well want similar `C-u' pass-through for other commands, without also
wanting scrolling (or whatever).


3. Wrt controlling which commands are affected by the option (i.e., forgetting
about `C-u' now): The current design makes the library designer responsible for
this choice, not the user.  That is another flaw, IMO.  A user should be able to
easily (using Customize, not just putting `put' here and there) choose which
commands are affected.  Instead of a Boolean option (`isearch-allow-scroll'),
users should have an option that specifies the affected commands.  (It could
also configure any specifics for each command, if there are such.)


4. Why are there currently _two_ different properties that turn on this
sensitivity (i.e., "scrolling")?  From the code comments:

;; ... property called `isearch-scroll'.
;; If a command's symbol has the value t for this property or for the
;; `scroll-command' property, it is a scrolling command.

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.

All of this smacks of being a carryover from someone's (hi Alan) personal
customizations, rather than being thought out in terms of users in general.

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

[Alan Mackenzie]

Hi, Drew,

I kind of feel myself being addressed here.  :-)

On Fri, Sep 09, 2011 at 01:38:16PM -0700, Drew Adams wrote:
> 1. The doc for this option, as well as its name, give the impression that it is
> about allowing scrolling.  It is not.

It is largely about scrolling.  Try enabling the option and use <PgUp>,
<PgDn> during an isearch.  Or try C-l.  The need to scroll during a
search was what inspired the feature.

> 1. For one thing, a non-nil value allows *any* command bound to a key in
> `isearch-mode-map' to take advantage of a prefix arg.  That is, `C-u' is passed
> through to the command if the option value is non-nil.  The command need not
> have anything to do with scrolling.

I'm not sure that's quite true.  Or if it is, keys like C-s don't react
to it.

> And there are already at least two such vanilla commands:
> `isearch-query-replace' and `isearch-query-replace-regexp' (`M-%', `C-M-%').  A
> `C-u' changes the command behavior in a way that has nothing to do with
> scrolling.

It's good that the C-u works, though.  ;-)

> At a minimum, the doc should be adjusted.  The option name should also be
> changed to fit what it really does.

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

> Likewise, the functions (e.g.  `isearch-lookup-scroll-key') and other
> code and doc strings in isearch.el that paint this feature as having to
> do with scrolling.

They're stricly internal functions, so changing their names/doc strings
wouldn't be a big deal.

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

> 2. I would like to see us separate the treatment of a prefix arg - whether it
> gets passed it through to a command or it exits Isearch - from the other
> uses/effects of this option.

I agree, that would be a good idea.  It wouldn't take very much work.

> IOW, I would like to be able to set some option to have Isearch pass `C-u'
> through, and have that be independent of the setting of some other option that
> controls whether scrolling (or some other behavior) is allowed.  Even if
> allowing scrolling (or whatever) might also require the ability to pass through
> `C-u', that does not mean that being able to pass through `C-u' should allow
> scrolling.  It makes little sense to couple these two features.

Need it be an option?  Why not just let C-u through no matter what?

> The query-replace commands are a good example, and users (such as yours truly)
> might well want similar `C-u' pass-through for other commands, without also
> wanting scrolling (or whatever).

As a matter of interest, have you tried setting isearch-allow-scroll?  If
you have and didn't like it, what about it didn't you like?

> 3. Wrt controlling which commands are affected by the option (i.e., forgetting
> about `C-u' now): The current design makes the library designer responsible for
> this choice, not the user.  That is another flaw, IMO.  A user should be able to
> easily (using Customize, not just putting `put' here and there) choose which
> commands are affected.

I disagree totally here.  The sophisticated user can set a suitable
command to be a "scrolling" command.  The unsophisticated user is going
to get his Emacs into a thorough mess by messing around in this area.

> Instead of a Boolean option (`isearch-allow-scroll'), users should have
> an option that specifies the affected commands.  (It could also
> configure any specifics for each command, if there are such.)

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

> 4. Why are there currently _two_ different properties that turn on this
> sensitivity (i.e., "scrolling")?  From the code comments:

> ;; ... property called `isearch-scroll'.
> ;; If a command's symbol has the value t for this property or for the
> ;; `scroll-command' property, it is a scrolling command.

I haven't a clue.  I've no idea who put `scroll-command' in or why.

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

> All of this smacks of being a carryover from someone's (hi Alan) personal
> customizations, rather than being thought out in terms of users in general.

Pretty much all standard commands that can be "scrolling" commands
already are.  Let me know if there are any I have missed.

Users capable of writing their own "scrolling" commands will be quite
capable of putting the `isearch-scroll' property on them.  (I have done
this.)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

> Hi, Drew,

Hi Alan,

> I kind of feel myself being addressed here.  :-)

Consider it a compliment that I now see some use for this general feature -
beyond scrolling (which I personally won't use it for). ;-)

> > 1. The doc for this option, as well as its name, give the 
> > impression that it is
> > about allowing scrolling.  It is not.
> 
> It is largely about scrolling.

I meant that it is not _necessarily_ about scrolling.  I understand that that
was the original motivation, and it remains an important use case (for people
who want scrolling).

> > 1. For one thing, a non-nil value allows *any* command 
> >    bound to a key in `isearch-mode-map' to take advantage
> >    of a prefix arg.  That is, `C-u' is passed
> >    through to the command if the option value is non-nil.
> >    The command need not have anything to do with scrolling.
> 
> I'm not sure that's quite true.  Or if it is, keys like C-s 
> don't react to it.

AFAICT, it is 100% true.  For one thing, that's how
`isearch-query-replace(-regexp)' works.  Those commands do _not_ have property
`isearch-scroll' or `scroll-command' on their symbols.  They simply use the
feature that `C-u' gets passed through if `isearch-allow-scroll' is non-nil.

> > And there are already at least two such vanilla commands:
> > `isearch-query-replace' and `isearch-query-replace-regexp' 
> > (`M-%', `C-M-%').  A `C-u' changes the command behavior in
> > a way that has nothing to do with scrolling.
> 
> It's good that the C-u works, though.  ;-)

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.

For example, I have an Icicles command (bound to `S-TAB') that runs from
Isearch, and if you use `C-u S-TAB' then its behavior is different.  But that
means that to take advantage of this users need to turn on
`isearch-allow-scroll'.

That would be OK if that only had the effect of allowing `C-u' pass-through.
But it also allows scrolling, and it's not obvious that users who want to use
`C-u S-TAB' also want Isearch to allow scrolling.

> > At a minimum, the doc should be adjusted.  The option name 
> > should also be changed to fit what it really does.
> 
> 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.  The function used to look
up such commands is `isearch-lookup-scroll-key', but there is nothing in that
function's definition that deals with scrolling or scroll commands (apart from
the names of the properties checked).

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

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

Now, yes, it happens that the scrolling commands use property `scroll-command'.
That was one of my points: separate the property used to distinguish susceptible
commands for Isearch from a property that is associated with scrolling.  For
scrolling commands, if you want pass-through from Isearch then you just give
them property `isearch-scroll' (a bad name), in addition to property
`scroll-command'.

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

> > Likewise, the functions (e.g. `isearch-lookup-scroll-key') 
> > and other code and doc strings in isearch.el that paint this
> > feature as having to do with scrolling.
> 
> They're stricly internal functions, so changing their 
> names/doc strings wouldn't be a big deal.

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.  Once freed, nothing would prevent you from
re-associating them: telling Isearch that you want scrolling commands to benefit
from the pass-through feature.

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

Now that does not mean that every command is a reasonable candidate for using
this feature.  It just means that the feature is not in any way
scrolling-specific.

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

Even if you are right about that, nothing says that that particular set of
commands is limited to scrolling commands.  And even if that were also the case,
nothing in fact prevents using an inappropriate command this way.  The code
looks for only one thing: property `isearch-scroll'.

> > 2. I would like to see us separate the treatment of a 
> >    prefix arg - whether it gets passed it through to a
> >    command or it exits Isearch - from the other
> >    uses/effects of this option.
> 
> I agree, that would be a good idea.  It wouldn't take very much work.

Very glad to hear that.

> Need it be an option?  Why not just let C-u through no matter what?

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.

But as far as I'm concerned, I think I would be in favor of always letting
prefix-arg keys pass through without exiting Isearch.

(It would be up to the command they are passed through to to decide whether to
exit.  In the case of the Icicles feature that uses this, the command does in
fact exit Isearch, after picking up some Isearch info.  But the important thing
is to be able to pass a prefix arg to the command, which is bound to a key on
`isearch-mode-map'.)

> As a matter of interest, have you tried setting 
> isearch-allow-scroll?  If
> you have and didn't like it, what about it didn't you like?

I have tried it.  I don't recall just what I didn't like.  I wouldn't say that
I'm against it or I don't like it.  (For one thing, I'm not used to it.)  But I
do recall trying it out a fair amount a few years back.  You know, everyone is
different.  The fact that someone might not like to use it doesn't mean much.

> > 3. Wrt controlling which commands are affected by the 
> >    option (i.e., forgetting about `C-u' now): The current
> >    design makes the library designer responsible for
> >    this choice, not the user.  That is another flaw, IMO.
> >    A user should be able to easily (using Customize, not just
> >    putting `put' here and there) choose which commands are affected.
> 
> I disagree totally here.  The sophisticated user can set a suitable
> command to be a "scrolling" command.  The unsophisticated 
> user is going to get his Emacs into a thorough mess by messing
> around in this area.

I suspect you are still thinking of this in terms of scroll commands.  I am not.

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.

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

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.  (I say "intentionally" because it is already open
but without any advertising and partially hidden behind the names "scroll"
this-and-that.

> > Instead of a Boolean option (`isearch-allow-scroll'), users 
> > should have an option that specifies the affected commands.
> > (It could also configure any specifics for each command, if
> > there are such.)
> 
> 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.  Again, I think you are thinking only
in terms of scrolling commands.  The feature is in fact only about pass-through
to a command, letting it run without necessarily exiting Isearch.  It is just
like the `C-u' pass-through, but without the `C-u'.  The code is not
"scroll"-specific at all, AFAICT.

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.

My point about the non-C-u pass-through was mainly to say that it is already
there, and it has nothing, a priori, to do with scrolling.  That its predefined
use might currently be limited to scrolling does not mean that the code actually
recognizes scrolling.  Likewise, if it turns out that no one will ever want to
use it for any command other than scrolling.  The code itself is agnostic -
scrolling-blind (AFAICT).

> > 4. Why are there currently _two_ different properties that 
> >    turn on this sensitivity (i.e., "scrolling")?  From the
> >    code comments:
> 
> > ;; ... property called `isearch-scroll'.
> > ;; If a command's symbol has the value t for this property 
> > ;; or for the `scroll-command' property, it is a scrolling
> > ;; command.
> 
> I haven't a clue.  I've no idea who put `scroll-command' in or why.

I presume that it is for scrolling commands, outside of any Isearch context.

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

But I don't really care.  My point was that these are two different things that
need not be automatically coupled.  They can instead be explicitly coupled if
that's a good idea.  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').

Again, though.  I don't want to insist on using pass-through for non-scrolling
commands.  I don't really care about that.

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.

Passing `C-u' through to a command (e.g. `isearch-query-replace') really has
nothing to do, logically, with allowing scrolling.  Users who would like to
allow `C-u' pass-through should not also have to allow scrolling.  That's my
main point, and I think you agree with that much.

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

[Stefan Monnier]

> I meant that it is not _necessarily_ about scrolling.  I understand that that
> was the original motivation, and it remains an important use case (for people
> who want scrolling).

Actually, it's more than that: its intention is about scrolling.
You can abuse it, but some people like pass-through for some set of
commands but not for others, so isearch-allow-scroll is meant to control
that for scrolling commands.

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

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.

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


        Stefan

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

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

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

[Alan Mackenzie]

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

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

[Alan Mackenzie]

Hi, Stefan.

On Fri, Sep 09, 2011 at 08:58:42PM -0400, Stefan Monnier wrote:
> > I meant that it is not _necessarily_ about scrolling.  I understand that that
> > was the original motivation, and it remains an important use case (for people
> > who want scrolling).

> Actually, it's more than that: its intention is about scrolling.
> You can abuse it, but some people like pass-through for some set of
> commands but not for others, so isearch-allow-scroll is meant to control
> that for scrolling commands.

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

I do not agree with this.  ;-)  The prefix arg is an essential part of
the command with which one might exit isearch.

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

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

This isn't quite true either.  The current isearch-scroll property must
be t (not merely non-nil) at the moment.  This leaves other non-nil
values to specify other behaviour.  This was deliberate.

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


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Juri Linkov]

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

I think this would be the best thing to do.  And to add
a new property that doesn't exit Isearch regardless of the value of
`isearch-allow-scroll'.  And put it on all universal argument commands
`universal-argument', `negative-argument', `digit-argument', i.e.:

  ;; Universal argument commands
  (put 'universal-argument 'isearch-inhibit-exit t)
  (put 'negative-argument 'isearch-inhibit-exit t)
  (put 'digit-argument 'isearch-inhibit-exit t)

that will do TRT by default for commands unrelated to scrolling.

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

[Alan Mackenzie]

Hi, Juri.

On Sat, Sep 10, 2011 at 02:47:08PM +0300, Juri Linkov wrote:
> > 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.

> I think this would be the best thing to do.  And to add
> a new property that doesn't exit Isearch regardless of the value of
> `isearch-allow-scroll'.  And put it on all universal argument commands
> `universal-argument', `negative-argument', `digit-argument', i.e.:

Please everybody, this whole thing is balooning out of control.  What
everybody seems to be forgetting is that this feature can only be used
with commands which:

1. Don't change the buffer being isearched through;
2. Don't move point;
3. Don't swap to another buffer, window or frame;
4. Don't mess with isearch's state (e.g. with search-regexp functions).

This is really a TINY number of commands, mostly to do with scrolling,
changing window arrangement, and the prefix arg.  Any other command would
screw up the isearch horribly.

>   ;; Universal argument commands
>   (put 'universal-argument 'isearch-inhibit-exit t)
>   (put 'negative-argument 'isearch-inhibit-exit t)
>   (put 'digit-argument 'isearch-inhibit-exit t)

> that will do TRT by default for commands unrelated to scrolling.

I agree these three commands should be separated out.  I've already
supplied a rough patch for this.

But for any more additional complexity, we should have a firm use case.
Complexity without reason is a Bad Thing.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

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

Well, yes and no.  Yes, in general Isearch tries to prevent exit.

But if a command wants to exit, it can do so:

(defun foo ()
  (interactive)
  (isearch-done)
  (message "WWWWWWWW")(sleep-for 2)
  (forward-char 2))

That's what I do now, to exit Isearch and invoke Icicles search.  In this case,
I use only `C-u' pass-through, not command pass-through.

;; Bound to `S-TAB' in Isearch.
(defun icicle-search-w-isearch-string (&optional use-context-p)
  "Icicles-search the buffer using an Isearch string chosen by completion.
The string you choose is used as the Icicles search context.  You can
navigate among its occurrences or search within those occurrences for
a subpattern.
If option `isearch-allow-scroll' is non-nil then a prefix arg changes
the behavior, as follows:
1. You are prompted for an Icicles search-context regexp.
2. You are prompted for an Isearch string, which you choose using
   completion.  It is copied to the `kill-ring'.
3. You can yank that string anytime during Icicles search, to search
   for it within the contexts defined by the regexp matches."

  (interactive "P")
  (isearch-done)
  (if (not use-context-p)
      (icicle-search (point-min) (point-max)
                     (icicle-isearch-complete-past-string) t)
    (let ((regexp  (icicle-search-read-context-regexp)))
      (kill-new (icicle-isearch-complete-past-string))
      (icicle-search (point-min) (point-max) regexp t))))

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

If you like.  I really don't care how you characterize it, as long as it is
understood.

Users of a command such as `icicle-search-w-isearch-string' should not need to
also allow _scrolling_ for Isearch, just to allow such a command to work from
Isearch, picking up the prefix arg.  IOW, I would like to be able to remove this
part of the command's doc string: "If option `isearch-allow-scroll' is non-nil".
This command has nothing to do with scrolling within Isearch.  Absolutely
nothing.

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

It's a detail - not important.  IMO, it might be better to put this kind of code
at the place where the command is defined, and not in isearch.el:
(put 'recenter 'isearch-scroll t)
But I certainly won't argue the point.

> Their "isearch behaviour" is part of isearch.  These commands
> operate precisely the same way, regardless of
> whether they're called from isearch or not.

The fact that you want some particular command to not exit Isearch is part of
the behavior you want for _that command_.  Yes, it's the part of the behavior
that is within an Isearch context... so it's a choice.  I would probably put the
`put' where the command is defined and not where Isearch is defined.  But it's a
choice.

The same kind of thing arises for decisions about where to put thing-at-point
properties: at the point of the function's definition, or in thingatpt.el?  And
so on.  We can perhaps agree to disagree about this.

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

You changed the subject.  (1b) is about passing a _command_ through, not passing
`C-u' through (see: "forgetting about `C-u'", above).

But wrt what you say: Yes, `C-u' is passed through regardless of whether the
command is a "scrolling" command.  I do not put property `isearch-scroll' (or
`scroll-command') on command `icicle-search-w-isearch-string'.  And it works.

But what is important (to me) is that users must turn on `isearch-allow-scroll'
to enable the `C-u' pass-through.  They should not have to.  I myself do not
want scrolling within Isearch (I want `C-v' to exit Isearch, for example), yet I
want to be able to use `C-u S-TAB' from within Isearch.

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

One person's horrible kludge is another's feature. ;-)

But as I say, I personally don't have a need (so far) for command pass-through.
`C-u' pass-through would be enough, for me.

The point here was that the code _already_ is general and not in any way limited
to "scrolling", in spite of the "scrolling" vocabulary used to describe it.
Nothing prevents a "scrolling command" (that is, a command with property
`isearch-scroll') from exiting Isearch - it is up to the command.

> (Every command being adjusted to do this?  

What "every command"?  I'm simply describing what the code already does.  I'm
not describing some wishlist feature.

> What about other uses of the return value?  There are an awful lot of
commands)

No idea what you're on about here.  I think you have perhaps misunderstood me.

> > 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"?

No, this is still part of (1b): _command_ pass-through, not `C-u' pass-through.

The point of that sentence is to say that _users_ should have the control, not
some library foo.el that might baptise some command `foo' as a "scrolling"
command (i.e., pass-through).

A user should be able to allow pass-through for some commands and not others.
Today, s?he can do that only by allowing all of them (non-nil
`isearch-allow-scroll') and then removing `isearch-scroll' or `scroll-command'
properties from the commands s?he does not want to pass through.

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

I don't think so.  Am I missing something?

(defun foo (arg)
  (interactive "P")
  (isearch-done)
  (message "arg: %S" arg)(sleep-for 2)
  (forward-char 2))

(define-key isearch-mode-map "\C-f" 'foo)

Leave `isearch-allow-scroll' nil.
Now search and hit `C-u C-f'.

AFAICT, the `C-u' exits Isearch.  It is not passed through to `foo'.

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

[Drew Adams]

> > We all agree that the fact that C-u got folded into it is definitely
> > a misfeature in this respect.
> 
> I do not agree with this.  ;-)  The prefix arg is an essential part of
> the command with which one might exit isearch.

I think what Stefan meant here - at least what I would say, is what you already
agreed to:

d>> 2. I would like to see us separate the treatment of a prefix
d>>    arg - whether it gets passed it through to a command or it
d>>    exits Isearch - from the other uses/effects of this option.
a>
a> I agree, that would be a good idea.  It wouldn't take very much work.

IOW, IIUC, you, Stefan, and I have already agreed that passing `C-u' through
would be a good idea, independently of `isearch-allow-scroll' and "scrolling"
commands.

The fact that scrolling commands might always need to _also_ enjoy `C-u'
pass-through is a different matter.  That seems to be what you're saying here.
But that wasn't the point.  The point was that all commands should enjoy the
same `C-u' pass-through privilege - which I believe you've already agreed to.

> > But you still only have one boolean value to control what 
> > commands to pass through.
> 
> This isn't quite true either.  The current isearch-scroll 
> property must be t (not merely non-nil) at the moment.  This
> leaves other non-nil values to specify other behaviour.  This
> was deliberate.

Well, OK.  Today it's a Boolean.  Tomorrow it could let you specify more.

That was one of my points: let's let it let you specify just which commands (or
categories of commands) Isearch should pass through.

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

[Alan Mackenzie]

Hi, Drew.

On Sat, Sep 10, 2011 at 09:43:23AM -0700, Drew Adams wrote:
> > 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.

> Well, yes and no.  Yes, in general Isearch tries to prevent exit.

Dash it, Drew, you can try a man's patience.  It was me who programmed
the device, me who first used "scrolling command", so I get to define
what it means.  I know you don't like the term, but if you can't bring
yourself to use it as I've defined it, please suggest another term for
it.  If we can't agree on terminology, then there's not much point trying
to carry out a discussion.

> But if a command wants to exit, it can do so:

> (defun foo ()
>   (interactive)
>   (isearch-done)
>   (message "WWWWWWWW")(sleep-for 2)
>   (forward-char 2))

> That's what I do now, to exit Isearch and invoke Icicles search.  In this case,
> I use only `C-u' pass-through, not command pass-through.

I'm kind of with Stephen at the moment.  What exactly do you mean by
"command pass-through"?

> ;; Bound to `S-TAB' in Isearch.

OK.  Things bound in the isearch-mode-map are a different kettle of fish
entirely from scrolling commands.

> (defun icicle-search-w-isearch-string (&optional use-context-p)
>   (interactive "P")
>   (isearch-done)
>   (if (not use-context-p)
>       (icicle-search (point-min) (point-max)
>                      (icicle-isearch-complete-past-string) t)
>     (let ((regexp  (icicle-search-read-context-regexp)))
>       (kill-new (icicle-isearch-complete-past-string))
>       (icicle-search (point-min) (point-max) regexp t))))

[ .... ]

> > I'm not sure what you mean by this.

> It's a detail - not important.  IMO, it might be better to put this kind of code
> at the place where the command is defined, and not in isearch.el:
> (put 'recenter 'isearch-scroll t)
> But I certainly won't argue the point.

Ah right, got you.  I thought you were talking about the executable code
dealing with the property, not the setting of it.

> > Their "isearch behaviour" is part of isearch.  These commands
> > operate precisely the same way, regardless of
> > whether they're called from isearch or not.

> The fact that you want some particular command to not exit Isearch is part of
> the behavior you want for _that command_.

I couldn't disagree more, if we're talking about something like
`recenter-top-bottom'.  If we're talking about a command bound in
isearch-mode-map, like `icicle-s-w-i-s', then yes.

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

> You changed the subject.  (1b) is about passing a _command_ through, not passing
> `C-u' through (see: "forgetting about `C-u'", above).

I don't know what you mean.  What is passing a command through what to what?

> But what is important (to me) is that users must turn on `isearch-allow-scroll'
> to enable the `C-u' pass-through.  They should not have to.  I myself do not
> want scrolling within Isearch (I want `C-v' to exit Isearch, for example), yet I
> want to be able to use `C-u S-TAB' from within Isearch.

We're agreed on this point.  My patch was trying to achieve that.

> The point here was that the code _already_ is general and not in any way limited
> to "scrolling", in spite of the "scrolling" vocabulary used to describe it.
> Nothing prevents a "scrolling command" (that is, a command with property
> `isearch-scroll') from exiting Isearch - it is up to the command.

The definition of "scrolling command" prevents it.  It would be
profoundly bad programming practice for a random command to manipulate
the internals of isearch.  For a command on the isearch-mode-map (which
cannot be a "scrolling command") it's a different matter.

[ .... ]

> The point of that sentence is to say that _users_ should have the control, not
> some library foo.el that might baptise some command `foo' as a "scrolling"
> command (i.e., pass-through).

> A user should be able to allow pass-through for some commands and not others.

Why?  With the exception of the prefix-arg commands, you haven't made any
strong case for this.  Can you give an example of two scrolling commands,
one of which a user would strongly want, the other strongly not want?

> Today, s?he can do that only by allowing all of them (non-nil
> `isearch-allow-scroll') and then removing `isearch-scroll' or `scroll-command'
> properties from the commands s?he does not want to pass through.

That is surely enough.  I can't conceive of any situation where the
binary choice is inadequate.  What commands might a user want to separate
out?

> > Try out this patch; I think it does what you want.

> I don't think so.  Am I missing something?

No.  I must have been missing something.

> (defun foo (arg)
>   (interactive "P")
>   (isearch-done)
>   (message "arg: %S" arg)(sleep-for 2)
>   (forward-char 2))

> (define-key isearch-mode-map "\C-f" 'foo)

> Leave `isearch-allow-scroll' nil.
> Now search and hit `C-u C-f'.

> AFAICT, the `C-u' exits Isearch.  It is not passed through to `foo'.

OK.  It was worth a try.  :-)

Anyhow, we're in feature freeze at the moment, so until Emacs 24 is split
off onto a branch, there's nowhere for fresh code to go.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[PJ Weisberg]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Saturday, September 10, 2011, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Drew.
>
> On Sat, Sep 10, 2011 at 09:43:23AM -0700, Drew Adams wrote:
>> > 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.
>
>> Well, yes and no.  Yes, in general Isearch tries to prevent exit.
>
> Dash it, Drew, you can try a man's patience.  It was me who programmed
> the device, me who first used "scrolling command", so I get to define
> what it means.  I know you don't like the term, but if you can't bring
> yourself to use it as I've defined it, please suggest another term for
> it.  If we can't agree on terminology, then there's not much point trying
> to carry out a discussion.

The problem is that you've defined "scrolling command" to mean something
that has nothing to do with scrolling (i.e., commands which MOST DEFINITELY
DON'T exit isearch).  This leads to ridiculous conclusions such as "C-u
`universal-argument' is a scrolling command in its
own right."

> I'm kind of with Stephen at the moment.  What exactly do you mean by
> "command pass-through"?

Awkward phrasing, but if you read Drew's post it's fairly clear what he
meant:  `C-u' "passes through" if it passes a prefix argument to the next
command (its normal purpose) without exiting isearch.  So, a command "passes
through" if it also works normally without exiting isearch.

-- 

-PJ

[-- Attachment #2: Type: text/html, Size: 1893 bytes --]

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

[Stephen J. Turnbull]

PJ Weisberg writes:

 > The problem is that you've defined "scrolling command" to mean something
 > that has nothing to do with scrolling (i.e., commands which MOST DEFINITELY
 > DON'T exit isearch).

No, that's completely wrong: there must be no buffer changes, no point
movement, some other conditions.  Exiting isearch or not is not part
of the definition of "scrolling command".  The fact that the current
defintion doesn't mention "movement" of anything is a bit odd, indeed,
but such things are occasionally useful.

One might want to define an additional class of commands that satisfy
those restrictions but aren't scrolling commands (ie, adjusting the
position of the window with respect to the buffer).  If so, define the
classes (including adjusting the definition of "scrolling command")
and adjust the code to recognize them.  But:

 > This leads to ridiculous conclusions such as "C-u
 > `universal-argument' is a scrolling command in its own right."

`universal-argument' is a meta-command, of which there are very few,
so adding it (and other such meta-commands) ad hoc to "scrolling
commands" might be the pragmatic way to handle it.

What other commands conform to the restrictions that Alan stated?  Of
those, which would you like to add to the class that inhibit isearch's
normal exit behavior?  Are there whole classes of them that users
would like to enable (or disable!) as a group, or a bunch of isolated
commands that different users are likely to express varied willingness
to enable them?

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

[Drew Adams]

> > Well, yes and no.  Yes, in general Isearch tries to prevent exit.
> 
> Dash it, Drew, you can try a man's patience.  It was me who programmed
> the device, me who first used "scrolling command", so I get to define
> what it means.  I know you don't like the term,

I have nothing against the term.  If that's what it does.

My (minor/FYI/heads-up) about the terminology was simply this: I don't think
that the code actually enforces anything about scrolling.  I understand that
scrolling was the motivation and is still your intention.  But IIUC (and I could
be wrong) the actual behavior does not look at scrolling - it looks only at
whether a given command has the property `isearch-scroll' or `scroll-command'.

> but if you can't bring yourself to use it as I've defined it,
> please suggest another term for it.

I suggested a few alternatives, actually, and I even gave a nod to one that ST
suggested (although I don't think it is accurate).

But I don't really care about this.  Call it what you like.

> If we can't agree on terminology, then there's not much 
> point trying to carry out a discussion.

So let's agree.  You win.  And in fact I've used your terminology since the
beginning, although I did put it in quotes: "scrolling command".
 
> > But if a command wants to exit, it can do so:
> 
> > (defun foo ()
> >   (interactive)
> >   (isearch-done)
> >   (message "WWWWWWWW")(sleep-for 2)
> >   (forward-char 2))
> 
> > That's what I do now, to exit Isearch and invoke Icicles 
> > search.  In this case, I use only `C-u' pass-through, not
> > command pass-through.
> 
> What exactly do you mean by "command pass-through"?

I mean that I do not put property `isearch-scroll' or `scroll-command' on my
command, so it does not get treated as a "scrolling command".

What I do do is take advantage of the fact that if `isearch-allow-scroll' is
non-nil then a command invoked from Isearch can have a prefix arg passed to it
(instead of exiting Isearch).

And what I am asking for is to let users take advantage of this "`C-u'
pass-through" _without_ also having to set `isearch-allow-scroll' to non-nil and
consequently open the flood gates to scrolling within Isearch.

IOW, I want to be able to pass a prefix arg to a command that I invoke from
Isearch, without having to allow scrolling.  End of story - you can forget the
rest if it's distracting you from that request.

> > ;; Bound to `S-TAB' in Isearch.
> 
> OK.  Things bound in the isearch-mode-map are a different 
> kettle of fish entirely from scrolling commands.

That's the kettle I'm actually interested in, personally.

> > (defun icicle-search-w-isearch-string (&optional use-context-p)
> >   (interactive "P")
> >   (isearch-done)
> >   (if (not use-context-p)
> >       (icicle-search (point-min) (point-max)
> >                      (icicle-isearch-complete-past-string) t)
> >     (let ((regexp  (icicle-search-read-context-regexp)))
> >       (kill-new (icicle-isearch-complete-past-string))
> >       (icicle-search (point-min) (point-max) regexp t))))
> 
> > > Their "isearch behaviour" is part of isearch.  These commands
> > > operate precisely the same way, regardless of
> > > whether they're called from isearch or not.
> 
> > The fact that you want some particular command to not exit 
> > Isearch is part of the behavior you want for _that command_.
> 
> I couldn't disagree more, if we're talking about something like
> `recenter-top-bottom'.  If we're talking about a command bound in
> isearch-mode-map, like `icicle-s-w-i-s', then yes.

Well, we can disagree.  And to me it's a detail, anyway.  If it were I, I would
specify `recenter-top-bottom's Isearch behavior, etc. at the place where the
command is defined.  And to me it doesn't matter which keymap(s) (if any) the
command is bound in.

I gave the analogy of thing-at-point behavior.  Another analogy is
`delete-selection' behavior.

Sure, delete-selection behavior is currently specified for some commands in
delsel.el, and thing-at-point behavior is specified for some thing types in
thingatpt.el.  But if you want to specify such behavior for your command `toto',
are you going to perform surgery on delsel.el, isearch.el, and thingatpt.el?
No, you're probably going to add the `put's that specify such behavior to your
library toto.el.  That's all.

And I would probably just organize things like that from the start - if it were
I.  But I'm not saying that Emacs needs to move such `put's out of delsel.el,
isearch.el, etc. and into the libraries that define the commands whose behavior
those `put's help contribute to defining.  Let's forget about this disagreement.

> > > > > > 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.
> 
> > You changed the subject.  (1b) is about passing a _command_ 
> > through, not passing `C-u' through (see: "forgetting about `C-u'", above).
> 
> I don't know what you mean.  What is passing a command 
> through what to what?

Forget the expression, if it's not clear.  What I meant was applying property
`isearch-scroll' or `scroll-command' to a command's symbol.  The resultant
behavior is what I was calling command pass-through.

It is something different from the `C-u' "pass-through" that happens _without_
using such a property, just by setting option `isearch-allow-scroll' to non-nil.

I suppose I should not have tried to talk about both features in the same mail,
but in my defense it is not I who mixed these two different creatures together.
;-)  I tried to distinguish them and address each of them separately, but
apparently I did not succeed in making myself clear.

> > But what is important (to me) is that users must turn on 
> > `isearch-allow-scroll' to enable the `C-u' pass-through.
> > They should not have to.  I myself do not
> > want scrolling within Isearch (I want `C-v' to exit 
> > Isearch, for example), yet I want to be able to use
> > `C-u S-TAB' from within Isearch.
> 
> We're agreed on this point.  My patch was trying to achieve that.

I'm glad we agree on the one thing I really care about.  The rest was meant
mainly as an FYI that I think things could be cleaned up a bit - but I don't
really care if they are.

> > Nothing prevents a "scrolling command" (that is, a command 
> > with property `isearch-scroll') from exiting Isearch - it is up
> > to the command.
>
> The definition of "scrolling command" prevents it.

What part of my `foo' example above (not the one below) was not clear?  Try it.
Put property `isearch-scroll' on `foo' (making it a "scrolling command" in your
eyes), bind `foo' to a global key (e.g. (global-set-key "\C-f" 'foo)), and
invoke it from Isearch.  For me it exits with no problem.  What am I missing?
Where's the mysterious prevention?

> It would be profoundly bad programming practice for a random command
> to manipulate the internals of isearch.  For a command on the
> isearch-mode-map (which cannot be a "scrolling command") it's a
> different matter.

Well, I won't argue it strongly, but I disagree.  The feature that you so much
wanted to add to Isearch for scrolling commands might just as well be used by
some other command that does something just as benign.  But you would anyway no
doubt see any such command through scrolling-colored glasses, and baptize it
kosher (ouch! sorry for such a meta4mix).

> > A user should be able to allow pass-through for some 
> > commands and not others.
> 
> Why?  With the exception of the prefix-arg commands, you 
> haven't made any strong case for this.  Can you give an
> example of two scrolling commands, one of which a user would
> strongly want, the other strongly not want?

No, sorry, I just don't care.  The only case I really care about is the
prefix-arg behavior.

If you don't see that the current code is not really about scrolling (or, if you
prefer, if I don't see that it really IS only about scrolling), then that's OK
with me - let's leave it at that.  We agree about the important part: free
`C-u'!

> > Today, s?he can do that only by allowing all of them (non-nil
> > `isearch-allow-scroll') and then removing `isearch-scroll' 
> > or `scroll-command' properties from the commands s?he does not
> > want to pass through.
> 
> That is surely enough.  I can't conceive of any situation where the
> binary choice is inadequate.  What commands might a user want 
> to separate out?

Dunno, Alan.  And don't care.  If there is some user who wants to allow
`recenter' but not `scroll-up' I guess we'll never know.  You obviously like to
allow the whole lot, and I like to disallow the whole lot.  And as I said, I
don't foresee my defining any "scrolling" commands that I will want to allow in
Isearch, so we can leave it as is.

> > > Try out this patch; I think it does what you want.
> > I don't think so.  Am I missing something?
> No.  I must have been missing something.
> 
> > (defun foo (arg)
> >   (interactive "P")
> >   (isearch-done)
> >   (message "arg: %S" arg)(sleep-for 2)
> >   (forward-char 2))
> > (define-key isearch-mode-map "\C-f" 'foo)
> 
> > Leave `isearch-allow-scroll' nil.
> > Now search and hit `C-u C-f'.
> 
> > AFAICT, the `C-u' exits Isearch.  It is not passed through to `foo'.
> 
> OK.  It was worth a try.  :-)

And thanks for the try.  I'm glad we agree that this is desirable.

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

[Alan Mackenzie]

Hi, Drew,

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

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

Here's a better patch.  I've tested it more than the previous attempt.


*** isearch.el	2011-09-04 15:31:05.000000000 +0000
--- isearch.100911.el	2011-09-11 10:26:12.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,1981 ----
  	   (apply 'isearch-unread keylist)
  	   (isearch-edit-string))
            ;; Handle a scrolling function.
!           ((progn
! 	     (setq key (isearch-reread-key-sequence-naturally keylist)
! 		   keylist (listify-key-sequence key)
! 		   main-event (aref key 0))
! 	     (or (and isearch-allow-scroll
! 		      (setq scroll-command (isearch-lookup-scroll-key key)))
! 		 (let (overriding-terminal-local-map)
! 		   (setq scroll-command (key-binding key))
! 		   (memq scroll-command
! 			 '(universal-argument negative-argument 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).

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

[Drew Adams]

> > 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.
> 
> Here's a better patch.  I've tested it more than the previous attempt.

Thank you, Alan.  Seems to work.

Even works with a sequence such as `C-1 C-- C-2', which passes -12 as it should,
but which is relatively unknown.  I tested this case because I noticed that you
did not include `universal-argument-minus' in your test. But that is covered OK
anyway, I guess because of the default ([t]) binding for
`universal-argument-other-key'.

Can this patch please be installed?  Or are there people who prefer that `C-u'
exit Isearch?  If there are, then can we please have a user option for this
choice?

Thx.

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

[Alan Mackenzie]

Hi, Drew.

On Sun, Sep 11, 2011 at 09:54:17AM -0700, Drew Adams wrote:
> > > 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.

> > Here's a better patch.  I've tested it more than the previous attempt.

> Thank you, Alan.  Seems to work.

Great stuff!

> Even works with a sequence such as `C-1 C-- C-2', which passes -12 as it should,
> but which is relatively unknown.  I tested this case because I noticed that you
> did not include `universal-argument-minus' in your test. But that is covered OK
> anyway, I guess because of the default ([t]) binding for
> `universal-argument-other-key'.

`univeral-argument-minus' isn't used anymore.  The C-- is now handled by
`negative-argument'.

> Can this patch please be installed?  Or are there people who prefer that `C-u'
> exit Isearch?  If there are, then can we please have a user option for this
> choice?

Here's another version of the patch, this time with
`isearch-allow-prefix'.  Its doc string isn't all that great; perhaps you
can improve it.

As for installing it, it's fine by me, but you'd have to negotiate with
Stefan, since we're in feature freeze.  Before installing, there really
ought to be a mention of the feature in the Emacs manual.

As a matter of interest, the code does assume scrolling, sort of.  After
a "scrolling command" the code checks that the search string is within
the window, and scrolls it back in if it isn't.

> Thx.


*** isearch.el	2011-09-04 15:31:05.000000000 +0000
--- isearch.100911.el	2011-09-11 17:14:27.000000000 +0000
***************
*** 1817,1822 ****
--- 1817,1830 ----
    :type 'boolean
    :group 'isearch)
  
+ (defcustom isearch-allow-prefix nil
+   "Whether prefix arguments are allowed during incremental search.
+ If non-nil, entering a prefix argument will not terminate the
+ search.  This option is ignored \(presumed t) when
+ `isearch-allow-scroll' is set."
+   :type 'boolean
+   :group 'isearch)
+ 
  (defun isearch-string-out-of-window (isearch-point)
    "Test whether the search string is currently outside of the window.
  Return nil if it's completely visible, or if point is visible,
***************
*** 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
--- 1974,1991 ----
  	   (apply 'isearch-unread keylist)
  	   (isearch-edit-string))
            ;; Handle a scrolling function.
!           ((progn
! 	     (setq key (isearch-reread-key-sequence-naturally keylist)
! 		   keylist (listify-key-sequence key)
! 		   main-event (aref key 0))
! 	     (or (and isearch-allow-scroll
! 		      (setq scroll-command (isearch-lookup-scroll-key key)))
! 		 (and isearch-allow-prefix
! 		      (let (overriding-terminal-local-map)
! 			(setq scroll-command (key-binding key))
! 			(memq scroll-command
! 			      '(universal-argument
! 				negative-argument 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).

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

[Drew Adams]

> `univeral-argument-minus' isn't used anymore.  The C-- is now 
> handled by `negative-argument'.

Huh?

(defvar universal-argument-map
  (let ((map (make-sparse-keymap)))
    ...
    (define-key map [?-] 'universal-argument-minus)
    ...
    (define-key map [kp-subtract] 'universal-argument-minus)
    ...))

> > Can this patch please be installed?  Or are there people 
> > who prefer that `C-u' exit Isearch?  If there are, then can
> > we please have a user option for this choice?
> 
> Here's another version of the patch, this time with
> `isearch-allow-prefix'.  Its doc string isn't all that great; 
> perhaps you can improve it.

I suggest "prefix-arg", not just "prefix", in the option name.  There are lots
of prefixes of different kinds in Emacs.

I suggest that the default value allow `C-u' pass-through, not prevent it.  It
sounded like those weighing in so far on this all agreed that this should be the
(new) behavior.

I suggest turning it around: `isearch-prefix-arg-terminates' or
`isearch-prefix-arg-terminates-search' (with default value nil, allowing
pass-through).  Easier to document, for one thing:

"Non-nil means that a prefix argument terminates search.
 Ignored (treated as nil) if `isearch-allow-scroll' is non-nil."

To me that's simpler and clearer.  (It is misleading to say that a prefix arg is
"allowed" - it is always allowed.  The question is whether it gets passed to the
command or it terminates search immediately.)

Putting it this way also leaves open the possibility that termination might
still occur if the value is nil (e.g. if the command itself chooses to exit).
IOW, nil does not definitively prevent termination. (Yes, I know, it is not the
`C-u' but the command that would terminate.  Still, it's clearer not to state
that a nil value prevents termination.)

> As for installing it, it's fine by me, but you'd have to 
> negotiate with Stefan, since we're in feature freeze.

Nothing to negotiate.  He and Yidong can decide based on what's already been
discussed.

> Before installing, there really ought to be a mention of the
> feature in the Emacs manual.

Dunno about that.  But if the new behavior is to allow `C-u' pass-through, then
this would be a user-visible change and should be mentioned in NEWS.

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

[Richard Stallman]

I think C-u should exit isearch.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Alan Mackenzie]

Hi, Richard.

On Sun, Sep 11, 2011 at 10:46:56PM -0400, Richard Stallman wrote:
> I think C-u should exit isearch.

Presumably you'd be OK if the stay-in-isearch behaviour was guarded by
an option (default off)?

In practice, there won't be too much difference, since the C-u will be
applied to the next (non-isearch) command anyway.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

RMS> I think C-u should exit isearch.

Bingo.  Exactly what I suspected:

AM> Need it be an option?  Why not just let C-u through no matter what?
da>
da> Dunno.  That would probably be OK for me, but I can imagine RMS
da> or others chiming in that they are used to having `C-u'
da> immediately exit Isearch.  Having an option means not disturbing
da> the general, traditional behavior.

So much for:

st> it doesn't need to be a customization at first.  Only
st> once it appears that there are many users who do like the
st> behavior, and many who don't, does it need to be a visible
st> customization.

RMS is not "many", but I think the point has been made.  If we allow `C-u'
pass-through then we should also allow users to turn it off.  The next question
is what the default value should be.  I'd vote for pass-through by default, but
I don't feel strongly about that.

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

[Richard Stallman]

    Presumably you'd be OK if the stay-in-isearch behaviour was guarded by
    an option (default off)?

The change will be inconvenient for users in general, not just for me.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Alan Mackenzie]

On Mon, Sep 12, 2011 at 09:39:40PM -0400, Richard Stallman wrote:
>     Presumably you'd be OK if the stay-in-isearch behaviour was guarded by
>     an option (default off)?

> The change will be inconvenient for users in general, not just for me.

I don't think there will be any inconvenience at all.  Unless the user
sets the option, isearch will behave exactly as it has done.

> -- 
> Dr Richard Stallman

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Richard Stallman]

    I don't think there will be any inconvenience at all.  Unless the user
    sets the option, isearch will behave exactly as it has done.

If the default is the current behavior, I guess the other option can't
hurt.  I could not understand from this text

    >     Presumably you'd be OK if the stay-in-isearch behaviour was guarded by
    >     an option (default off)?

what the default would be.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Drew Adams]

>     I don't think there will be any inconvenience at all.  
>     Unless the user sets the option, isearch will behave
>     exactly as it has done.
>
> If the default is the current behavior, I guess the other
> option can't hurt.

As a famous person is wont to say, why not poll the users about the default
behavior?

We can at least discuss it here.  (But the important thing is of course to give
users the option.)

Unlike Richard, I am in favor of passing `C-u' through (e.g. to a command on
`isearch-mode-map') by default, that is, _not_ making it exit Isearch.  Yes,
that would be a change from past behavior.

It would have the advantage that a library can bind a command in
`isearch-mode-map', and its users need not customize the new Isearch option in
order to let that command receive `C-u' during Isearch.  They would not need to
customize anything - the command/key would just work as advertised, including
wrt a prefix arg.

Users of such a library/command have presumably already made the choice to use
it.  Why should the library have to add to the command's doc that if you want to
use a prefix argument with it (in Isearch) then you have to customize option
`isearch-blah'?

Where else do we not allow a command on a keymap to see a prefix arg used with
its key?  Why should this not be the default behavior for Isearch, too?

To me, this is all the more important because, as some have pointed out in the
past, `isearch-mode-map' is already pretty full.  Letting a command bound in
that map use a prefix arg has the effect of putting multiple commands on the
same key, distinguished by the prefix arg.  That's a good thing.

I suspected from the beginning that Richard might want `C-u' to exit Isearch (he
has indicated before that he generally likes Control keys to exit), which is why
I proposed making the behavior fix optional.

Until Richard spoke up, my impression was that the consensus of those speaking
about the issue seemed to be to let `C-u' pass through (not exit Isearch), by
default.  Maybe, maybe not.  At any rate, Alan's first patch presumably tried to
implement that behavior (without any user choice), but when he added the option
in his second patch, he made the default behavior exit Isearch.

It should still be an open question, so far, what the default behavior will be.
The only arguments I've seen are (a) what I say above versus (b) tradition (no
change in the default behavior).  That is essentially (a) providing consistency
with other keymaps versus (a) keeping the same inconsistency we've enjoyed in
the past.

Any other arguments wrt the default value?

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

[Juri Linkov]

> Any other arguments wrt the default value?

Another argument for not exiting isearch with C-u by default
is that some isearch commands accept the C-u argument and change
their behavior accordingly depending on `current-prefix-arg' like
`isearch-yank-char', `isearch-del-char', `isearch-query-replace',
`isearch-query-replace-regexp', `isearch-occur', but currently users
can't use C-u to access their full functionality without customizing
`isearch-allow-scroll' to t.

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

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On 9/13/2011 3:52 PM, Juri Linkov wrote:
>> Any other arguments wrt the default value?
> 
> Another argument for not exiting isearch with C-u by default
> is that some isearch commands accept the C-u argument and change
> their behavior accordingly depending on `current-prefix-arg' like
> `isearch-yank-char', `isearch-del-char', `isearch-query-replace',
> `isearch-query-replace-regexp', `isearch-occur', but currently users
> can't use C-u to access their full functionality without customizing
> `isearch-allow-scroll' to t.
> 

Also, there are plenty of ways to exit isearch other than C-u. I can't
remember ever using C-u to exit isearch, in fact, and if the prefix
argument is still applied to any command that _does_ exit isearch, I see
no problem changing the default behavior.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

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

[Drew Adams]

> Also, there are plenty of ways to exit isearch other than C-u. I can't
> remember ever using C-u to exit isearch, in fact, and if the prefix
> argument is still applied to any command that _does_ exit 
> isearch,

Yes, it is.

> I see no problem changing the default behavior.

Good to hear.

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

[Richard Stallman]

It is not an issue of how many "ways to exit isearch" there are.  It
is an issue of how many commands you need to remember WON'T exit the
search.  The idea of isearch is that control characters exit, except
for a short list of a few.  But that list has been growing.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[PJ Weisberg]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Wednesday, September 14, 2011, Richard Stallman <rms@gnu.org> wrote:
> It is not an issue of how many "ways to exit isearch" there are.  It
> is an issue of how many commands you need to remember WON'T exit the
> search.  The idea of isearch is that control characters exit, except
> for a short list of a few.  But that list has been growing.

But does it make sense to think of C-u as a command in itself?  It's
*always* used in conjunction with another command, which may exit isearch or
not.

-- 

-PJ

[-- Attachment #2: Type: text/html, Size: 617 bytes --]

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

[Drew Adams]

> It is an issue of how many commands you need to remember
> WON'T exit the search.

That there are many commands bound to keys in Isearch is a plus, not a minus -
they are there to make Isearch more useful.

Yes, as in Emacs generally, more key bindings can mean more remembering.  That's
what `C-s C-h' is for.

> The idea of isearch

_The idea of isearch_, or just one of several, possibly competing goals?

> is that control characters exit, except
> for a short list of a few.  But that list has been growing.

That just means that you can do more in Isearch - a good thing.

Yes, having more key bindings means a potential downside of further taxing a
user's memory.  Tradeoff.  No different from any other mode (or pseudo-mode -
Isearch is essentially modal) that binds keys.

At any rate, this feature is not about adding any command/key bindings to the
Isearch default map.  It is about treating Isearch normally wrt a prefix arg.

And you will be able to opt out easily.  Don't you wish you could opt out just
as easily for all the other control keys that no longer exit Isearch? ;-)  At
least here all you have to do is set an option value.

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

[Richard Stallman]

    But does it make sense to think of C-u as a command in itself?  It's
    *always* used in conjunction with another command, which may exit isearch or
    not.

It's a character you can type, which can either exit isearch or not.

I think we already have too many characters that have a special meaning
in Isearch.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Richard Stallman]

    That there are many commands bound to keys in Isearch is a plus, not a minus -
    they are there to make Isearch more useful.

    Yes, as in Emacs generally, more key bindings can mean more remembering.  That's
    what `C-s C-h' is for.

I think you've missed the crucial point about special Isearch commands.

With ordinary Emacs commands, if you don't know about them and you never
use them, they do not affect you.  Thus, there is no drawback to having
thousands of them.

However, when a control character is special in Isearch and you don't
know it, it will bite you.  You will type it while in an Isearch,
expecting it to have its usual meaning, and it will do something else
instead.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[chad]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]


On Sep 17, 2011, at 7:52 PM, Richard Stallman wrote:
> 
> I think you've missed the crucial point about special Isearch commands.
> 
> With ordinary Emacs commands, if you don't know about them and you never
> use them, they do not affect you.  Thus, there is no drawback to having
> thousands of them.
> 
> However, when a control character is special in Isearch and you don't
> know it, it will bite you.  You will type it while in an Isearch,
> expecting it to have its usual meaning, and it will do something else
> instead.

Do you think the usual meaning of C-u is ``exit the modal thing I'm 
doing now''?

The only time I've ever wanted to use C-u in isearch, it either preceded 
a command that would have exited isearch on its own, or I wanted to 
isearch for 6 `-'s, and I did not want it to exit isearch (and was confused 
when it did).

I don't see how a ``user expectation'' argument will ever support making 
C-u exit isearch.  If it's just a matter of a learned interaction, that's 
different.

I hope that helps,
*Chad


[-- Attachment #2: Type: text/html, Size: 1523 bytes --]

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

[Richard Stallman]

    > However, when a control character is special in Isearch and you don't
    > know it, it will bite you.  You will type it while in an Isearch,
    > expecting it to have its usual meaning, and it will do something else
    > instead.

    Do you think the usual meaning of C-u is ``exit the modal thing I'm 
    doing now''?

Please don't attack straw men.  Emacs normally doesn't even have such
"modal things" anyway.  What it normally has is major modes that are
specified in a buffer.

It is not good that we are turning Isearch into something of that
nature by adding so many commands that are special in it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Michael Welsh Duggan]

Richard Stallman <rms@gnu.org> writes:

>     > However, when a control character is special in Isearch and you don't
>     > know it, it will bite you.  You will type it while in an Isearch,
>     > expecting it to have its usual meaning, and it will do something else
>     > instead.
>
>     Do you think the usual meaning of C-u is ``exit the modal thing I'm 
>     doing now''?
>
> Please don't attack straw men.  Emacs normally doesn't even have such
> "modal things" anyway.  What it normally has is major modes that are
> specified in a buffer.
>
> It is not good that we are turning Isearch into something of that
> nature by adding so many commands that are special in it.

Since C-u is always a prefix character, would it make sense to you for
it not to quit isearch if the character that follows a C-u opt/number
prefix is a key sequence that is currently in use by isearch, and for it
to quit Isearch and pass the prefix on to the non-isearch command
otherwise?

In this case, `C-u C-n' would exit isearch and move down 4 lines, whereas
`C-u n' would add four "n"s to the current search string.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

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

[Dani Moncayo]

> Since C-u is always a prefix character, would it make sense to you for
> it not to quit isearch if the character that follows a C-u opt/number
> prefix is a key sequence that is currently in use by isearch, and for it
> to quit Isearch and pass the prefix on to the non-isearch command
> otherwise?
>
> In this case, `C-u C-n' would exit isearch and move down 4 lines, whereas
> `C-u n' would add four "n"s to the current search string.

FWIW: Several people have expressed this idea, with which I agree.
C-u should do nothing by itself (and that includes not exiting
Isearch, of course).  Its only effect should be to provide a prefix
argument to the next command, to extend its behavior.

I hope it helps.

-- 
Dani Moncayo

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

[Stefan Monnier]

> FWIW: Several people have expressed this idea, with which I agree.
> C-u should do nothing by itself (and that includes not exiting
> Isearch, of course).  Its only effect should be to provide a prefix
> argument to the next command, to extend its behavior.

I tend to agree.


        Stefan

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

[Alan Mackenzie]

Hi, everybody.

On Tue, Sep 20, 2011 at 09:59:22PM +0200, Dani Moncayo wrote:
> > Since C-u is always a prefix character, would it make sense to you for
> > it not to quit isearch if the character that follows a C-u opt/number
> > prefix is a key sequence that is currently in use by isearch, and for it
> > to quit Isearch and pass the prefix on to the non-isearch command
> > otherwise?

> > In this case, `C-u C-n' would exit isearch and move down 4 lines, whereas
> > `C-u n' would add four "n"s to the current search string.

Since when has adding four identical characters into a search string been
useful?  Maybe "))))" whilst programming elisp, and there is a (long)
place name in Wales with four consecutive 'l's.  But really?  :-)

> FWIW: Several people have expressed this idea, with which I agree.
> C-u should do nothing by itself (and that includes not exiting
> Isearch, of course).

C-u is bound to a command, namely `universal-argument', and we do our
users a disservice if we try to pretend otherwise.

> Its only effect should be to provide a prefix argument to the next
> command, to extend its behavior.

No.  When in isearch, it first exits isearch and then generates the
prefix argument (4).  It exits isearch like (almost) any other
non-character keysequence does.

What is now going down is that C-u will _sometimes_ exit isearch,
sometimes not.  This is going to leave a squidgy uncomfortable feeling
in the stomach of anybody who thinks about it, yet hasn't explicitly
enabled this behaviour.

isearch-allow-scroll isn't enabled by default, so why should
isearch-enable-prefix, which is almost (but not quite) as radical a
departure from classical Emacs, be?

The anomaly we're stumbling over here is the (almost?) unique status of
isearch as a modal (in the vi sense) behaviour in Emacs.

> I hope it helps.

> -- 
> Dani Moncayo

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Dani Moncayo]

>> FWIW: Several people have expressed this idea, with which I agree.
>> C-u should do nothing by itself (and that includes not exiting
>> Isearch, of course).
>
> C-u is bound to a command, namely `universal-argument', and we do our
> users a disservice if we try to pretend otherwise.

I don't pretend otherwise, at all.  What you say does not conflict
with my point, AFAIU.

>> Its only effect should be to provide a prefix argument to the next
>> command, to extend its behavior.
>
> No.  When in isearch, it first exits isearch and then generates the
> prefix argument (4).  It exits isearch like (almost) any other
> non-character keysequence does.

I'm sorry, but I fail to see the need for C-u to do something (exit
Isearch) prematurely.  As I said, I would be much better to wait for
the "real" command before deciding what to do.  That makes a lot more
sense to me. YMMV.


-- 
Dani Moncayo

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

[chad]

On Sep 21, 2011, at 2:04 AM, Alan Mackenzie wrote:

> Hi, everybody.
> 
> Since when has adding four identical characters into a search string been
> useful?  Maybe "))))" whilst programming elisp, and there is a (long)
> place name in Wales with four consecutive 'l's.  But really?  :-)

As I mentioned, my actual experience with emacs:

	I've tried to use it to isearch for strings of several `-' characters (which 
	were basically record separators), and was surprised when C-u quit 
	isearch. The case I mentioned uses 6 `-'s; the other cases I see (less
	frequently lately) use either 33 `-'s or 66 `;'s.

	I've never wanted C-u to quit isearch. 

Richard commented that special-casing C-u might turn isearch into a 
`modal thing' (my term). I think the majority of people believe that it
has always been such a thing, and that is its primary value.

Perhaps there are people who want to be able to exit isearch by inserting 
a number of identical characters at point, but it certainly seems strange
to me (hardly surprising, since I already said I was unpleasantly surprised
by it).

I hope that helps,
*Chad

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

[Drew Adams]

AFAICT, we are all agreed with the proposal to put this under user control, by
providing an option.

Richard (and possibly others?) disagrees that the default value of the option
should let `C-u' pass through - he prefers that the default value exit Isearch.
But he has agreed with giving users the option.

At this point, my concern is that we get the option into Emacs now, regardless
of the default value.

Can we please commit Alan's patch before the pretest?  Use whatever default
value you want, but let's please let users control this now.  Thx.

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

[Richard Stallman]

    > In this case, `C-u C-n' would exit isearch and move down 4 lines, whereas
    > `C-u n' would add four "n"s to the current search string.

That would be useful once in a blue moon, and annoying more often.
There are probably people who expect C-u n to exit the search and
insert 4 n's.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Richard Stallman]

    > FWIW: Several people have expressed this idea, with which I agree.
    > C-u should do nothing by itself (and that includes not exiting
    > Isearch, of course).  Its only effect should be to provide a prefix
    > argument to the next command, to extend its behavior.

    I tend to agree.

This reasoning is based on thinking of Isearch as a kind of a mode,
but that's exactly what we should avoid.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Dani Moncayo]

Hi Richard,

>    > FWIW: Several people have expressed this idea, with which I agree.
>    > C-u should do nothing by itself (and that includes not exiting
>    > Isearch, of course).  Its only effect should be to provide a prefix
>    > argument to the next command, to extend its behavior.
>
>    I tend to agree.
>
> This reasoning is based on thinking of Isearch as a kind of a mode,
> but that's exactly what we should avoid.

My reasoning goes beyond Isearch.  It is a way of thinking about C-u
as a universal command which always does exactly the same thing:
Collect a numeric prefix argument for the next command to process, and
do nothing beyond that.


-- 
Dani Moncayo

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

[Drew Adams]

>     > FWIW: Several people have expressed this idea, with 
>     > which I agree.  C-u should do nothing by itself (and
>     > that includes not exiting Isearch, of course).  Its
>     > only effect should be to provide a prefix
>     > argument to the next command, to extend its behavior.
> 
>     I tend to agree.
> 
> This reasoning is based on thinking of Isearch as a kind of a mode,
> but that's exactly what we should avoid.

What we "should avoid", if anything, is preventing a command bound in
`isearch-mode-map' from receiving a prefix arg, i.e., making `C-u' always exit
Isearch.

Let's not get into how modal Isearch really is or should be - it's not necessary
(or very useful) here.

You would agree that it is possible for out-of-the-box Emacs, and for users, to
bind commands to keys in `isearch-mode-map'.  Whether Isearch is or should be
truly modal is not as important as letting those commands act normally -
including receiving a prefix arg.

You can bind keys in the map to commands that exit Isearch, and you can bind
keys to commands that do not choose to exit Isearch - no problem.  But why
should a command bound in the Isearch keymap not even receive its prefix arg and
decide its own fate?  You have your preference, and we can agree to disagree
about this.

You want `C-u' to exit Isearch and I do not want it to.  I want to let the
command it precedes ("prefix") decide, as always in Emacs.  Some might agree
with you; others might agree with me.

More importantly, I think you have already agreed to giving _users_ the choice,
via an option.

Let's decide which behavior should be the default (have `C-u' exit Isearch or
not), and let's add an option to let users override that default behavior.  End
of story.

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

[Stephen J. Turnbull]

Richard Stallman writes:
 >     > FWIW: Several people have expressed this idea, with which I agree.
 >     > C-u should do nothing by itself (and that includes not exiting
 >     > Isearch, of course).  Its only effect should be to provide a prefix
 >     > argument to the next command, to extend its behavior.
 > 
 >     I tend to agree.
 > 
 > This reasoning is based on thinking of Isearch as a kind of a mode,
 > but that's exactly what we should avoid.

Why?  That's like saying, "thinking of Shovel as a kind of a digging
implement" is exactly what we should avoid!  I am not saying we should
have gratuitious modality in Emacs.  I'm saying that if we have
unavoidable modality, we should not kid ourselves.  In the present
Isearch implementation, I see no way to disabuse users of the naive
intuition that one "enters" and "exits" Isearch.  The minibuffer
activates and deactivates, and so does an idiosyncratic form of
highlighting in the buffer.  The behavior of the minibuffer is itself
changed, since the cursor does *not* jump to the minibuffer as it
normally does.  Normally self-inserting characters become motion
commands.  If that last is not modal, what is?

In any case, my own intuition happens to be the opposite of yours.  I
see the *current* behavior of C-u as being very much affected by the
modality of Isearch, and it bothers me.  When I type C-u in any other
situation, Emacs quietly waits until I type something else.  It does
not immediately make any perceptible change to the Emacs environment.
But when using Isearch, C-u visibly disturbs state, ie, the state of
the search.

From this point of view, the whole point of Alan's changes (and of
Drew's suggestion as well) is to *reduce* the modality of isearch.
With Alan's option *on*, scrolling commands now work as they do
elsewhere in Emacs: the visible portion of the buffer at hand changes,
without disturbing the state of the buffer or the search.  With
Drew's option *on*, C-u now works as it does elsewhere in Emacs,
providing additional context to the next command, without disturbing
the state of the buffer or the search.

It seems to me that both of these changes make Emacs as a whole less
modal, not more so.  And I agree that making Emacs less modal is a
good thing.

As for the other bindings in isearch-mode, I agree that even the
relatively few we have now do increase the modality of Isearch, and
I'm of mixed feelings about almost all of them (especially C-w and
C-y, which are both most useful to me personally, but also require the
most effort of me to overcome muscle memory).  However, I see such
bindings as a very different issue from the more subtle changes of
which Alan and Drew wish to avail themselves.

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

[Richard Stallman]

     > This reasoning is based on thinking of Isearch as a kind of a mode,
     > but that's exactly what we should avoid.

    Why?  That's like saying, "thinking of Shovel as a kind of a digging
    implement" is exactly what we should avoid!

"Digging implement" describes a purpose.  The purpose of Isearch is
searching; if you called it a "searching feature", that would be
undeniable, and the analogy to "digging implement" would be valid.

Whether something is a mode is a question about how people understand
its interface.

Isearch is not supposed to be a mode.  It is supposed to be a command
which searches for the printing character string you type, and you can
edit the search string in simple limited ways.  Unrelated editing
commands end searcch and do their normal editing.

The only control characters that originally didn't exit the Isearch
were C-r and C-s -- which are the commands to enter Isearch.

Then I added M-y, which was ok because M-y would always be an error if
it exited an Isearch (since the previous command was not a yank).

But then people started making other commands special, destroying the
clear simplicity.  As a result of those, Isearch is now more complex
and people start to think of it as a mode.  Thus, they propose changes
that make it more like a mode, and make it even more complex, and even
less of a command that searches for the printing character string you
type.

    >From this point of view, the whole point of Alan's changes (and of
    Drew's suggestion as well) is to *reduce* the modality of isearch.
    With Alan's option *on*, scrolling commands now work as they do
    elsewhere in Emacs: the visible portion of the buffer at hand changes,
    without disturbing the state of the buffer or the search. 

I never noticed Alan's proposal, but now that I see what it is, I am
against it.  It is very common to use C-v to exit an Isearch.  This
change would be a painful surprise.

The idea that being in a search is a state that commands "shouldn't
disturb" is the result of thinking of it as a mode.  It is normal
for editing commands to stop searching and edit instead.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Drew Adams]

>     From this point of view, the whole point of Alan's 
>     changes (and of Drew's suggestion as well) is to *reduce*
>     the modality of isearch.  With Alan's option *on*, scrolling
>     commands now work as they do elsewhere in Emacs: the visible
>     portion of the buffer at hand changes, without disturbing the
>     state of the buffer or the search. 
> 
> I never noticed Alan's proposal, 

Alan's "proposal" wrt scrolling is not a proposal.  It has been part of Emacs
since 2003/2/24, according to a comment in isearch.el.  Blame its admission on
the Emacs maintainer back then, I guess. ;-)

> but now that I see what it is, I am
> against it.  It is very common to use C-v to exit an Isearch.  This
> change would be a painful surprise.

It is a user _option_, and by default the behavior is the one you prefer.
(FWIW, I prefer the same behavior as you for this: `C-v' exits Isearch.)

> The idea that being in a search is a state that commands "shouldn't
> disturb" is the result of thinking of it as a mode.  It is normal
> for editing commands to stop searching and edit instead.

And editing commands are perfectly free to do that.  No one says that commands
"shouldn't disturb" searching.

And commands do so and will continue to do so, even with the new proposal wrt
`C-u'.  Such commands are not bound to keys in `isearch-mode-map', so they will
exit Isearch (and take their `C-u' with them. ;-)).

This is about creating a user _option_ to allow commands that are bound to keys
in `isearch-mode-map' to receive the prefix arg that a user tries to give them.
That's all.

And you have already agreed to adding this option.
What remains to decide is the default value of the option.

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > Whether something is a mode is a question about how people understand
 > its interface.

Indeed.  Guess what?  My fingers use isearch as you originally
intended; I don't use *any* non-printing characters to invoke isearch-
specific commands except C-s, C-r, BKSP, and RET (you missed those
last two, I think they have always been available with isearch-
specific behavior).  Nevertheless, I *understand* isearch as modal.

 > It is normal for editing commands to stop searching and edit
 > instead.

You made an exception for BKSP.  That one bothers me a lot.  Much of
the time, it "should" stop searching and edit the buffer, but it
doesn't.  Of course, there's no way for Emacs to know which I meant,
so I have to accept that modality.  OTOH, it would be abnormal for RET
to stop searching and self-insert; its current meaning of "accept the
search (= just stay at the found text)" is just right.  Those two
keystrokes alone are enough to evoke a perception of modality in me.

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

[Alan Mackenzie]

Hi, Richard.

On Wed, Sep 21, 2011 at 04:48:40PM -0400, Richard Stallman wrote:

> Whether something is a mode is a question about how people understand
> its interface.

> Isearch is not supposed to be a mode.  It is supposed to be a command
> which searches for the printing character string you type, and you can
> edit the search string in simple limited ways.  Unrelated editing
> commands end searcch and do their normal editing.

> The only control characters that originally didn't exit the Isearch
> were C-r and C-s -- which are the commands to enter Isearch.

Yes.  But such a "feature pure" Isearch wouldn't serve users' needs very
well, particularly in such a rich environment as Emacs.

> Then I added M-y, which was ok because M-y would always be an error if
> it exited an Isearch (since the previous command was not a yank).

Ah.  _NOW_ I understand why `isearch-yank-kill' is on M-y.  :-)  (At
least, was on M-y.)

> But then people started making other commands special, destroying the
> clear simplicity.  As a result of those, Isearch is now more complex
> and people start to think of it as a mode.  Thus, they propose changes
> that make it more like a mode, and make it even more complex, and even
> less of a command that searches for the printing character string you
> type.

I use Isearching almost constantly, and expect most users do too.   I'd
be unhappy and less productive if its many features (I think I use most
of them) were not there.  In fact, I'd write them if they weren't.  ;-)

>     >From this point of view, the whole point of Alan's changes (and of
>     Drew's suggestion as well) is to *reduce* the modality of isearch.
>     With Alan's option *on*, scrolling commands now work as they do
>     elsewhere in Emacs: the visible portion of the buffer at hand
>     changes, without disturbing the state of the buffer or the search. 

> I never noticed Alan's proposal, but now that I see what it is, I am
> against it.

With all due respect, what you said back in 2003 (on the 1st March) was:
"I have no objections to it if it is disabled by default.".  Then, I
thought it should have been enabled by default.  Now I see that it
shouldn't be.

> It is very common to use C-v to exit an Isearch.  This change would be
> a painful surprise.

It would.  That is why it needs an option setting for this to happen.  I
think that, likewise, `isearch-allow-prefix' should be nil by default.

> The idea that being in a search is a state that commands "shouldn't
> disturb" is the result of thinking of it as a mode.  It is normal
> for editing commands to stop searching and edit instead.

Is scrolling "editing" here?  I would have said no, since it doesn't
change the buffer and doesn't move point.

> -- 
> Dr Richard Stallman

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Richard Stallman]

    Alan's "proposal" wrt scrolling is not a proposal.  It has been part of Emacs
    since 2003/2/24, according to a comment in isearch.el.  Blame its admission on
    the Emacs maintainer back then, I guess. ;-)


    It is a user _option_, and by default the behavior is the one you prefer.
    (FWIW, I prefer the same behavior as you for this: `C-v' exits Isearch.)

Since the default was not change, I have nothing against it.
I may have been the one to approve it, at that period.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Richard Stallman]

    Indeed.  Guess what?  My fingers use isearch as you originally
    intended; I don't use *any* non-printing characters to invoke isearch-
    specific commands except C-s, C-r, BKSP, and RET (you missed those
    last two, I think they have always been available with isearch-
    specific behavior).

RET was originally entered into the search string, and that was
quite useful.

DEL was the only character that edited the search string,
since many programs use DEL to do that.

ESC was the original way to explicitly exit without doing
anything else.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Richard Stallman]

    > The idea that being in a search is a state that commands "shouldn't
    > disturb" is the result of thinking of it as a mode.  It is normal
    > for editing commands to stop searching and edit instead.

    Is scrolling "editing" here?  I would have said no, since it doesn't
    change the buffer and doesn't move point.

You're making a distinction I didn't intend, so we are talking past
each other.

When I said "editing commands" I meant "anything other than inserting
text." The rule is that they exit Isearch.  There have always been
exceptions, but they were few.

The more exceptions there are, the harder it is to remember how to use
Isearch.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[PJ Weisberg]

On Thu, Sep 22, 2011 at 2:44 PM, Richard Stallman <rms@gnu.org> wrote:
>    > The idea that being in a search is a state that commands "shouldn't
>    > disturb" is the result of thinking of it as a mode.  It is normal
>    > for editing commands to stop searching and edit instead.
>
>    Is scrolling "editing" here?  I would have said no, since it doesn't
>    change the buffer and doesn't move point.
>
> You're making a distinction I didn't intend, so we are talking past
> each other.
>
> When I said "editing commands" I meant "anything other than inserting
> text." The rule is that they exit Isearch.  There have always been
> exceptions, but they were few.
>
> The more exceptions there are, the harder it is to remember how to use
> Isearch.

Are you arguing that isearch non-exiting commands shouldn't exist, or
that they shouldn't be able to take a prefix argument?  The former
makes more sense, but having C-u exit isearch only accomplishes the
latter.

-PJ

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

[Richard Stallman]

    Are you arguing that isearch non-exiting commands shouldn't exist, or
    that they shouldn't be able to take a prefix argument?

Neither.  I am saying that the non-printing characters that are exceptions
to the rule should be as few as possible.

(The rule is that they exit Isearch and then execute normally.)

I think the existing exceptions are already so numerous
as to constitute a nuisance.





-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

[Drew Adams]

ping

> This is about creating a user _option_ to allow commands that 
> are bound to keys in `isearch-mode-map' to receive the prefix
> arg that a user tries to give them. That's all.
> 
> And you [RMS] have already agreed to adding this option.
> What remains to decide is the default value of the option.

Everyone in the thread seems to have agreed that the option should be added.
Alan provided patch for it.  Can we have this done in Emacs 24 please?  If you
don't change the default behavior there is no impact on users who do not
customize the option, and the code is essentially the same (no surprises).