[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concerning delete-by-moving-to-trash on free systems
From: |
David De La Harpe Golden |
Subject: |
Re: Concerning delete-by-moving-to-trash on free systems |
Date: |
Thu, 27 Nov 2008 14:35:14 +0000 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
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.
Re: Concerning delete-by-moving-to-trash on free systems, martin rudalics, 2008/11/27