GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
Message #563 received at 56393 <at> debbugs.gnu.org (full text, mbox):
>
> 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.
>
I agree that it's a relatively rare problem, but when it happens it is
very annoying, because Emacs becomes unusable. I disagree, however, that
most of theses cases are known upfront, in most cases a user simply opens
a file that they can open in other editors without setting any specific
option in these other editors, with the expectation that they will be able
to edit it in Emacs. Now the situation is reversed: you can open and edit
files in Emacs that you cannot open and edit in other editors.
>
> 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.
>
What we have right now is a kind of (minimal) mode indeed, which is turned
on automatically when necessary. And from a user point of view it's also
a kind of (minimal) mode, which they can turn off unconditionally by
setting long-line-threshold to nil in their init file, or turn on
unconditionally by setting long-line-threshold to 0 in their init file.
I don't think turning it on unconditionally has any significant drawback,
but there some extreme cases where commands would not do their job
properly (for example, doing M-> C-u 37000 C-p in xdisp.c), which is why
it is not turned on unconditionally by default.
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.