Recently added option "-F" freezes Emacs for several seconds

[yugaego]

PR #3 added implicit argument "-F" to the trash command to use Finder for trashing,
but this argument is documented as a "slower" option.
Indeed, in my setup now Emacs freezes for ~5 seconds whenever I delete files.

First I'd considered to make this "-F" argument optional, but seems using asynchronous processes
might be a better solution, because:

• Finder could still be in use, thus "put back" feature would still work.
• slow processing would be done in background.

Any opinions?

[yugaego]

I investigated the question of trashing on MacOS more, getting to the following conclusions.

For those, who DON'T really need "Put Back" feature

It's enough to configure:

(setq delete-by-moving-to-trash t)

(if (eq system-type 'darwin)
    (setq trash-directory "~/.Trash"))

delete-by-moving-to-trash is available/updated since Emacs 23.1.
trash-directory is available/updated since Emacs 23.2.
So this is expected to be a working solution for many (or majority) of MacOS Emacs users.

For those who DO want to use "Put Back" feature

The issue is not something specific to Emacs app only. On MacOS, "Put Back" feature is enabled only for those files that were deleted by Finder. (At least it used to be so and works this way on my system too.)

Possible workarounds:

• Use this package osx-trash (with/out brew install trash).
• brew install trash and call trash -F command from an init-file (see man trash for more details). Examples to base the solution on: osx-trash package code or EmacsWiki.
• Do not install trash library, but call Finder with an Applescript. Examples to base the solution on: this package code again or Use ns-do-applescript instead of external binaries? #4 .
• Use Emacs Mac port that more fully integrates Emacs into MacOS. There's a Homebrew adaptation of this package.
• Implement in Emacs core. This option details are out of the scope of my comment here, so I'm just mentioning the possibility.

Summarizing: since the listed options eliminate my personal need in using this particular package and no other feedback/opinions were given, I'm closing the discussion (at least for now).

I might participate in discussing/implementing approach #4 if that gets a bit more traction.