bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el

[Gregory Heytings]

> > But you provide the solution: when an xref is followed, the file is 
> > opened in a buffer, at which point buffer-file-coding-system is set. 
> > So it seems that it suffices to do (goto-char (filepos-to-bufferpos 
> > (get-byte-position))).
>
> Yes.  But it can be slow.

Can it become so slow that it would have an impact on user experience? 
filepos-to-bufferpos would be called only when the xref link is followed, 
so I guess that even a 0.1 or 0.2 second delay should be okay.

> > I just did a filepos-to-bufferpos for one of the last bytes of a 6 MB 
> > Latin-1 file, and it took only ~2 ms.
>
> Which value of QUALITY did you use?

I just tried again on a 25 MB Latin-1 file, on one of the last bytes it 
took ~13 ms without specifying a quality.  I tried with nil, 'approximate 
and 'best, but do not see any difference, the result with benchmark-run is 
always ~13 ms.

> Also, what happens with multibyte encodings that are not UTF-8, like 
> iso-2022, for example?

Well, the Latin-1 file is already different from UTF-8.

I don't know anything about ISO-2022, but tried with a 25 MB file, created 
with iconv, which Emacs recognizes as an iso-2022-7bit-dos one.  In that 
case filepos-to-bufferpos does not work at all, with 'approximate you get 
a position that is about 2 million characters away from the correct one, 
and with 'best or nil you get nil...