Re: async 1.0

[John Wiegley]

>>>>> Christopher Schmidt <address@hidden> writes:

> Whilst this is an incredibly interesting package, I do not think that
> async.el should be a "core service" that may be used by other core packages.

I think that it should definitely be a core service, but _of course_, "opt-in"
until it is discovered that each particular use of async.el cannot break in
any way (and I'm open to the thought that this may never be true, and it will
be opt-in forever).

For example, I have changes to dired to make it asynchronous.  They work great
here, and I'm not sure what all your doom and gloom is about.  However, I
wouldn't imagine enabling such a change by default; I would add a
`dired-use-async' variable.

*However*, such a variable loses a lot of value if dired is part of Emacs but
async isn't.  How can I modify dired (and it does require core modifications
to support async.el) if the changes rely on macros contained in a package from
ELPA?  Dired gets byte-compiled as part of the Emacs bootstrap, yet those
macros are not present until the user installs async.el from ELPA.  Do they
have to re-compile dired to establish the proper definitions in byte-code?

Further, even though enabling `dired-use-async' purports to make dired async,
it doesn't really.  The user has to additionally install async through ELPA
for that variable to become meaningful.  This is a needless burden on the
user, not all of whom are familiar and comfortable with installing packages
through ELPA.  Async should be something people can just turn on, not
something they have to jump through hoops to get.

So, I think async.el should be a core services so that other core services can
rely on its definitions at compile time, as Emacs is being built.  Otherwise,
changing dired, eshell, smtpmail, etc., to use async.el ends up being way too
hacky to be worth doing.

I believe requiring distribution through ELPA would kill chance at real
adoption for async.el.

> smtpmail-async would break my setup.  It would break my setup in a way very
> hard to fix.

Can you explain that a bit more?  Otherwise, it sounds like FUD.

> Other than that, GNU Emacs has excellent asynchronous process and network
> facilities already.  Why not use them?

And these would be?  I'm not aware of any core service that lets me
asynchronously call lambdas.

> If this package makes it into GNU Emacs, please make every single usage
> opt-in by default.

I wouldn't dream of enabling this by default for unsuspecting users.  It needs
years of battle testing before I'd even begin to have that kind of confidence.

> If async.el somehow finds its way on my machine, the very first form in my
> init.el will be responsible for redefining all `async-'-functions to
> unconditionally signal an error.

Again, a bit FUD-y.

> Slightly off topic...  I do not agree with GNU ELPA not being applicable for
> core services.  I think every single package that is not absolutely
> necessary for running a bare Emacs should be moved to GNU ELPA.  In
> particular I am thinking of packages like CEDET, Calc, Calendar, ECB, ERC,
> Gnus, Org-mode, all prog-modes, eshell, mh-e, rmail, shell, term etc.  On
> top of that, IMO every single core package should have a copy on GNU ELPA so
> one can to overwrite the native GNU Emacs one with the one from GNU ELPA.
> This would decouple all packages from the Emacs release cycle and allow bug
> fixes to be distributed instantly.  On top of that, this would make actual
> core emacs development, test, release and bug management a lot easier.[1]

This is a discussion for another thread, please.

John