Remove dired-async.el in favor of helm-async.el

[Silex]

Hello,

After browsing throught the tickets, it looks to me that:

1. dired-async.el has issues
2. helm-async.el has not those issues
3. they both do the same thing

Why not remove dired-async.el and rename helm-async.el to dired-async.el?

If 1/2/3 are wrong please correct me.

@thierryvolpiatto: do you need it to be named helm-async for helm to work?

[jwiegley]

So, helm async just makes operations within a dired buffer asynchronous? Why is it called helm-async at all then?

[thierryvolpiatto]

John Wiegley notifications@github.com writes:

So, helm async just makes operations within a dired buffer asynchronous? Why is it called helm-async at all then?

Because at first it have been designed to make helm working async, but it works also with dired (in helm-mode you want from a dired buffer to use C, R etc...) The approach is different from dired-async.el: IIRC you have redefined functions to be async (copy-file, etc..) and you call them from dired-create-file.

In helm-async.el I don't use all this only `dired-create-file' which reuse the emacs functions (copy etc..) in children emacs. The only thing helm-async.el doesn't have is deleting files async, and the fancy thing in dired buffer (changing color or something like that IIRC), though you have an animation in mode-line that can probably be used in dired (never try because with helm I don't use dired at all).

So if you want to use only helm-async.el, we could merge it with dired-async.el to use the best of both.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[jwiegley]

I'm happy to head in the direction of merging. dired-async.el has enough flaws right now that I never trust it, so I'm happy to take any change which either brings in stability, or eliminates it entirely in favor of a better option.

[thierryvolpiatto]

John Wiegley notifications@github.com writes:

I'm happy to head in the direction of merging. dired-async.el has enough flaws right now that I never trust it, so I'm happy to take any change which either brings in stability, or eliminates it entirely in favor of a better option.

Great, I will look into that as soon as possible.

Thanks.

---

Reply to this email directly or view it on GitHub: https://github.com/jwiegley/emacs-async/issues/24#issuecomment-32693542

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Silex]

:+1: nice!

[thierryvolpiatto]

Hi John,

John Wiegley notifications@github.com writes:

I'm happy to head in the direction of merging. dired-async.el has enough flaws right now that I never trust it, so I'm happy to take any change which either brings in stability, or eliminates it entirely in favor of a better option.

I have now renamed helm-async.el to dired-async.el. I didn't merge the delete-file stuff from old dired-async.el because it is not working (can't trust it).

So actually the only operations supported are copy, rename, symlink... well all the operations handled by `dired-create-file'. They are both working from helm and dired without special settings.

The fancy thing changing colors in dired buffer have been removed too, instead notification will popup in mode-line, which is IMO more adapted to asynchronous operations (i.e when copying huge files async from dired you probably will not wait in this dired buffer for the color change but do something more interesting somewhere in an other buffer). So while the async process is running you will have in mode-line a notification telling you an async job is running, when this notification disapear, that's mean the async job is finish.

If you want to reenable asynchronous file deletion, we will have to rewrite it using the same approach used actually in dired-create-file:

Basically,

on Host emacs: Run a loop on marked files and store them.

On child emacs: Do the delete operation on this list of files.

IMO async deletion of files is not really useful as it is always fast enough to not block emacs very long like copying etc..

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[jwiegley]

Great!

[Silex]

Thanks guys!