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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Wed, 20 Jul 2022 08:30:21 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> 
>> Is finding newlines that expensive?  (I don't remember.)
>
> It isn't, but if you have a very large buffer, finding _all_ the
> newlines in it could take time.
>
>> I mean, if someone turns that "mode" on, does he deserve to suffer a
>> little bit while that is switched on?
>
> We want to have this "mode" turned on by default.

Okay.

If that's already determined, I don't need to think about it.

>
>> I think someone with such a long line deserves to suffer.
>
> That's a bootstrap problem: when you first visit a file, you usually
> don't know whether it will have long lines.  By the time you know,
> it's many times too late.  Thus such a feature should ideally be
> active by default, unless it sometimes causes serious problems.

Ideally, right.

What I'm trying to hint at it is that there's another way to see this:

It was mentioned a number of times that only a small fraction of people
encounter that problem.  And I'd add that this small fraction encounters
the problem only in a small fraction of cases.  And I even think most of
these cases are known upfront.

So, with some kind of mode, one could turn the iterator-narrowing on
(and off!) in redisplay_window without affecting anyone who doesn't have
the problem in the first place.

Just wanted to explain that.  No need for discussions.

Previous Next

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