Emacs integration

[DamienCassou]

This library is so important that there is no reason for it to be external to Emacs.

Please integrate these functions into Emacs.

[magnars]

Yes, coming to Emacs I was really surprised that it was so lacking in string manipulation functions. How to go about getting it into Emacs core tho?

[DamienCassou]

You must ensure that all contributors have signed the FSF agreement (which is not a problem if you are the only one :-)). Then, you should make some noise on the emacs-dev mailing list I guess.

[magnars]

I'll give it a little time to mature, then go visit the emacs-dev list, then. Thanks.

[bbatsov]

Yep, the library needs at least half an year in the wild first. Great initial version, though. :-)

[magnars]

Agreed and thanks :-)

[wyuenho]

+1

[rejeep]

I'm not sure I want packages like s, dash or f in Emacs core. Adding a feature to one of em now is really simple and will be available within a day. But if in core, it will take forever.

[sindikat]

You could start by adding them to GNU ELPA. It would make them more "official" (you would still have to sign FSF papers and oblige to certain coding standards), but nobody would stop you from changing the code as you wish. Good example is ErgoEmacs—it was added to GNU ELPA, yet it's the most unstable Emacs mode ever :P, with features changing every day. Moreover, it is one of the most idiosyncratic packages I've ever seen. Yet it's in GNU ELPA.

[bbatsov]

You'll no longer be able to accept PR from people who haven't signed the FSF agreement for packages accepted in ELPA, which is the biggest problem I have with it.

On a related note - Emacs 24.4 has more string functions in its new subr-x.el library.

[xiongtx]

I'm guessing at this point, this won't be happening?

What if someone else wanted to add similar string functions to Emacs? Is there going to be a priority/copyright issue?

[bbatsov]

I'm guessing at this point, this won't be happening?

Yep, it won't be happening.

What if someone else wanted to add similar string functions to Emacs? Is there going to be a priority/copyright issue?

Really useful functions will be welcomed to subr-x.el. There are no copyright issues, but you'll still have to match the style of string functions in subr-x.el.

[xiongtx]

Are you maintaining this library now :)? Good to hear that copyright won't be an issue.

I'm surprised there's no string.el in Emacs sources. subr-x.el seems like a grab-bag; code organization is definitely not one of Emacs's many strengths.

[Fuco1]

When I look at what happened to seq I'm quite sad. Since the moment it got into ELPA/Emacs it just stagnates... there's no feedback, the author gets no motivation to work on it because no users come and ask for features/provide bug reports... it has maybe 15% of dash covered and I don't see any change any time soon.

Getting into Emacs is, it seems to me, the death sentence...

[DamienCassou]

I guess the issue can be closed then.

[NicolasPetton]

@Fuco1 I'm not sure it's because it got integrated into Emacs (or probably not only because of that). It's also partly my fault, because it covers my needs as it is today.

BTW, how would you like it to evolve? It's true that I don't get much feedback.

[Fuco1]

@NicolasPetton Hey! I left you some feedback on the github repo NicolasPetton/seq.el#9 .

I understand you might not have time to implement stuff and I would do that, but I simply can't work with the emacs devel setup :/

I will gladly send you the patch(es) in form of a github pullrequest or I can open it against some of the Emacs mirrors on github which are up-to-date. I've signed the paperwork and you can then submit the patches to Emacs. I know it's a bit silly...

There was also this discussion magnars/dash.el#179

(this is such a massive hijack of this thread :D)

[NicolasPetton]

@Fuco1 Thanks! Let's stop hijacking this thread then, I'll answer on the seq.el repo.

[bbatsov]

When I look at what happened to seq I'm quite sad. Since the moment it got into ELPA/Emacs it just stagnates... there's no feedback, the author gets no motivation to work on it because no users come and ask for features/provide bug reports... it has maybe 15% of dash covered and I don't see any change any time soon.

Btw, I don't think that dash.el's huge scope is actually a feature. :-) I actually like a lot more the focused approach taken by seq.el (and after the first few versions I think it covered all my needs completely). Sure - there's always room for improvement, but few Emacs libraries actually get much maintenance regardless of where they are hosted. I think that about 20 people maintain 80% of the most popular Emacs Lisp libraries...

Going back to s.el - ever since I've added the most important (commonly needed) functions from it to Emacs itself in version 25 I never needed s.el. If someone tells me exactly what they think is missing in Emacs and why I'd be happy to commit the missing bits to Emacs myself.

[jasonm23]

I think it's fair to say we can close this issue.

Going back to s.el - ever since I've added the most important (commonly needed) functions from it to Emacs itself in version 25 I never needed s.el. If someone tells me exactly what they think is missing in Emacs and why I'd be happy to commit the missing bits to Emacs myself.

[minad]

Fyi, I maintain the Compat package, which aims to backport Emacs library functions to older Emacs versions. Compat makes it possible to use new Emacs APIs in packages much sooner, even without dropping support for older Emacs versions. I encourage to add more functionality from s.el to subr.el or subr-x.el.

[jasonm23]

@minad

Hi Daniel, if you'd like this issue re-opened let me know.
It should be non-controversial that we'd all want subr to be at least equal to and surpass s.el.

[jasonm23]

Contributors subscribed to this issue, and would like to contribute code to subr / subr-x. This is a call to action.

[wyttenbach]

+1