>
> As far as s.el goes, I suppose it might be a good thing to add it to
>
ELPA for those who like it.
>
> I'm not completely sold on its contents for the core, however: a lot of
> it looks like a compatibility layer for Clojure's familiarity's sake,
> with very thin wrappers (which basically just add the cost of function
> invocation).
>

Okay, I picked s.el because I felt it was one of the low hanging fruits,
but maybe I'd have picked something else. Now I started let's finish this
one and then I'll move to `file-*`.


> 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?



> 2. s-trim: string-trim is already in subr-x.
>

Well as I said we would not import what already exists int he `string-`
namespace


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.

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

Thanks,
Philippe