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

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

[積丹尼 Dan Jacobson]

so-long mode is great, when opening files.
But what about the case
(compile "perl -wle 'print 8 x 888888888;'")?
That's going to produce a buffer with a really long line.
So so-long mode should jump in to the rescue.

And what about M-x shell?
If we do
$ perl -wle 'print 8 x 888888888;'
there, so-long mode should somehow 'detect there is something wrong on
the fourth floor of building H, and send in security guards to the
rescue' too.

$ grep so-long .emacs
(global-so-long-mode 1)
is what I am using here in emacs-version "27.1"

>>>> Norbert N. Nerblesome says:
> Just do M-x so-long in the buffer you are uncomfortable with, and you
> will see
> "Changed to so-long-mode (from compilation-mode).  C-c C-c to revert."
> So what's the big deal?

The big deal is, we, sadly might never have the opportunity to type
those "last words and testament," as emacs might already have gotten
locked up. Therefore one hopes the problem could be detected for us and
so-long mode activated automatically:

"Buffer has sprouted long lines. so-long mode activated to prevent emacs jamming itself."

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

[Phil Sainty]

On 7/12/20 2:12 am, 積丹尼 Dan Jacobson wrote:
> so-long mode is great, when opening files.
> But what about the case
> (compile "perl -wle 'print 8 x 888888888;'")?
> That's going to produce a buffer with a really long line.
> So so-long mode should jump in to the rescue.
>
> And what about M-x shell?
> If we do
> $ perl -wle 'print 8 x 888888888;'

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.


-Phil

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

[積丹尼 Dan Jacobson]

>>>>> "PS" == Phil Sainty <psainty@orcon.net.nz> writes:
PS> One immediate issue with the scenario you're considering
PS> is that buffers handling process output are commonly
PS> auto-scrolling to the end of the output, which means that

Got an idea: Guilty until proven innocent!

E.g., when a *compilation* buffer is born, it should / could be in
so-long mode at birth.

And only when it is finished filling up, (compilation status: "exit") an
(automatic) inspection could be made. And only if there were no crazy
long lines in it, would so-long mode be lifted.

Yes, there are long (many minutes) compilation jobs. Ones where the
user is sure nothing will go wrong too. For them the user could set a
variable...

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

[Stefan Kangas]

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.