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