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

Previous Next

Full log

Message #116 received at 46859 <at> debbugs.gnu.org (full text, mbox):

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

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

Previous Next

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