RE: Imports / inclusion of s.el into Emacs

[Drew Adams]

> > I thought we had a golden opportunity to put s.el inside Emacs:
> 
> We can still put it in GNU ELPA, which is just as good.  Frankly, it's
> better.  We can pick and choose all the best ideas and include them in
> a way that fits with the rest of Emacs.  And users who still prefer
> s.el are free to use it, including in other GNU ELPA packages.
> 
> > - I can try to suggest a few aliases, and maybe one or two will be
> > accepted, but certainly not a lot.
> > - I can try to suggest a few new functions, and maybe one or two will
> > be accepted.
> 
> Sounds good, thank you.  (I'm not sure why you think that most of your
> suggestions would be rejected, though.)
> 
> > - Whatever is introduced is likely to be "Emacsified" as not to look
> > too much like clojure.
> 
> The way I understand this discussion, I don't think the point is that
> we just want to be different for the sake of being different.  It's
> just that we can't import functions wholesale simply to be similar to
> another language when we already have perfectly good alternatives in
> ELisp.  Or at least we can't do that in core (OTOH it's fine if a
> library like s.el wants to do that).
> 
> > - I can notify the author of s.el that only a tiny subset of s.el (if
> > any) is likely to be imported, but he should know he's very welcome
> to
> > put s.el on ELPA.
> 
> If I read you correctly, you're a bit disappointed.  Even so, please
> focus on the positive, that we would like to add s.el to GNU ELPA,
> rather than the negative "it will not be added to Emacs core".  I
> believe adding it to GNU ELPA will send most of the positive and
> encouraging signals that we all want to communicate to the
> outside-of-ELPA package author crowd.

+1 to everything Stefan K said there.
(And expressed constructively, as usual.)