Re: async 1.0

[Christopher Schmidt]

John Wiegley <address@hidden> writes:

>>>>>> Christopher Schmidt <address@hidden> writes:
[...]
> 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).

You did not mention that before.

[...]
> 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.

I was not arguing in favour of making async.el a GNU ELPA package rather
than a core GNU Emacs package.  I did not question asynchronous beef-ups
of dired or smtpmail per se.

[...]
>> 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.

This is off-topic.  Executive summary: I rewrote the network stack of
Emacs in order to perform certificate pinning and OCSP verification.
This is integrated into a setup where user-visible mutable state (this
is fuzzy!) is stored persistently on a per-frame basis - frames bound to
distinct modes and instances - with these instances keeping track off
all file and network activity.  This stuff is integrated into my OS
environment, with Emacs modifying firewall rules whenever necessary.

>> 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.

I do not like that you snipped context out of my quotes.

    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.
    [...]
    When it comes to side-effect free CPU work that does not require
    user feedback this [async.el] 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.

Why do you want complex forms to be called asynchronously out of the
context of the original Emacs process?

Does the advantage of an easy and little intrusive implementation in
comparison to Masashi's deferred.el or the use of manual async
primitives outweigh the loss of "customisation, progress, error,
debugging and bidirectional communication functionality"?  Does it
outweigh that a minority of end-users would have to fiddle with async to
translate their customizations into child emacsen?  Is there any non-I/O
(non-tramp) related use-case for async.el?

The point I was trying to make is that async.el can make development and
actual end-user usage both simpler and harder.  Some issues could be
avoided by using non-forking asynchronous I/O in the first place.  "A
nice short-term solution with severe long-term consequences."  (Now that
I looked up 'severe' in a dictionary, I think it is the wrong term.  I
wanted to say that async.el can cause unexpected surprises.)

[...]
>> 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.

I am sorry.  That comment was not appropriate, it does not matter.


Implementing asynchronous smtp on top of smtpmail within 19 LOC is
impressive.  No doubt whatsoever.  This is a great opt-in feature.  You
did not mention opt-in-ness before and to me it was not obvious from the
context, especially because AFAICT dired-async.el unconditionally
redefines dired internals to use async.el.

John, I have no intention to spread FUD.  I am sorry for offending you
if that is the case.  I have lots of respect for your work.[1]  I am not
a GNU Emacs developer and I do not want to be one.  I was just
brainstorming, raising a few points that went through my head, from an
Emacs user point of view, when I read the messages regarding async.el.
I was under the impression that you would use async.el to revamp the
core packages of Emacs, one after another, wreaking havoc upon my
precious customizations.

Greetings,

        Christopher

[1] I borrowed some stuff from your dotemacs.  Eshell is featured in a
Hollywood movie and your work on git modularization should make Boost
fun again.  I loved your OpenGenera blog post ;)  This is great stuff!