Eli Zaretskii <e...@gnu.org> writes: >> X-Spam-Status: No, score=-1.01 tagged_above=-999 required=6.2 >> tests=[ALL_TRUSTED=-1, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=disabled >> From: joa...@verona.se >> Cc: Eli Zaretskii <e...@gnu.org>, Arthur Miller <arthur.mil...@live.com>, >> emacs-tangents@gnu.org >> Date: Tue, 12 Sep 2023 21:07:41 +0200 >> >> - if I'm connected to an emacs session by ssh, and mistakenly make a >> cli command dump tens of megabytes of spewage to the shell buffer, I'm in >> trouble >> and cant easily get out of it. I need to open a new ssh session and >> kill the rampaging cli. This is quite tedious. Would concurrency fix this? > > This should be doable, and doesn't come anywhere near the "rewrite" > job. You just need a way of blocking the output from the shell, and > then use Emacs commands to kill it.
That would be really great! >> - Same for long-lines, this is still not a solved problem. > > You didn't try Emacs 29 yet, did you? Well, I rebuild from master like at least once a month, so I should be good right? But I see your point, I should come up with a more tangible measure than claiming long lines to be unsolved. Sorry for that. > >> - Gnus refreshes slowly, maybe that could be helped with concurrency, >> but it could also be helped with more async work in gnus. > > Concurrency can help you keep reading messages while Gnus refreshes in > parallel, but it won't easily help you refresh faster, unless someone > comes up with a way of collecting the update in parallel chunks (in > which case they should be able to do that today with the emacs-async > package, I think). Yes, one of these days I should really try one of the gnus-async hacks. -- Joakim Verona joa...@verona.se
