GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Tue, 5 Jul 2022 08:50:02 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Tue, 05 Jul 2022 14:30:08 +0000
>
> I did try this, and it does happen.  Here:
>
>  (with-temp-buffer
>    (insert-file-contents "long-line.xml")
>    (point-max))
>
> (where long-line.xml is the file whose URL I've shown in my message). 
> This gives me 30001, whereas the correct value is 306666.
>

That's of course not what I meant with "in practice".  What I meant is: 
are there actual uses of "(with-temp-buffer (insert-file-contents ..." 
which insert actual files with sufficiently long lines?  Such files are 
not so common.  As I said, if that's the case, it's easy to add a "(let 
((auto-narrow-long-line-threshold nil))" around the code, in this case 
either in the with-temp-buffer macro or in the code above.

>
> I think it will happen quite a lot in the wild.
>

Let's see if it does before reaching a conclusion.

>
> That means the list will be very long and users will have to constantly 
> update it.  E.g., whenever they install a new package or even a new 
> version of a package.
>

Packages can take care of this by themselves, can't they?  When the 
package is loaded, (add-to-list auto-narrow-widen-automatically 
the-package-command).

>>> Also, the automatic restriction is very visible and causes surprising 
>>> effects: (point-min) and (point-max) evaluate to the narrowed region 
>>> (so it's basically very hard to know the real size of the buffer), and 
>>> scrolling through the buffer causes the scroll-bar thumb move in a 
>>> non-monotonic manner: I scroll towards the end of the buffer, but the 
>>> thumb sometimes jumps back up, as if I moved towards the beginning.
>>
>> Indeed.  Users will see the "Auto-Narrow" indication in the modeline 
>> with which they can easily find an explanation for that behavior.  If 
>> this behavior is problematic, it could be fixed by using the dimensions 
>> of the whole buffer when updating the scroll bar (and perhaps also the 
>> modeline), when auto-narrow-mode is active.
>
> I think it should be fixed, yes.
>

Okay, I'll see what I can do.




This bug report was last modified 3 years and 33 days ago.

Previous Next


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