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

[Eli Zaretskii]

> Date: Thu, 04 Mar 2021 16:47:30 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 46859@debbugs.gnu.org
> 
> > Yes.  But it can be slow.
> 
> Can it become so slow that it would have an impact on user experience? 

I don't know, Grep is a somewhat special application.

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

Yes, 0.1 sec is definitely okay.

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

AFAIR, with single-byte encoding we take a shortcut there.

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

Not 'best, 'exact.  Did you try 'exact?  It should have worked,
barring any bugs.