bug#56393: Actually fix the long lines display bug

[Phil Sainty]

Hi Gregory,

Thanks for this.  I've only had a brief play, but it looks like a
very useful approach.

I can cause it to glitch by visiting a large file and leaning on the
page down key.  After a little while it fails to widen, and I'm left
in some narrowed portion of the buffer until I use a command which
re-triggers it.

I have vague misgivings about the fact that it doesn't care about the
file type or major mode, as it triggers for binary files which are
already handled safely by their major mode (images, archives, docview,
and anything else).  I say "vague" because I also didn't observe any
problems with such examples -- but I don't know whether that is
guaranteed to be true for all file types.

It's not clear to me how seamless this feature is (partly because I've
not had a chance to examine it in detail -- but I won't be able to do
so any time soon).  I see an explicit list of supported commands in
the code though, and I worry about that.  Surely(?) we can't insist
that all commands (if not functions generally?) which need to deal
with the full buffer (including all the custom code out there in
users' configs) should be updated to make them explicitly aware of
this new mode?  That doesn't seem maintainable to me, and I can only
imagine it causing lots of problems.  I always imagined a final
resolution for this issue being something that didn't necessitate
code changes by users.

Is that really needed?  As you're already attacking this in C code,
couldn't the widening and re-narrowing happen automatically for
everything?  I'm (perhaps naively) imagining that the narrowing might
just happen for the duration of each redisplay cycle.

Obviously there is some overlap with so-long.el which is a framework
for "doing a thing" (out of a collection of possible things) if long
lines are detected, and auto-narrow-mode could certainly be the new
default thing to do; so I'm wondering whether or not there's any
benefit to integrating the two things.  So-long is conservative in
when it triggers by comparison, partly to be confident of not causing
unwanted issues, and partly by necessity because its default action
(a major mode) is very disruptive; but its decision making can be
made more aggressive.

I always saw so-long.el as a band-aid until a real fix arrived, so
there may not be any need for any integration if its purpose has been
served.  It would seem possible to do, though, and so if there are
drawbacks of any significance with this new approach then I'd be
inclined to suggest that so-long and longlines would still have a
place, and integrating the new tool into the existing toolkit would
be a good thing.


-Phil