bug#45085: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell

[Stefan Kangas <stefan@marxist.se>]

tags 45085 + wontfix
close 45085
thanks

Phil Sainty <psainty@orcon.net.nz> writes:

> One immediate issue with the scenario you're considering
> is that buffers handling process output are commonly
> auto-scrolling to the end of the output, which means that
> after running a command which produces a massive line,
> you're liable to be left with the *end* of the giant line
> visible in the window (which is the worst-case situation);
> so Emacs might struggle with that even if so-long was
> active.
>
> I do think it would be interesting to experiment with using
> `after-change-functions' to detect the insertion of
> extremely long lines into a buffer, but I also think it
> might bring significant complications, so I don't have any
> current plans to extend the library in these directions.
>
> We can be relatively confident about the suitability of
> calling `so-long' in a buffer which is visiting a file of
> programming code; but it's harder to have such confidence
> when considering buffers *generally* -- Emacs buffers can be
> used for almost anything, and it may be wildly inappropriate
> for `so-long' to get involved in many of those cases.
> Especially when considering buffers dealing with external
> processes, when the buffer's mode might be fairly generic,
> yet with a wide variety of different output possibilities.
>
> Explicit/white-listed uses of `so-long-minor-mode' can be
> useful, however.  For example, I recall an Emacs 26 user
> reporting excellent performance improvements (albeit at the
> cost to the readability) from using `so-long-minor-mode' in
> debugger backtrace buffers when giant lists of text
> properties were involved; so there's certainly scope to use
> so-long outside of file-visiting buffers in particular
> scenarios; but my gut feeling is that such uses ought to be
> targeted individually.

It seems like this is not something we want to do or even see as
feasible.  So I'm closing this as wontfix.

If this conclusion is incorrect, please reply to this email (use "Reply
to all" in your email client) and we can reconsider.