unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Concerning delete-by-moving-to-trash on free systems
@ 2008-11-27 10:09 Tassilo Horn
  2008-11-27 13:19 ` David De La Harpe Golden
  2008-11-27 13:43 ` martin rudalics
  0 siblings, 2 replies; 8+ messages in thread
From: Tassilo Horn @ 2008-11-27 10:09 UTC (permalink / raw)
  To: emacs-devel

Hi all,

I've just found out about that option, and basically it's nice.  But in
order to integrate emacs on the modern GNU desktop the moving to trash
should be in compliance with the Freedesktop.org Trash Specification [1]
on systems that support it.  This spec enables undoing of deletions
which requires storage of some metadata of course.

Beside from not conforming to this standard, the current implementation
has other drawbacks.

  - Delete a directory foo which contains the files a and b recursively
    (from within dired).  Then goto the trash-directory.  Now foo, a and
    b are side by side.

  - Now delete another file named a.  This file is really deleted,
    because a already exists in trash.  (Overwriting would be as bad as
    the current decision.)

Bye,
Tassilo
__________
[1] http://www.freedesktop.org/wiki/Specifications/trash-spec?action=show&redirect=Standards%2Ftrash-spec




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 10:09 Concerning delete-by-moving-to-trash on free systems Tassilo Horn
@ 2008-11-27 13:19 ` David De La Harpe Golden
  2008-11-27 14:00   ` Tassilo Horn
  2008-11-27 13:43 ` martin rudalics
  1 sibling, 1 reply; 8+ messages in thread
From: David De La Harpe Golden @ 2008-11-27 13:19 UTC (permalink / raw)
  To: emacs-devel

Tassilo Horn wrote:
> Hi all,
> 
> I've just found out about that option, and basically it's nice.  But in
> order to integrate emacs on the modern GNU desktop the moving to trash
> should be in compliance with the Freedesktop.org Trash Specification [1]
> on systems that support it.  This spec enables undoing of deletions
> which requires storage of some metadata of course.
> 

FWIW, see #973 Support for moving files to freedesktop.org-style 
trashcan (with patch):
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=973





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 10:09 Concerning delete-by-moving-to-trash on free systems Tassilo Horn
  2008-11-27 13:19 ` David De La Harpe Golden
@ 2008-11-27 13:43 ` martin rudalics
  1 sibling, 0 replies; 8+ messages in thread
From: martin rudalics @ 2008-11-27 13:43 UTC (permalink / raw)
  To: emacs-devel

 >   - Now delete another file named a.  This file is really deleted,
 >     because a already exists in trash.  (Overwriting would be as bad as
 >     the current decision.)

IMHO, this qualifies as a very severe bug.

martin





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 13:19 ` David De La Harpe Golden
@ 2008-11-27 14:00   ` Tassilo Horn
  2008-11-27 14:35     ` David De La Harpe Golden
  0 siblings, 1 reply; 8+ messages in thread
From: Tassilo Horn @ 2008-11-27 14:00 UTC (permalink / raw)
  To: David De La Harpe Golden; +Cc: emacs-devel

David De La Harpe Golden <david@harpegolden.net> writes:

Hi David,

>> I've just found out about that option, and basically it's nice.  But
>> in order to integrate emacs on the modern GNU desktop the moving to
>> trash should be in compliance with the Freedesktop.org Trash
>> Specification [1] on systems that support it.  This spec enables
>> undoing of deletions which requires storage of some metadata of
>> course.
>>
>
> FWIW, see #973 Support for moving files to freedesktop.org-style
> trashcan (with patch):
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=973

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.

Does that have a chance to be included for 23.1?  I know, it's
feature-freeze, but even if it wouldn't do TRT in each and every case,
it cannot be worse than the current behavior, right?

Bye,
Tassilo




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 14:00   ` Tassilo Horn
@ 2008-11-27 14:35     ` David De La Harpe Golden
  2008-11-27 14:58       ` Tassilo Horn
  0 siblings, 1 reply; 8+ messages in thread
From: David De La Harpe Golden @ 2008-11-27 14:35 UTC (permalink / raw)
  To: Emacs developers

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.














^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 14:35     ` David De La Harpe Golden
@ 2008-11-27 14:58       ` Tassilo Horn
  2008-11-27 15:26         ` Juanma Barranquero
  0 siblings, 1 reply; 8+ messages in thread
From: Tassilo Horn @ 2008-11-27 14:58 UTC (permalink / raw)
  To: Emacs developers

David De La Harpe Golden <david@harpegolden.net> writes:

Hi!

>> 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!):

I see.  I looked at it too briefly.

> 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.

I'd say it's more than ok.  As I mentioned in my original posting the
current fallback trashcan loses data.  That's much more problematic than
moving the files to a real trash can which cannot be accessed
appropriately with emacs ATM.

> 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),

Exactly.  I like moving to trash because seldomly but sometimes I delete
something which I shouldn't delete.  The main point is that it's still
there, no matter if I have to fire up some other app to restore it.

> 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 would be fantastic.

> 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.

Ok, let's add that to the 23.2 TODO list. ;-)

Anyway, my main point is (if I didn't mention it often enough): Don't
release 23.1 with an option which sounds great but loses data.

Bye,
Tassilo




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 14:58       ` Tassilo Horn
@ 2008-11-27 15:26         ` Juanma Barranquero
  2008-11-27 16:20           ` Tassilo Horn
  0 siblings, 1 reply; 8+ messages in thread
From: Juanma Barranquero @ 2008-11-27 15:26 UTC (permalink / raw)
  To: Emacs developers

On Thu, Nov 27, 2008 at 15:58, Tassilo Horn <tassilo@member.fsf.org> wrote:

> Anyway, my main point is (if I didn't mention it often enough): Don't
> release 23.1 with an option which sounds great but loses data.

File a bug report and mark it as "Severity: grave".

  Juanma




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Concerning delete-by-moving-to-trash on free systems
  2008-11-27 15:26         ` Juanma Barranquero
@ 2008-11-27 16:20           ` Tassilo Horn
  0 siblings, 0 replies; 8+ messages in thread
From: Tassilo Horn @ 2008-11-27 16:20 UTC (permalink / raw)
  To: emacs-devel

"Juanma Barranquero" <lekktu@gmail.com> writes:

Hi Juanma,

>> Anyway, my main point is (if I didn't mention it often enough): Don't
>> release 23.1 with an option which sounds great but loses data.
>
> File a bug report and mark it as "Severity: grave".

Done, #1440.

Bye,
Tassilo




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-11-27 16:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-27 10:09 Concerning delete-by-moving-to-trash on free systems Tassilo Horn
2008-11-27 13:19 ` David De La Harpe Golden
2008-11-27 14:00   ` Tassilo Horn
2008-11-27 14:35     ` David De La Harpe Golden
2008-11-27 14:58       ` Tassilo Horn
2008-11-27 15:26         ` Juanma Barranquero
2008-11-27 16:20           ` Tassilo Horn
2008-11-27 13:43 ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).