bug#50497: [PATCH] Adding eww-{next,previous,up,top}-path.

[Juri Linkov]

>>> That's also true, so I was sceptical about adding that (because it also
>>> makes `C-s' etc behave sub-optimally in 99.7% of web pages), so I've
>>> been pondering whether to remove it (or at least hide it behind and
>>> option defaulting to "off").
>>
>> But users like it:
>> https://www.reddit.com/r/emacs/comments/9oi1e3/ewws_awesome_isearch_support_just_blew_my_mind/
>
> Yeah, it's a neat trick (which makes people go "ooo").  So disabling it
> would be a shame.  But it does make the user experience slightly worse
> most of the time...
>
> Actually, we could just tweak it -- today it says "repeat for next
> buffer" even if there's no next buffer (it only checks afterwards),
> apparently.  Hm...  Right, if eww only sets
> `multi-isearch-next-buffer-function' when there's a rel=next/prev, then
> this awkwardness disappears.

But still I'd like to make `C-s' less sub-optimal when used
on pages with a rel=next/prev and to fix such complaints:

  "It turns out that this interacts badly with asynchronous loading of
  web pages -- I think the buffer is being searched before the web content
  is loaded, but with local content it's either all managing to happen
  fast enough that the issue doesn't arise, or it's being done in a more
  synchronous manner.  Hopefully this can be addressed, but in the
  meantime you may need to test with local html files."

What do you think about supporting synchronous mode in eww?
When adding a variable that causes eww-retrieve to use
url-retrieve-synchronously, isearch part could look like this:

  (defun eww-isearch-next-buffer (&optional _buffer wrap)
    (let ((eww-synchronous t))
      (if wrap
          (condition-case nil
              (eww-top-url)
            (error nil))
        (if isearch-forward
            (eww-next-url)
          (eww-previous-url))))
    (current-buffer))