Re: Isearch setting of inhibit-point-motion-hooks too inflexible

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Richard Stallman]

    The following patch against emacs 21.2 will add a new variable
    `isearch-inhibit-point-motion-hooks' and change `isearch-search' to
    make use of it.

That would solve your problem, but since it is an all-or-nothing
choice, we must expect that people using multiple packages will find
that neither t nor nil gives good results for all of those packages.

I wonder if we can find a solution where a single mode
will work with various packages.  Does someone recall why
isearch currently wants inhibit-point-motion-hooks to be t
if it can match in invisible text?

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Gregor Schmid]

Dear Richard,

Richard Stallman <rms@gnu.org> writes:

>     The following patch against emacs 21.2 will add a new variable
>     `isearch-inhibit-point-motion-hooks' and change `isearch-search' to
>     make use of it.
> 
> That would solve your problem, but since it is an all-or-nothing
> choice, we must expect that people using multiple packages will find
> that neither t nor nil gives good results for all of those packages.

Correct me if I'm wrong, but wouldn't 
(make-local-variable 'isearch-inhibit-point-motion-hooks)
solve this if some mode needs a non-default behavior? I don't think
folding/outline type packages can be combined in one buffer anyway.

Best regards,
    Greg

-- 
Gregor Schmid                           Gregor.Schmid@qfs.de
Quality First Software GmbH                http://www.qfs.de

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Stefan Monnier]

>     The following patch against emacs 21.2 will add a new variable
>     `isearch-inhibit-point-motion-hooks' and change `isearch-search' to
>     make use of it.
> 
> That would solve your problem, but since it is an all-or-nothing
> choice, we must expect that people using multiple packages will find
> that neither t nor nil gives good results for all of those packages.
> 
> I wonder if we can find a solution where a single mode
> will work with various packages.  Does someone recall why
> isearch currently wants inhibit-point-motion-hooks to be t
> if it can match in invisible text?

I think it's for intangible text (i.e. it doesn't just allow to
search in invisible text but also in invisible+intangible).
At least, the code is careful to make text tangible if it wasn't
before.


	Stefan

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Richard Stallman]

    Correct me if I'm wrong, but wouldn't 
    (make-local-variable 'isearch-inhibit-point-motion-hooks)
    solve this if some mode needs a non-default behavior?

If a particular major mode wants a non-default behavior, this would
do it.  But these features are not always major modes.  Can we use
an overlay property to make the decision?

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Stefan Monnier]

>     Correct me if I'm wrong, but wouldn't 
>     (make-local-variable 'isearch-inhibit-point-motion-hooks)
>     solve this if some mode needs a non-default behavior?
> 
> If a particular major mode wants a non-default behavior, this would
> do it.  But these features are not always major modes.  Can we use
> an overlay property to make the decision?

Since this thing is used by isearch in order to look inside
intangible text, I think it should simply be removed:
isearch should *not* look inside intangible text.

As we have discussed in this group at length, `intangible' is a very
strong statement and has far reaching implications.  It should be
used very sparingly.


	Stefan

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Gregor Schmid]

Dear Richard, dear Stefan,

Richard Stallman <rms@gnu.org> writes:
>     Correct me if I'm wrong, but wouldn't 
>     (make-local-variable 'isearch-inhibit-point-motion-hooks)
>     solve this if some mode needs a non-default behavior?
> 
> If a particular major mode wants a non-default behavior, this would
> do it.  But these features are not always major modes.  Can we use
> an overlay property to make the decision?

Possibly. But consider Stefan's comment:

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> Since this thing is used by isearch in order to look inside
> intangible text, I think it should simply be removed:
> isearch should *not* look inside intangible text.
> 
> As we have discussed in this group at length, `intangible' is a very
> strong statement and has far reaching implications.  It should be
> used very sparingly.

My favourite soultion would also be to simply remove any manipulation
of inhibit-point-motion-hooks from isearch-search.

If you decide to leave it in and make it more flexible than with my
suggested patch, e.g. thorugh overlays, please also add a simple
option that just requires setting some variable, so as to keep the
simple case simple. Whatever the solution, anything will be better
than the current totally inflexible scheme.

Thanks for addressing this issue, best regards,
    Greg

-- 
Gregor Schmid                           Gregor.Schmid@qfs.de
Quality First Software GmbH                http://www.qfs.de

Re: Isearch setting of inhibit-point-motion-hooks too inflexible

[Richard Stallman]

    Since this thing is used by isearch in order to look inside
    intangible text, I think it should simply be removed:
    isearch should *not* look inside intangible text.

You might perhaps be right, but I am not convinced.