Introduce -defun

[yyoncho]

• I used -lambda as a base, tried several versions with extracting the common
  code but neither of them made the code more readable(IMO).

• Removed the restrictions against doing (-lambda () ...) which does not seem
  to needed.

[ericdallo]

LGTM, maybe add some link/docs on the README on how to use?

[basil-conto]

@ericdallo

maybe add some link/docs on the README on how to use?

For every defexamples entry in dev/examples.el, the create-docs.sh script adds the relevant function's docstring and its first few examples to README.md.

[yyoncho]

@basil-conto addressed comments and force-pushed.

[basil-conto]

addressed comments and force-pushed.

Thanks, but some of the docs still contain mistakes; see below.

By the way, dash.el is now included in GNU ELPA and is copyrighted by the Free Software Foundation. Do you have a copyright assignment on file?

[yyoncho]

addressed comments and force-pushed.

Thanks, but some of the docs still contain mistakes; see below.

Sorry about that, please check the newly force pushed version(hopefully I have fixed everything).

By the way, dash.el is now included in GNU ELPA and is copyrighted by the Free Software Foundation. Do you have a copyright assignment on file?

I don't have an assignment.

[basil-conto]

I don't have an assignment.

Would you be willing to? You only need to do it once for all FSF-copyrighted Emacs packages, including Emacs core. It involves filling out one of the forms under http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright and emailing it to [email protected]. They'll tell you what you need to do from there.

See also (info "(emacs) Copyright Assignment").

[basil-conto]

Thanks, LGTM. All that's missing is the copyright assignment.

[yyoncho]

Ping.

[ericdallo]

any news on that @basil-conto ?

[basil-conto]

any news on that @basil-conto ?

Any news on what?

I lack both the ability to check whether @yyoncho's copyright assignment is on file, and to merge this PR.

[ericdallo]

I lack both the ability to check whether @yyoncho's copyright assignment is on file, and to merge this PR.

Yeah, sorry for that :/

[basil-conto]

Yeah, sorry for that :/

No worries. :) Perhaps if the dash.el maintainers are looking for more help I could use it as justification to ask for access to the copyright assignment list, which would allow synchronising this repository with GNU ELPA, which I already have push rights to.

[yyoncho]

FWIW I started copyright assignment but it is not a blocker for the merge either way since I have already 2 commits with more than 15(?) lines in the repo. And generally, we need it in melpa, not sure if having a newer version in elpa will be sufficient.

[basil-conto]

it is not a blocker for the merge either way since I have already 2 commits with more than 15(?) lines in the repo

There was a lot of effort put into getting dash.el on GNU ELPA, so it's unfortunate if copyright status hasn't been checked since then.

And generally, we need it in melpa, not sure if having a newer version in elpa will be sufficient.

The status of dash.el, as a widely used Emacs package, on GNU ELPA is far more important than its status on MELPA. The latter is fine for high volumes of community packages, but the former is guaranteed to always be available and maintained by core Emacs developers, which is more important for packages in which code quality and stability is critical. If a package is on GNU ELPA it is effectively a part of Emacs.

[yyoncho]

And generally, we need it in melpa, not sure if having a newer version in elpa will be sufficient.

The status of dash.el, as a widely used Emacs package, on GNU ELPA is far more important than its status on MELPA.

By "we", I meant emacs-lsp team. Having it in elpa does not work for us because the melpa version will be higher(I guess).

[basil-conto]

Having it in elpa does not work for us because the melpa version will be higher(I guess).

I don't see how that would be a problem.

[yyoncho]

I don't see how that would be a problem.

package.el will pick the melpa version and we will break if it does not have -defun. We will break even now if anyone was using the elpa version because AFAICT dash was not updated in elpa for like 5 years...

[basil-conto]

package.el will pick the melpa version and we will break if it does not have -defun.

If GNU ELPA has -defun, then MELPA will also have it.

We will break even now if anyone was using the elpa version because AFAICT dash was not updated in elpa for like 5 years...

Which is something that I would like to change.

[magnars]

I agree with you, Basil, that we should wait for the CA to be in order, and I’m happy that you’re putting in the effort to get us back on track. man. 1. jun. 2020 kl. 22:18 skrev Basil L. Contovounesios < [email protected]>:

…

package.el will pick the melpa version and we will break if it does not have -defun. If GNU ELPA has -defun, then MELPA will also have it. We will break even now if anyone was using the elpa version because AFAICT dash was not updated in elpa for like 5 years... Which is something that I would like to change. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACA4OIM2YTVY3ND3MJJ2ETRUQEIBANCNFSM4NELLTYA> .

[magnars]

Since Emacs Lisp has a global namespace, you could include the function in your own code while waiting for this to propagate to the package repos, perhaps? man. 1. jun. 2020 kl. 21:17 skrev Ivan Yonchovski <[email protected]

…

: And generally, we need it in melpa, not sure if having a newer version in elpa will be sufficient. The status of dash.el, as a widely used Emacs package, on GNU ELPA is far more important than its status on MELPA. By "we", I meant emacs-lsp team. Having it in elpa does not work for us because the melpa version will be higher(I guess). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACA4OJN4FCDDWME3OXEXI3RUP5EHANCNFSM4NELLTYA> .

[basil-conto]

Since Emacs Lisp has a global namespace, you could include the function in
your own code while waiting for this to propagate to the package repos,
perhaps?

I haven't tested this, but would (defalias 'foo (-lambda ...)) effectively do the same as (-defun foo ...)?

[basil-conto]

FWIW I started copyright assignment

Any updates on that?

I haven't tested this, but would (defalias 'foo (-lambda ...)) effectively do the same as (-defun foo ...)?

It seems to - so is -defun useful enough to have on its own? Or can we just use defalias+-lambda instead?

[yyoncho]

FWIW I started copyright assignment

Any updates on that?

I will try to finish that these days.

I haven't tested this, but would (defalias 'foo (-lambda ...)) effectively do the same as (-defun foo ...)?

It seems to - so is -defun useful enough to have on its own? Or can we just use defalias+-lambda instead?

I don't insist on getting this in - we already defined lsp-defun in lsp-mode.