Inclusion in Emacs about s.el HOT 12 CLOSED

This makes more sense when viewed together with the ->> threading macro from dash. Other than that, s is not a language, but a library for working with strings, so having several functions for creating strings in different ways isn't too outlandish.

from s.el.

I was shocked when emacs didn't have functions for working with strings, so I made this package. I would be happy for Emacs to have proper string functions. Feel free to use the same function signatures as here. I'm sure that would help people migrate easier.

from s.el.

Thanks! I'll keep you posted about the development/issues raised.

I just noticed on https://github.com/magnars/s.el/graphs/contributors that it's not so high, and that you own more than 90% of the commits.

What is your position on copyright assignments? My idea is that if you agree, we can already import the code where only you is the author. Not sure how well that'd work in practice because probably that every function has a typo fix or whatever from a contributor, but from what I've seen some of your contributors already did the copyright assignements so they'd probably agree as well.

from s.el.

from s.el.

Great news! Will keep you informed.

from s.el.

Ok I have some news.

I would be lying if I said it went well, but in the end there was some interesting debate 😅

There was a lot of more general discussions in the past days about namespaces & prefixes, and basically for s.el the conclusions are the following:

• Emacs has a lot of string functions already. They are just "weirdly named and inconsistent" from our point of view. But from their point of view, it's mostly fine that they are namespaced all over the place.
• Aliasing or renaming the existing functions to match a scheme (pun intended) more like what you did ("clojure" like) yielded a lot of bikeshedding, and it looks like we might be successful to rename a handful of functions but certainly not for as much as we'd like because they feel it'd create too much work/maintainance/disruption.
• Some of your functions are new APIs and they'll be considered case by case, but overall there's a tendancy to minimalism in the Emacs api (e.g concat argued as good enough for s-prepend, s-append and s-concat).

I'll keep you posted about how things progress on that front.

On the other hand, there was a strong desire to have s.el in ELPA "as is" and hoped you'd be willing to do that. I felt curiosity there and I guess if it was in ELPA there would be more "old timers" trying it out, because some of them don't like MELPA (this is me guessing). I have no clue how you feel about this so please express your concerns. So far I understand your primary target are MELPA users, and that dash.el is already on both but suffers a bit of "staleness" on ELPA compared to MELPA. Maybe I can kill two birds with one stone if you comment on that too.

Thanks again for your support, and no pressure feel free to be honest.

from s.el.

Hello again :) Thanks for the update. I would be lying if I said I'm surprised. ^^

I would be happy to add s.el to ELPA as is, especially if it does not include any (or very little) work on my part. Let me know what is needed.

from s.el.

Oookay.

Here are the good news first: in the best case inclusion in ELPA requires absolutely no work on your part except registering it. In the worse case it'd mean having an "elpa" branch where you push "stable" things. Tho when looking at dash I see it's at 2.12 while melpa is at 2.17 so I need to check why, maybe there was some automation going on that is broken.

But the bad news is since the s.el ELPA proposal some voiced their opinion against it. The discussion is still going but we need to wait on a consensus before going further, some would like you to rename it to clos- (clojure-string) before adoption because they fear it might have bad consequences. This triggered a discussion about what ELPA is (just a "good packages" repository or "packages that could go in & out of core") and we also need to wait for that to settle down.

In the meantime of course a new discussion poped up about having real namespace supports in Emacs lisp and people are debating implementations, if that happens this would theorically reduce the friction for s.el in ELPA.

Anyway, at this point we can only wait 🤷‍♂️

I'll keep you posted. Sorry for dragging you into this, I genuinely thought it'd be a good idea to propose. I guess I'm that naive 😄

from s.el.

from s.el.

Oh well, I completely forgot about this issue.

I see that dash is in ELPA, nice!

I'll close this because I don't have the force to move this forward 😉

from s.el.

(e.g concat argued as good enough for s-prepend, s-append and s-concat).

Why does s.el have three functions for "concat"? The docs don't show anything that s-append and s-prepend do differently. Which language does have three different names for "concat"?

from s.el.

Why does s.el have three functions for "concat"? The docs don't show anything that s-append and s-prepend do differently. Which language does have three different names for "concat"?

Well the signatures are different:

s-concat (&rest strings)
s-prepend (prefix s)
s-append (suffix s)

e.g (s-prepend "foo" "bar" "baz") is an error.

from s.el.