Re: Simple isearch concerns

[Juri Linkov]

>>> +(put 'beginning-of-buffer 'isearch-match-scroll 
>>> 'isearch-beginning-of-buffer)
>>> +(put 'end-of-buffer 'isearch-match-scroll 'isearch-end-of-buffer)
>>> +(put 'scroll-up-command 'isearch-match-scroll 'isearch-scroll-up)
>>> +(put 'scroll-down-command 'isearch-match-scroll 'isearch-scroll-down)
>>> ...
>>> +     ((and isearch-allow-match-scroll
>>> +           (symbolp this-command)
>>> +           (get this-command 'isearch-match-scroll))
>>> +      (setq this-command (get this-command 'isearch-match-scroll)))
>>
>> As noted in another message, this is basically the same as:
>>
>>  (define-key isearch-mode-map [remap beginning-of-buffer] 
>> 'isearch-beginning-of-buffer)
>>  (define-key isearch-mode-map [remap end-of-buffer] 'isearch-end-of-buffer)
>>  (define-key isearch-mode-map [remap scroll-up-command] 'isearch-scroll-up)
>>  (define-key isearch-mode-map [remap scroll-down-command] 
>> 'isearch-scroll-down)
>
> I'm not sure I understand what you mean by this.  Indeed this can be done
> that way, too, but in that case it isn't a user option anymore, which can
> be easily set and toggled.

If you want a separate option, this is fine.  But then there is no need
to duplicate the key remapping feature.  To make the new feature more powerful,
you could attach to command symbol properties a function that
defines where to move point before searching the next match.

This is similar to how isearch-yank-internal funcalls its arg 'jumpform',
and how its callers like isearch-yank-char uses

  (lambda () (forward-char arg) (point))

or isearch-yank-word uses

  (lambda () (forward-word arg) (point))

to define where to move point before using it as the buffer position.

So command symbol properties could be defined using the same logic:

  (put 'beginning-of-buffer 'isearch-match-scroll 'beginning-of-buffer)
  (put 'end-of-buffer 'isearch-match-scroll 'end-of-buffer)
  (put 'scroll-up-command 'isearch-match-scroll (lambda () (goto-char 
(window-end))))
  (put 'scroll-down-command 'isearch-match-scroll (lambda () (goto-char 
(window-start))))

where the symbol property is called like (funcall 'beginning-of-buffer)
before repeating the search.

Then there is no need to add such ad-hoc commands as isearch-scroll-up
and isearch-scroll-down.

And instead of

  (setq this-command (get this-command 'isearch-match-scroll))

isearch-pre-command-hook could contain the same code
that is currently duplicated in several commands:

  (setq isearch-just-started t)
  (goto-char (window-end))  ;; only this line needs to be
                            ;; replaced with (funcall jumpform)
  (isearch-repeat 'forward)

Whereas it would be easy to handle more commands like below:

>>>>> Should then forward-char be remapped to isearch-repeat to go to the
>>>>> next match?  Then also remap next-line to go to the next line with
>>>>> matches, etc.
>>>>
>>>> Please don't, these commands should exit the search.
>>>
>>> Yes, I also think these commands should exit the search by
>>> default. Users who would like to have that behavior can do so easily
>>> with my patch:
>>>
>>> (put 'next-line 'isearch-match-scroll 'isearch-repeat-forward)
>>
>> Then 'isearch-match-scroll' has nothing to do with scrolling.
>
> It was you who suggested that change, you asked: "Should then forward-char
> be remapped to isearch-repeat to go to the next match?"  Or am
> I misunderstanding something?

Actually, the 'isearch-match-scroll' above doesn't do what is needed.
It just goes to the next match, whereas the need was to go to the next line
before searching for a new match.

With the logic above, this is easy to define like:

  (put 'next-line 'isearch-match-scroll (lambda () (forward-line 1)))