Re: Why @#! is not Emacs using the Recycle bin on w32?

[David De La Harpe Golden]

I don't even _like_ trashcans, sigh...

Manoj Srivastava wrote:
[quoted out of order]
> Sure, I can graft on a trash can, not just to my fvwm based UI,
> but also to the console (smallish hack to the unlink system call), but
> assuming that such addenda exist would be ... dangerous.

I don't think we're really talking about _that_ sort of trashcan
implementation (see: libtrash). (They also tend to hoard too many files
- using heavy-handed heuristics like "it was in /tmp" to decide whether
a file is a temporary/system file that shouldn't be backed up to trash
when an app unlinks something - only the individual app or user really
knows that for sure...)

But... why would we or should we assume that sort of trash exists or
otherwise?  And wouldn't it be pretty much emacs-transparent anyway?
What could emacs do about it?

The discussion is about emacs' (existing) support for emacs' "deleting"
to trashcans that need (or are basically instantiated by!) _explicit_
application support, where there is an operation or sequence of
operations distinct from a simple unlink() that an application uses to
explictly try to move something to trash rather than truly deleting it.
Like <<google searches>> Windows [1], MacOSX [2] and
Freedesktop.org-specced [3] ones.

[1] http://msdn.microsoft.com/en-us/magazine/cc301415.aspx
(midway down page, SHFileOperation)
[2] NSWorkspaceRecycleOperation
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWorkspace_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSWorkspaceRecycleOperation
[3] http://www.freedesktop.org/wiki/Specifications/trash-spec
(though presumably apps coded against e.g. the GNOME or KDE framework
APIs should be reusing the relevant framework implementation of that
spec rather than reimplementing it. Emacs isn't one of those apps though)


>         Nevertheless, if you assume that Emacs is running in an
>  environment where there is a trashcan, you will be incorrect.
>

How much does that matter?

If a user turns on emacs' support for his platforms' trashcan*, the
trashcan is either:

Already there,

Or maybe, as per fd.o trashcan spec, emacs creates "it" (that is to say,
its specced on-disk representation) upon use if it's not,

Or emacs fails to create and/or use it and being an interactive
application with a UI and all, can say so and ask the user what to do.
"Trashcan unusable because XYZ. Irreversibly delete?"

Having it on by default would violate longtime-emacs-user expectations
IMO (and be yet another thing for me to turn off in my .emacs), but
suggesting much in the way of dire consequences in the event a trashcan
doesn't or can't exist but emacs tries to use one is quite unwarranted.

If it's on-by-default there are small problems, undoubtedly - most
likely, emacs creating and using a trashcan without the user realising**
or wanting it to, or, less likely, hitting the user with a "Trashcan
unusable..." query as above.  On a practical level, that doesn't seem
very much different to emacs causing ~/.emacs.d to spring into existence
though, or its habit of leaving backup~ files strewn about.

Also, the user might not have any means to comfortably browse and
restore from the trashcan emacs creates and/or uses if they don't use
other programs with a trashcan browser, though hacking dired to provide
an emacs-internal trash view looks pretty doable on
freedesktop.org-trashcan-using systems (looks harder on macosx and
windows, but hey, both of those virtually always have a system trashcan
browser).  Another way of looking at that case is that in the absence
of any other platform trashcan, emacs could be said to be using an
fd.o-compliant interoperable trashcan as the "emacs platform" trashcan.

* and remember, some basic support is already in-tree, though presently
seems to me to be quite broken on my desktop - that has to be fixed
before considering turning it on by default. Actually, it has to be
fixed regardless...

** Though "File Deleted" messages could be changed to "Moved to Trash"
when it is used...