-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emacs integration #2
Comments
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? |
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. |
I'll give it a little time to mature, then go visit the emacs-dev list, then. Thanks. |
Yep, the library needs at least half an year in the wild first. Great initial version, though. :-) |
Agreed and thanks :-) |
+1 |
I'm not sure I want packages like |
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. |
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 |
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? |
Yep, it won't be happening.
Really useful functions will be welcomed to |
Are you maintaining this library now :)? Good to hear that copyright won't be an issue. I'm surprised there's no |
When I look at what happened to Getting into Emacs is, it seems to me, the death sentence... |
I guess the issue can be closed then. |
@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. |
@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) |
@Fuco1 Thanks! Let's stop hijacking this thread then, I'll answer on the seq.el repo. |
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 Going back to |
I think it's fair to say we can close this issue.
|
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. |
Hi Daniel, if you'd like this issue re-opened let me know. |
Contributors subscribed to this issue, and would like to contribute code to subr / subr-x. This is a call to action. |
+1 |
This library is so important that there is no reason for it to be external to Emacs.
Please integrate these functions into Emacs.
The text was updated successfully, but these errors were encountered: