* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
[not found] <15803.53742.404653.98167@gs.qfs.de>
@ 2002-10-28 19:20 ` Richard Stallman
2002-10-29 7:46 ` Gregor Schmid
2002-10-29 14:14 ` Stefan Monnier
0 siblings, 2 replies; 7+ messages in thread
From: Richard Stallman @ 2002-10-28 19:20 UTC (permalink / raw)
Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-28 19:20 ` Isearch setting of inhibit-point-motion-hooks too inflexible Richard Stallman
@ 2002-10-29 7:46 ` Gregor Schmid
2002-10-30 17:16 ` Richard Stallman
2002-10-29 14:14 ` Stefan Monnier
1 sibling, 1 reply; 7+ messages in thread
From: Gregor Schmid @ 2002-10-29 7:46 UTC (permalink / raw)
Cc: Gregor.Schmid, emacs-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-28 19:20 ` Isearch setting of inhibit-point-motion-hooks too inflexible Richard Stallman
2002-10-29 7:46 ` Gregor Schmid
@ 2002-10-29 14:14 ` Stefan Monnier
1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2002-10-29 14:14 UTC (permalink / raw)
Cc: Gregor.Schmid, emacs-devel
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-29 7:46 ` Gregor Schmid
@ 2002-10-30 17:16 ` Richard Stallman
2002-10-30 18:34 ` Stefan Monnier
2002-10-31 8:23 ` Gregor Schmid
0 siblings, 2 replies; 7+ messages in thread
From: Richard Stallman @ 2002-10-30 17:16 UTC (permalink / raw)
Cc: Gregor.Schmid, emacs-devel
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-30 17:16 ` Richard Stallman
@ 2002-10-30 18:34 ` Stefan Monnier
2002-10-31 17:27 ` Richard Stallman
2002-10-31 8:23 ` Gregor Schmid
1 sibling, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2002-10-30 18:34 UTC (permalink / raw)
Cc: Gregor.Schmid, emacs-devel
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-30 17:16 ` Richard Stallman
2002-10-30 18:34 ` Stefan Monnier
@ 2002-10-31 8:23 ` Gregor Schmid
1 sibling, 0 replies; 7+ messages in thread
From: Gregor Schmid @ 2002-10-31 8:23 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Isearch setting of inhibit-point-motion-hooks too inflexible
2002-10-30 18:34 ` Stefan Monnier
@ 2002-10-31 17:27 ` Richard Stallman
0 siblings, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2002-10-31 17:27 UTC (permalink / raw)
Cc: Gregor.Schmid, emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-10-31 17:27 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <15803.53742.404653.98167@gs.qfs.de>
2002-10-28 19:20 ` Isearch setting of inhibit-point-motion-hooks too inflexible Richard Stallman
2002-10-29 7:46 ` Gregor Schmid
2002-10-30 17:16 ` Richard Stallman
2002-10-30 18:34 ` Stefan Monnier
2002-10-31 17:27 ` Richard Stallman
2002-10-31 8:23 ` Gregor Schmid
2002-10-29 14:14 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).