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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 46859 <at> debbugs.gnu.org
Subject: bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el
Date: Thu, 04 Mar 2021 19:13:16 +0200

> Date: Thu, 04 Mar 2021 16:47:30 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: 46859 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.