> I haven't used dash/s/f much, but from what I see they do try to bring a
> more "flat" style of APIs, following the style of Clojure. There are a
> lot of utility functions in there too (like extra abstractions on top of
> the basics that the authors found to be useful). So when you ask the
> core library to be more like f.el, you'll have to specify what exactly
> you'd like to see changed: rename existing functions dealing with files
> to start with file-* or to add new ones. Then we can work out some sort
> of policy to adopt (or not) such changes.
>

I think the crux of the issue regarding existing Emacs lisp would be
"should all file related apis start with file- ?"

If we decide the answer is yes (as advised by the coding conventions) we
could start by simply aliasing the existing API that does not follow this
convention. That'd mean `copy-alist` would be aliased as `alist-copy`, do
you think people would be strongly against this?


> Also, quite a bit of functions seem to be named with the purpose of
> keeping the names short, perhaps too short, like the author came over
> from Clojure, found out that you can't simply
>
>    (require '[string-utils :as s])
>

Yes, I think "string-" is better than "s-", but I understand the author
didn't want to clash with the existing "string-" functions so he picked
"s-".

In this case I think a simple proposal would be to list all the "s-"
functions that don't have a corresponding "string-" function (s-truncate,
s-left, s-right, etc) and propose them for inclusion but named under the
"string-" namespace.

Regards,
Philippe