>> Well, this happens only in buffers with long lines, and only when we 
>> are inside a long line
>
> Is the last part really guaranteed?  AFAIU, the detection of long lines 
> scans the entire buffer, so if there's a long line _anywhere_ in the 
> buffer, the narrowing is applied, even if point is in no-so-long lines.
>

That's correct, but the narrowing starts well before the visually first 
element.  So when point is inside a not-so-long line, 
get_visually_first_element will work as usual: it will not stop at a 
narrowed BOB while searching for the visually first element, or IOW it 
will never need to search until the narrowed BOB to do its job.

>
> "As expected" in what sense?  Suppose we really are in a long line, the 
> Isearch match is really outside the window, but if we use point-10000 as 
> BEGV point seems to be _inside_ the window -- in this case the feature 
> implemented in isearch-update for slow terminals will not do its thing, 
> right?
>

I just tried

emacs -Q
(setq search-slow-speed most-positive-fixnum)
C-x C-f dictionary.json
C-s aan zich

and everything worked as expected.

>> Would the following be better from your point of view?
>>
>> [...]
>
> I guess it's better, as it reduces the number of cases where the problem 
> could happen, at the price of making those cases slower.
>

Okay, I'll push that.  It seems to work as well.

>> I understand.  But note that temporarily narrowing the buffer happens 
>> only at a few well-chosen places, which are situated rather low in the 
>> abstraction layers, so the effect on other parts of the code is nil.
>
> I think I agree with everything except the "nil" part ;-)
>

There is alas no "near-nil" value in Elisp. 😉