Re: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden <david@harpegolden.net>]

Tassilo Horn wrote:

> Nice!  Why do you fallback to ~/.local/share/ in
> move-file-to-trash-freedesktop.  With the predicate you already checked
> that XDG_DATA_HOME is set.  If it's not set in
> move-file-to-trash-freedesktop I'd expect an error.
> 

XDG_DATA_HOME is not guaranteed to be set in nonetheless freedesktop.org 
compliant environments (it's not set on my desktop running the 
generally-highly-fd.o XFCE4!):

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
| $XDG_DATA_HOME defines the base directory relative to which user
| specific data files should be stored. If $XDG_DATA_HOME is either not 
| set or empty, a default equal to $HOME/.local/share should be used.

So if it's not set, you're supposed to just go ahead and use the 
default.  It's just an override to allow people to use something other 
than .local/share if they want to.

Note the predicate didn't _only_ check if it's set,  that check is one 
part of a fast+loose "so, is this a freedesktop.org desktop where using 
this kind of trashcan would be appropriate" cascade of tests in
move-file-to-trash--freedesktop-p.

I figured having XDG_DATA_HOME was adequate to indicate a fd.o desktop,
but its absence does not mean a non-fd.o desktop.   I guess really, the 
fd.o model is apps decide to be partially or fully fd.o compliant, not 
that there's an easy way to check for fd.o-ness... but I might be wrong 
there:  If it's a thing that there's a more reliable way to tell "yes, 
nancy, this IS a freedesktop.org desktop", then
move-file-to-trash--freedesktop-p  could be simplified.

If it's actually okay for emacs to use the freedesktop-style trashcan by 
default rather than the builtin emacs "fallback" trashcan support, then 
the move-file-to-trash--freedesktop-p test could be dropped and the 
patch slightly simplified.

Note that it's really only one side of comprehensive trashcan support 
(the writing side). While it's not urgent (since most people interested 
in fd.o trashcans can presumably use their desktop environment file 
manager's trashcan interface), for the reading side, someone might 
conceivably want a dired that's trashcan-aware, so that you could browse 
the traschcan in a slightly extended dired view that offers a restore 
option (and at least with the metadata-available fd.o-style trashcan 
(and probably some others) it'd also be possible for dired to offer 
restorations of files when you're browsing a directory that has 
ex-members in the trashcan...).  That's generally more complicated e.g. 
while my patch for _writing_ to trashcan avails of the option not
to use per-volume trashcans in the relevant spec, _reading_ from trash 
properly should probably not disregard the existence of per-volume trash.