Re: Simple isearch concerns

[Alan Mackenzie <acm@muc.de>]

Hello, Augusto.

On Thu, Mar 03, 2022 at 17:36:35 +0100, Augusto Stoffel wrote:
> The non-quitting scroll commands in isearch are an extremely useful
> addition.  But I looked at the implementation now and I'm finding it
> problematic.

> At some point it was decided that instead of just defining
> 'isearch-scroll-up' and 'isearch-scroll-down commands', some
> pre-command-hook trickery would be used.  Presumably this is so that an
> user option, 'isearch-allow-scroll', could be provided (that's what I
> gather from the parent message of this email).

This is not quite how the history of this facility was.  (I wrote the
original version back in 2003.)  isearch-allow-scroll was at the centre
of the mechanism right from the beginning.  The idea was that users
could use the same keys for scrolling whilst inside an isearch as in
ordinary editing.  Commands like isearch-scroll-up never came into
consideration.  Originally, the pre-command- and post-command- hooks
weren't used.  They were implemented as a code clean-up some while later
(I think, by Juri Linkov).

> But this has several disadvantages: you can't assign different keys for
> the quitting and non-quitting versions of the scroll commands;

How is that a disadvantage?  To quit and scroll requires RET plus a
scrolling key sequence.  Were we to find new key sequences just for a
quitting version of lots of commands, they would be longer than for the
two distinct commands together.

> you can't put the (nonexistent) isearch-scroll-up/down commands in a
> repeat map; you can't activate the feature selectively, e.g. so that
> scrolling doesn't quit isearch but beginning/end of buffer does;

For this, you can just set the isearch-allow-scroll property to nil for
the commands you want to quit isearch.

> you can't advice or redefine isearch-scroll-up/down, because they
> don't exist;

You can advise the scrolling commands directly, testing for being inside
an isearch if needed.

> it's harder for external package to integrate (I had to copy a piece
> of the isearch-pre-command-hook into isearch-mb.el).

I'm not sure what you mean by "integrate", here: integrate with what, to
what purpose?

> The obvious and natural way to implement this feature would be to define
> isearch-scroll-up/down commands, bind them in the M-s prefix, and let
> whoever wants it by default to rebind the keys.

I think there are around 20 commands which have the
isearch-allow-scroll (or scroll-command) property set.  I have a few
more personal commands, bringing my total to around 30.

> Perhaps it's not too late to fix this.  Sorry I didn't bring this up at
> the time of the discussion.

What is to happen to my 30 scrolling commands?  Would I have to find 30
new key sequences to bind them to?  I wouldn't like that, and I don't
think most users of isearch scrolling would, either.

Could you perhaps be more explicit on what you're trying to do, and why
the current implementation of isearch scrolling makes this difficult?
Maybe there's a way forward which doesn't involve wholesale rewriting.

-- 
Alan Mackenzie (Nuremberg, Germany).