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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45085 in the body.
You can then email your comments to 45085 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Have so-long mode fire-sprinkler system always ready for M-x
 compile, M-x shell
Date: Sun, 06 Dec 2020 21:12:01 +0800

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."

Message #8 received at 45085 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 45085 <at> debbugs.gnu.org
Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready
 for M-x compile, M-x shell
Date: Thu, 10 Dec 2020 00:02:22 +1300

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

Message #11 received at 45085 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 45085 <at> debbugs.gnu.org
Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready
 for M-x compile, M-x shell
Date: Wed, 09 Dec 2020 20:51:34 +0800

>>>>> "PS" == Phil Sainty <psainty <at> 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...

Message #14 received at 45085 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 45085 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready
 for M-x compile, M-x shell
Date: Sat, 23 Oct 2021 03:35:00 -0700

tags 45085 + wontfix
close 45085
thanks

Phil Sainty <psainty <at> 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.

Previous Next

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