On Friday, 15 Sep 2023 at 07:51, Emanuel Berg wrote:
> "What servers", does that mean what servers in particular or
> what server types, i.e. the protocols employed?
Particular servers. Some have greater latency than others and having
Emacs hang while it waits for servers to respond can be frustr
(Again, moving to emacs-tangents@gnu.org.)
> Agreed, it is better with keyword arguments than
> a long list of nils because of optional arguments.
>
> But it is better yet to not have the functions take so many
> arguments in the first place, but to split them up and have
> the function name be
Eli Zaretskii wrote:
>> I think the biggest problem with uncooperative
>> multi-threading in Emacs is that Emacs has so much global
>> state. As a consequence, it's unsafe to let two threads use
>> anything in the C code in parallel.
>
> Indeed, that's the main problem. Just adding threads to Lisp
Arthur Miller wrote:
> Yes indeed; and I agree with what you wrote in your longer
> second mail about that. They do lessen the need for more
> functions which means less API surface to document and
> potentially lookup and learn. Isn't a good example that
> window functions that I wanted to make i
> From: Emanuel Berg
> Date: Fri, 15 Sep 2023 19:11:22 +0200
>
> Eli Zaretskii wrote:
>
> >> I think the biggest problem with uncooperative
> >> multi-threading in Emacs is that Emacs has so much global
> >> state. As a consequence, it's unsafe to let two threads use
> >> anything in the C code
> I think, in general and ranked from best to worse,
>
> 1. Many functions, all with few arguments
> 2. One function with not-that-many optional arguments
> 3. One function with keyword arguments
> 4. One function with too many optional arguments
I don't think any such generalization is
very help
Drew Adams wrote:
> I think you're missing the point I made about a "family"
> of functions.
>
> Just having separate "many functions, all with few
> arguments" can make it more difficult to understand which is
> which, what's what, and when to use this one or that one.
>
> More generally, it's ha
