emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Imports / inclusion of s.el into Emacs


From: Dmitry Gutov
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Fri, 1 May 2020 21:36:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 01.05.2020 20:36, Philippe Vaucher wrote:

    1. s-prepend/s-append: trivially replaced by 'concat'.


Okay, that falls in the part 2 of my plan (decide which functions to import). I note that you are against such helpers, do people generally have the same opinion as you on this topic around here?

I imagine so.

And in general, Clojure tends toward more high level programming, with its protocols and optimizing VM. Emacs is more low level, so that shows in the API. And, well, it's good to encourage faster code (within the limitations of our VM).

    3. s-split: basically delegates to split-string, but wraps it in
    save-match-data (which is generally against our guidelines for its use).


That falls in part 1 of my plan (alias existing misnamespaced functions), so we'd simply alias split-string as string-split.

That's why I suggested to propose a list of changes instead of continuing to debate intentions.

Now this point raises an interesting question about save-match-data, are these guidelines available somewhere?

Hmm. I'm not sure. There is this passage in searching.text, though:

  Notice that all functions are allowed to overwrite the match data
unless they're explicitly documented not to do so.  A consequence is
that functions that are run implicitly in the background
(@pxref{Timers}, and @ref{Idle Timers}) should likely save and restore
the match data explicitly.

And since save-match-data is not free, it makes sense to omit it. Especially it functions that are supposed to be used in a lot of code.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]