bug#56393: Actually fix the long lines display bug

[Gregory Heytings]

> > 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. 😉