Re: Simple isearch concerns

[Juri Linkov]

>> 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)
>>
>
> I'm not sure this would work, because it's not always (isearch-repeat
> 'forward).  For example with M-v it would be 'backward, regardless of the
> current direction of the search.  So I guess it means that another symbol
> property would be necessary.

A function attached to a symbol could return its search direction.
Indeed, the definitions will be slightly longer, but still this is
better than defining new commands.  So this could look like:

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

> With C-p it's not clear (to me) if it should depend on the current
> direction of the search or not.  Should C-s C-p change the direction to
> a backward search, or move to previous line and restart a forward search?

The same question applies to scroll-up-command and scroll-down-command, e.g.
in a forward search using scroll-up-command should change the direction?

Maybe this preference should be specified by the same your new option
isearch-allow-match-scroll, so when its value is t, then the enabled scrolling
doesn't change the direction.  But it does this when its value is e.g.
'change-direction'.