Re: async 1.0

[Christopher Schmidt]

John Wiegley <address@hidden> writes:

> I want this to be a core service any Emacs author can use, not
                      ^^^^^^^^^^^^
> something that requires users to install a package from ELPA.
>
> Is there a problem with my including it?  I am fully signed up with
> the FSF.

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.

This approach to asynchronousy breaks things.  I have customizations all
over the place.  I add functionality to tons of hooks and I have lots of
defadvice's around core functions.  `async-inject-variables' does not
help very much in this regard as it just handles the tip of the iceberg.
It does not remotely cover all customisation points that might need to
be translated to the child Emacs instance.

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

Other than that, GNU Emacs has excellent asynchronous process and
network facilities already.  Why not use them?  In this case one does
not loose customisation, progress, error, debugging and bidirectional
communication functionality.  Of course this would require some
development effort, but in the end there are only very few core packages
(tramp, dired, mail sending, anything else?) that benefit from a true
asynchronous dispatch-and-forget implementation anyway.

There are tons of real issues with async.el.  To make a long story
short, I think true asynchronous I/O in Emacs is a hard, and forking is
not a solution.

Do not get me wrong.  This is an interesting package.  When it comes to
side-effect free CPU work that does not require user feedback this is
the way to go.  (I have no actual example for this use-case, though.)
When it comes to I/O, and this is what all posts in this thread are
about, async.el IMO totally undermines everything Emacs stands for.  It
seems to be like a forbidden fruit.  A nice short-term solution with
severe long-term consequences.

If this package makes it into GNU Emacs, please make every single usage
opt-in by default.  Document on a per use-case basis which functions and
hooks are run in the child Emacs instance.  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.

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]

Just my two cents.

        Christopher

[1] I realise this would require substantial modifications to pretty
much every single aspect of GNU Emacs and GNU ELPA.  Yet I think this is
an approach worth discussing.