Re: Shrinking the C core

[joakim]

Eli Zaretskii <eliz@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: joakim@verona.se
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Arthur Miller <arthur.miller@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
joakim@verona.se