all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* delete-file to trash
@ 2010-05-21 19:48 Leo
  2010-05-21 20:15 ` Tassilo Horn
                   ` (2 more replies)
  0 siblings, 3 replies; 48+ messages in thread
From: Leo @ 2010-05-21 19:48 UTC (permalink / raw)
  To: emacs-devel

Hello all,

I have found myself difficult to get along with
delete-by-moving-to-trash. On the one hand I would love to be able to rm
files in eshell and dired without confirmation and yet still have the
ability to recover from mistakes. On the other hand, the current
implementation seems flawed.

It seems someone needs to inspect every occurrences of delete-file in
emacs and carefully check whether to add a 'force arg. Sometimes temp
files may contain sensitive data and they should not be moved to the
trash bin. For example, at the moment, if you have encrypted files open
in epg, the decrypted contents will be moved to the trash bin although
this is trivial to fix for this particular case.

I still maintain a more suitable approach is to have delete-file not
move to trash bin unless explicitly called for. For example, it can be
implemented similarly to handle-shift-selection.

Anyway it seems it is harmful to use this feature. So I guess I will
start phasing it out.

Leo




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

* Re: delete-file to trash
  2010-05-21 19:48 delete-file to trash Leo
@ 2010-05-21 20:15 ` Tassilo Horn
  2010-05-21 20:57   ` Leo
  2010-05-21 21:12   ` Lennart Borgman
  2010-05-21 21:39 ` Eli Zaretskii
  2010-05-22  0:38 ` Stefan Monnier
  2 siblings, 2 replies; 48+ messages in thread
From: Tassilo Horn @ 2010-05-21 20:15 UTC (permalink / raw)
  To: emacs-devel

On Friday 21 May 2010 21:48:43 Leo wrote:

> I still maintain a more suitable approach is to have delete-file not
> move to trash bin unless explicitly called for. For example, it can be
> implemented similarly to handle-shift-selection.

Yes, the current approach is not really perfect when you enable
`delete-by-moving-to-trash' globally, but when enabling it only for
example for eshell or dired mode, I think it's quite good.

--8<---------------cut here---------------start------------->8---
(defun th-dired-mode-init ()
  (set (make-local-variable 'delete-by-moving-to-trash) t))

(add-hook 'dired-mode-hook 'th-dired-mode-init t)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo



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

* Re: delete-file to trash
  2010-05-21 20:15 ` Tassilo Horn
@ 2010-05-21 20:57   ` Leo
  2010-05-21 21:12   ` Lennart Borgman
  1 sibling, 0 replies; 48+ messages in thread
From: Leo @ 2010-05-21 20:57 UTC (permalink / raw)
  To: emacs-devel

On 2010-05-21 21:15 +0100, Tassilo Horn wrote:
> Yes, the current approach is not really perfect when you enable
> `delete-by-moving-to-trash' globally, but when enabling it only for
> example for eshell or dired mode, I think it's quite good.

Thanks for the workaround suggestions.

Since the feature is new I would like to see it right from the start.
There are already patches flow into trunk to accommodate the new arg to
delete-file. Once it is set in stone I will then again have to rely on
defadvice.

Leo




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

* Re: delete-file to trash
  2010-05-21 20:15 ` Tassilo Horn
  2010-05-21 20:57   ` Leo
@ 2010-05-21 21:12   ` Lennart Borgman
  2010-05-21 21:32     ` Tassilo Horn
  1 sibling, 1 reply; 48+ messages in thread
From: Lennart Borgman @ 2010-05-21 21:12 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel

On Fri, May 21, 2010 at 10:15 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> On Friday 21 May 2010 21:48:43 Leo wrote:
>
>> I still maintain a more suitable approach is to have delete-file not
>> move to trash bin unless explicitly called for. For example, it can be
>> implemented similarly to handle-shift-selection.
>
> Yes, the current approach is not really perfect when you enable
> `delete-by-moving-to-trash' globally, but when enabling it only for
> example for eshell or dired mode, I think it's quite good.
>
> --8<---------------cut here---------------start------------->8---
> (defun th-dired-mode-init ()
>  (set (make-local-variable 'delete-by-moving-to-trash) t))
>
> (add-hook 'dired-mode-hook 'th-dired-mode-init t)
> --8<---------------cut here---------------end--------------->8---



Wouldn't it be strange if Emacs as the only application had moving to
trunk disabled by default?

I suggest a better approach would be to identify those cases where it
should not be on and send bug reports/patches for them as soon as
possible.



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

* Re: delete-file to trash
  2010-05-21 21:12   ` Lennart Borgman
@ 2010-05-21 21:32     ` Tassilo Horn
  2010-05-21 21:44       ` Lennart Borgman
  2010-05-22  5:37       ` Eli Zaretskii
  0 siblings, 2 replies; 48+ messages in thread
From: Tassilo Horn @ 2010-05-21 21:32 UTC (permalink / raw)
  To: emacs-devel

On Friday 21 May 2010 23:12:30 Lennart Borgman wrote:

> Wouldn't it be strange if Emacs as the only application had moving to
> trunk disabled by default?

Basically no application except file managers delete by moving to trash.
So dired (and eshell) should do that by default, too, and maybe even
`delete-file' when called interactively.  But when I expire the Gnus
agent cache, I really don't want gazillions of cached news articles end
up in my trashcan.

> I suggest a better approach would be to identify those cases where it
> should not be on and send bug reports/patches for them as soon as
> possible.

I think there are far more cases where you want to delete than move to
trash.

Bye,
Tassilo



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

* Re: delete-file to trash
  2010-05-21 19:48 delete-file to trash Leo
  2010-05-21 20:15 ` Tassilo Horn
@ 2010-05-21 21:39 ` Eli Zaretskii
  2010-05-21 21:46   ` Lennart Borgman
                     ` (3 more replies)
  2010-05-22  0:38 ` Stefan Monnier
  2 siblings, 4 replies; 48+ messages in thread
From: Eli Zaretskii @ 2010-05-21 21:39 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 21 May 2010 20:48:43 +0100
> 
> Anyway it seems it is harmful to use this feature.

I think the whole idea is fundamentally flawed.  Somebody got envious
of the terrible MS invention and wanted to have it on Posix platforms.
The implementation is not the culprit, it's the idea that is simply
wrong.  There's no chance in the world that we could ever have a good
way of deciding programmatically when to move to trash and when not.
Only a human can decide that.

FWIW, when I work on Windows and happen to delete files from the
Explorer, I always hold the Shift key.



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

* Re: delete-file to trash
  2010-05-21 21:32     ` Tassilo Horn
@ 2010-05-21 21:44       ` Lennart Borgman
  2010-05-21 21:58         ` Tassilo Horn
  2010-05-22  5:36         ` Eli Zaretskii
  2010-05-22  5:37       ` Eli Zaretskii
  1 sibling, 2 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-21 21:44 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel

On Fri, May 21, 2010 at 11:32 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>
>> Wouldn't it be strange if Emacs as the only application had moving to
>> trunk disabled by default?
>
> Basically no application except file managers delete by moving to trash.


I thought all GUI applications moved files to trash when the user
deleted them. Is not that the case? What does the specs for different
platforms say?



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

* Re: delete-file to trash
  2010-05-21 21:39 ` Eli Zaretskii
@ 2010-05-21 21:46   ` Lennart Borgman
  2010-05-22  0:52   ` Stefan Monnier
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-21 21:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Leo, emacs-devel

On Fri, May 21, 2010 at 11:39 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Leo <sdl.web@gmail.com>
>> Date: Fri, 21 May 2010 20:48:43 +0100
>>
>> Anyway it seems it is harmful to use this feature.
>
> I think the whole idea is fundamentally flawed.  Somebody got envious
> of the terrible MS invention and wanted to have it on Posix platforms.


Maybe it is instead bad structures within Emacs that is the problem?
The calls to delete files in Emacs simply does not have an argument to
tell if the user somehow deleted the file or if it was deleted
programmatically.



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

* Re: delete-file to trash
  2010-05-21 21:44       ` Lennart Borgman
@ 2010-05-21 21:58         ` Tassilo Horn
  2010-05-21 22:13           ` Lennart Borgman
  2010-05-22  5:36         ` Eli Zaretskii
  1 sibling, 1 reply; 48+ messages in thread
From: Tassilo Horn @ 2010-05-21 21:58 UTC (permalink / raw)
  To: emacs-devel

On Friday 21 May 2010 23:44:52 Lennart Borgman wrote:
> >> Wouldn't it be strange if Emacs as the only application had moving
> >> to trunk disabled by default?
> >
> > Basically no application except file managers delete by moving to
> > trash.
> 
> I thought all GUI applications moved files to trash when the user
> deleted them. Is not that the case?

What GUI applications deal with files in a user-visible way?  I know
only file managers (or specialized file managers like photo managers or
music managers), and maybe email programs when using Maildir.  And the
latter normally delete by moving to trash, but not to the freedesktop
trashcan but a custom trash email folder.

But many apps (GUI or not) use files internally (just like emacs and
apps on the elisp platform), and those will never show up in trash when
they are deleted.

Bye,
Tassilo



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

* Re: delete-file to trash
  2010-05-21 21:58         ` Tassilo Horn
@ 2010-05-21 22:13           ` Lennart Borgman
  2010-05-21 23:14             ` Andreas Schwab
  0 siblings, 1 reply; 48+ messages in thread
From: Lennart Borgman @ 2010-05-21 22:13 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel

On Fri, May 21, 2010 at 11:58 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> >
>> > Basically no application except file managers delete by moving to
>> > trash.
>>
>> I thought all GUI applications moved files to trash when the user
>> deleted them. Is not that the case?
>
> What GUI applications deal with files in a user-visible way?


Any app that opens or saves a file. On w32 such apps can delete files.


> I know
> only file managers (or specialized file managers like photo managers or
> music managers),


Isn't Emacs such a program? ;-)


> and maybe email programs when using Maildir.  And the
> latter normally delete by moving to trash, but not to the freedesktop
> trashcan but a custom trash email folder.


Seems ok.


> But many apps (GUI or not) use files internally (just like emacs and
> apps on the elisp platform), and those will never show up in trash when
> they are deleted.

'
Hm, yes. That seems correct too.

I think the problem is to distinguish between user initiated file
deletions and deletion of internal files.



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

* Re: delete-file to trash
  2010-05-21 22:13           ` Lennart Borgman
@ 2010-05-21 23:14             ` Andreas Schwab
  0 siblings, 0 replies; 48+ messages in thread
From: Andreas Schwab @ 2010-05-21 23:14 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Tassilo Horn, emacs-devel

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Fri, May 21, 2010 at 11:58 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> What GUI applications deal with files in a user-visible way?
>
>
> Any app that opens or saves a file. On w32 such apps can delete files.

It's a property of the file chooser, which is a separate entity.

>> I know
>> only file managers (or specialized file managers like photo managers or
>> music managers),
>
>
> Isn't Emacs such a program? ;-)

dired is, not Emacs.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



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

* Re: delete-file to trash
  2010-05-21 19:48 delete-file to trash Leo
  2010-05-21 20:15 ` Tassilo Horn
  2010-05-21 21:39 ` Eli Zaretskii
@ 2010-05-22  0:38 ` Stefan Monnier
  2010-05-23  0:09   ` Chong Yidong
  2 siblings, 1 reply; 48+ messages in thread
From: Stefan Monnier @ 2010-05-22  0:38 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

> I still maintain a more suitable approach is to have delete-file not
> move to trash bin unless explicitly called for. For example, it can be
> implemented similarly to handle-shift-selection.

I agree.  Instead of a `force' arg to opt-out, we should either use
a new function for "move-to-trash" or use an opt-in arg like
`move-to-trash'.


        Stefan



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

* Re: delete-file to trash
  2010-05-21 21:39 ` Eli Zaretskii
  2010-05-21 21:46   ` Lennart Borgman
@ 2010-05-22  0:52   ` Stefan Monnier
  2010-05-22  6:42     ` Adrian Robert
  2010-05-22  7:32     ` Stephen J. Turnbull
  2010-05-22  1:00   ` Drew Adams
  2010-05-22  1:50   ` Leo
  3 siblings, 2 replies; 48+ messages in thread
From: Stefan Monnier @ 2010-05-22  0:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Leo, emacs-devel

> FWIW, when I work on Windows and happen to delete files from the
> Explorer, I always hold the Shift key.

One of the first steps in my learning Unix was to learn how to
add/change an alias in my shell to replace my syadmin's default alias of
"rm" from "rm -i" to "rm -rf".  Guess what: I never regretted it
(tho I've gotten rid of this alias in the mean time, because my fingers
learned to always type "rm -rf" anyway).

And remember: I'm the guy who constantly commits changes that don't
even compile, so it's not like I'm a careful user.

OT1H the trashcan "feature" is something that enough people think they
want that we do want to support it.  But OTOH I do think that people
will end up seeing the light (think of when Gnome will keep all your
files under a VCS as a matter of course), so I think "move-to-trash" is
transient and will be replaced by some kind of "automatic commit".
We don't have to worry about it yet, maybe, but we should think about
how best to deal with "move-to-trash" within this context.


        Stefan "Always have a backup"



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

* RE: delete-file to trash
  2010-05-21 21:39 ` Eli Zaretskii
  2010-05-21 21:46   ` Lennart Borgman
  2010-05-22  0:52   ` Stefan Monnier
@ 2010-05-22  1:00   ` Drew Adams
  2010-05-22  1:50   ` Leo
  3 siblings, 0 replies; 48+ messages in thread
From: Drew Adams @ 2010-05-22  1:00 UTC (permalink / raw)
  To: 'Eli Zaretskii', 'Leo'; +Cc: emacs-devel

> FWIW, when I work on Windows and happen to delete files from the
> Explorer, I always hold the Shift key.

Not that it matters at all, but so do I.




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

* Re: delete-file to trash
  2010-05-21 21:39 ` Eli Zaretskii
                     ` (2 preceding siblings ...)
  2010-05-22  1:00   ` Drew Adams
@ 2010-05-22  1:50   ` Leo
  3 siblings, 0 replies; 48+ messages in thread
From: Leo @ 2010-05-22  1:50 UTC (permalink / raw)
  To: emacs-devel

On 2010-05-21 22:39 +0100, Eli Zaretskii wrote:
> I think the whole idea is fundamentally flawed. Somebody got envious
> of the terrible MS invention and wanted to have it on Posix platforms.
> The implementation is not the culprit, it's the idea that is simply
> wrong. There's no chance in the world that we could ever have a good
> way of deciding programmatically when to move to trash and when not.
> Only a human can decide that.
>
> FWIW, when I work on Windows and happen to delete files from the
> Explorer, I always hold the Shift key.

On 2010-05-22 01:52 +0100, Stefan Monnier wrote:
> One of the first steps in my learning Unix was to learn how to
> add/change an alias in my shell to replace my syadmin's default alias
> of "rm" from "rm -i" to "rm -rf". Guess what: I never regretted it
> (tho I've gotten rid of this alias in the mean time, because my
> fingers learned to always type "rm -rf" anyway).
>
> And remember: I'm the guy who constantly commits changes that don't
> even compile, so it's not like I'm a careful user.

I think I force delete all the time too on both windows and GNU/Linux
because I don't want confirmation. But if emacs move things to trash
sensibly that actually is a nice feature.

> OT1H the trashcan "feature" is something that enough people think they
> want that we do want to support it. But OTOH I do think that people
> will end up seeing the light (think of when Gnome will keep all your
> files under a VCS as a matter of course), so I think "move-to-trash"
> is transient and will be replaced by some kind of "automatic commit".
> We don't have to worry about it yet, maybe, but we should think about
> how best to deal with "move-to-trash" within this context.
> 
>         Stefan "Always have a backup"

Leo




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

* Re: delete-file to trash
  2010-05-21 21:44       ` Lennart Borgman
  2010-05-21 21:58         ` Tassilo Horn
@ 2010-05-22  5:36         ` Eli Zaretskii
  2010-05-22 10:25           ` Lennart Borgman
  1 sibling, 1 reply; 48+ messages in thread
From: Eli Zaretskii @ 2010-05-22  5:36 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: tassilo, emacs-devel

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 21 May 2010 23:44:52 +0200
> Cc: emacs-devel@gnu.org
> 
> On Fri, May 21, 2010 at 11:32 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
> >
> >> Wouldn't it be strange if Emacs as the only application had moving to
> >> trunk disabled by default?
> >
> > Basically no application except file managers delete by moving to trash.
> 
> 
> I thought all GUI applications moved files to trash when the user
> deleted them. Is not that the case?

No.  On Windows, the move to Recycle Bin is the function of the
Windows Explorer, which is a file manager.  Applications that want to
do that need to call the special API implemented by the Explorer.
Applications that are not file managers don't.  They call the Windows
API which simply deletes.  A trivial example is cmd.exe, whose "del"
command deletes files, it does not move them to Recycle Bin.



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

* Re: delete-file to trash
  2010-05-21 21:32     ` Tassilo Horn
  2010-05-21 21:44       ` Lennart Borgman
@ 2010-05-22  5:37       ` Eli Zaretskii
  2010-05-22  9:17         ` Tassilo Horn
  1 sibling, 1 reply; 48+ messages in thread
From: Eli Zaretskii @ 2010-05-22  5:37 UTC (permalink / raw)
  To: Tassilo Horn; +Cc: emacs-devel

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Fri, 21 May 2010 23:32:03 +0200
> 
> Basically no application except file managers delete by moving to trash.
> So dired (and eshell) should do that by default

Eshell is not a file manager.



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

* Re: delete-file to trash
  2010-05-22  0:52   ` Stefan Monnier
@ 2010-05-22  6:42     ` Adrian Robert
  2010-05-22 13:03       ` Stefan Monnier
  2010-05-22  7:32     ` Stephen J. Turnbull
  1 sibling, 1 reply; 48+ messages in thread
From: Adrian Robert @ 2010-05-22  6:42 UTC (permalink / raw)
  To: emacs-devel


> OT1H the trashcan "feature" is something that enough people think they
> want that we do want to support it.  But OTOH I do think that people
> will end up seeing the light (think of when Gnome will keep all your
> files under a VCS as a matter of course), so I think "move-to-trash" is
> transient and will be replaced by some kind of "automatic commit".
> We don't have to worry about it yet, maybe, but we should think about
> how best to deal with "move-to-trash" within this context.

FWIW, on the Mac, the few apps I'm aware of that delete (not just overwrite)
files under explicit user control move them to trash.  The trash is considered
trash for the whole machine from the user's point of view, not just a mechanism
for the file manager app.

(And if you want to try out what this hypothetical Gnome VCS situation might be
like, you can use a Mac running Time Machine.  Not exactly the same thing, but
close in a lot of ways..)


-Adrian





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

* Re: delete-file to trash
  2010-05-22  0:52   ` Stefan Monnier
  2010-05-22  6:42     ` Adrian Robert
@ 2010-05-22  7:32     ` Stephen J. Turnbull
  1 sibling, 0 replies; 48+ messages in thread
From: Stephen J. Turnbull @ 2010-05-22  7:32 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Leo, emacs-devel

Stefan Monnier writes:

 > But OTOH I do think that people will end up seeing the light (think
 > of when Gnome will keep all your files under a VCS as a matter of
 > course), so I think "move-to-trash" is transient and will be
 > replaced by some kind of "automatic commit".

This is what John Plaice was calling "intensional versioning" in 1997
or so....

+1




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

* Re: delete-file to trash
  2010-05-22  5:37       ` Eli Zaretskii
@ 2010-05-22  9:17         ` Tassilo Horn
  0 siblings, 0 replies; 48+ messages in thread
From: Tassilo Horn @ 2010-05-22  9:17 UTC (permalink / raw)
  To: emacs-devel

On Saturday 22 May 2010 07:37:32 you wrote:

> > Basically no application except file managers delete by moving to
> > trash.  So dired (and eshell) should do that by default
> 
> Eshell is not a file manager.

Well, a shell is a superset of a file manager.  Eshell mode is a
corner-case.  It would be the only shell where files move to
trash...

Anyway, my point is to make moving to trash defaulting to true in modes
where users handle files intentionally, that is, they know they handle
files, as opposed to modes like Gnus, where it is only a coincidence
that mails on a certain backend are plain files (Maildir, nnml) but
other's are not (mbox, IMAP).

But it should definitively be true for modes like dired, image-dired,
and EMMS (which is not included in emacs).

Bye,
Tassilo



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

* Re: delete-file to trash
  2010-05-22  5:36         ` Eli Zaretskii
@ 2010-05-22 10:25           ` Lennart Borgman
  0 siblings, 0 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-22 10:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: tassilo, emacs-devel

On Sat, May 22, 2010 at 7:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Fri, 21 May 2010 23:44:52 +0200
>> Cc: emacs-devel@gnu.org
>>
>> On Fri, May 21, 2010 at 11:32 PM, Tassilo Horn <tassilo@member.fsf.org> wrote:
>> >
>> >> Wouldn't it be strange if Emacs as the only application had moving to
>> >> trunk disabled by default?
>> >
>> > Basically no application except file managers delete by moving to trash.
>>
>>
>> I thought all GUI applications moved files to trash when the user
>> deleted them. Is not that the case?
>
> No.  On Windows, the move to Recycle Bin is the function of the
> Windows Explorer, which is a file manager.  Applications that want to
> do that need to call the special API implemented by the Explorer.
> Applications that are not file managers don't.

Yes, of course. But does not all GUI applications do that? (It is for
example used when opening/saving a file.)

> They call the Windows
> API which simply deletes.  A trivial example is cmd.exe, whose "del"
> command deletes files, it does not move them to Recycle Bin.

A trivial example of a non-GUI application, yes.



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

* Re: delete-file to trash
  2010-05-22  6:42     ` Adrian Robert
@ 2010-05-22 13:03       ` Stefan Monnier
  2010-05-22 19:37         ` Adrian Robert
  0 siblings, 1 reply; 48+ messages in thread
From: Stefan Monnier @ 2010-05-22 13:03 UTC (permalink / raw)
  To: Adrian Robert; +Cc: emacs-devel

> (And if you want to try out what this hypothetical Gnome VCS situation
> might be like, you can use a Mac running Time Machine.

I have no intention to use such a proprietary software, and encourage
other people to stay away from it as well, especially as a form of
archival since that traps you into this proprietary platform.


        Stefan



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

* Re: delete-file to trash
  2010-05-22 13:03       ` Stefan Monnier
@ 2010-05-22 19:37         ` Adrian Robert
  2010-05-23  1:03           ` Stefan Monnier
  2010-05-23 14:54           ` Harald Hanche-Olsen
  0 siblings, 2 replies; 48+ messages in thread
From: Adrian Robert @ 2010-05-22 19:37 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel


On May 22, 2010, at 4:03 PM, Stefan Monnier wrote:

>> (And if you want to try out what this hypothetical Gnome VCS situation
>> might be like, you can use a Mac running Time Machine.
> 
> I have no intention to use such a proprietary software, and encourage
> other people to stay away from it as well, especially as a form of
> archival since that traps you into this proprietary platform.

I apologize, I should have thought before tossing this comment off.  I did not mean to advocate use of Mac OS in general, just point out that it could be a testbed for evaluating a feature that was being implemented or considered for implementation on a free platform.  Or not even using it, but just reading what others say about it positive or negative.

Regarding trapping, Time Machine uses standard unix hard links, and the default FS format for Mac OS is HFS+, the specs for which are published here (http://developer.apple.com/mac/library/technotes/tn/tn1150.html); a GNU/linux driver has been developed.


-Adrian




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

* Re: delete-file to trash
  2010-05-22  0:38 ` Stefan Monnier
@ 2010-05-23  0:09   ` Chong Yidong
  2010-05-23  0:27     ` David De La Harpe Golden
                       ` (2 more replies)
  0 siblings, 3 replies; 48+ messages in thread
From: Chong Yidong @ 2010-05-23  0:09 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I still maintain a more suitable approach is to have delete-file not
>> move to trash bin unless explicitly called for. For example, it can be
>> implemented similarly to handle-shift-selection.
>
> I agree.  Instead of a `force' arg to opt-out, we should either use
> a new function for "move-to-trash" or use an opt-in arg like
> `move-to-trash'.

Yes, the situation is unsatisfactory.

It's now clear that the majority of calls to `delete-file' in Emacs need
the FORCE argument.  Even if we successfully audit all calls to
`delete-file' in our tree, third-party code will still be doing spurious
trashing.  This is probably more annoying to Emacs users than spurious
deleting.

So, it seems better to flip the new FORCE argument to delete-file.  We
could change it to an argument ALLOW-TRASH, and change the doc of
delete-by-moving-to-trash to say that it will only take effect on calls
to `delete-file' that use the ALLOW-TRASH argument.  This is backward
incompatible but I don't see any better solution.

If we do this, I'd also like to turn the trash on by default, on systems
where there is a trash (i.e. on Windows, and on machines where a
Freedesktop trash is detected).

(It was probably a mistake to include the trashing feature, the first
time, without turning it on by default.  If we'd done that, the problems
would have been clarified much more quickly, and we could have figured
out something more appropriate.)



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

* Re: delete-file to trash
  2010-05-23  0:09   ` Chong Yidong
@ 2010-05-23  0:27     ` David De La Harpe Golden
  2010-05-23  1:06     ` Stefan Monnier
  2010-05-23  8:20     ` Leo
  2 siblings, 0 replies; 48+ messages in thread
From: David De La Harpe Golden @ 2010-05-23  0:27 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel, Stefan Monnier, Leo

On 23/05/10 01:09, Chong Yidong wrote:


> So, it seems better to flip the new FORCE argument to delete-file.  We
> could change it to an argument ALLOW-TRASH, and change the doc of
> delete-by-moving-to-trash to say that it will only take effect on calls
> to `delete-file' that use the ALLOW-TRASH argument.  This is backward
> incompatible but I don't see any better solution.
>

One oddity is that delete-file is directly usable interactively, I know 
I'm in the habit (though I _don't_ use the trashcan) - flipping the 
sense of the optional arg would effectively mean that it won't use the 
trashcan when called interactively, wouldn't it?  Unless you further 
make it special-case direct interactive use to be an 'allow-trash op of 
course.

Um. You can use M-x move-file-to-trash interactively too I suppose, that 
might be adequate if users can train themselves to do that instead of 
M-x delete-file.









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

* Re: delete-file to trash
  2010-05-22 19:37         ` Adrian Robert
@ 2010-05-23  1:03           ` Stefan Monnier
  2010-05-23 14:54           ` Harald Hanche-Olsen
  1 sibling, 0 replies; 48+ messages in thread
From: Stefan Monnier @ 2010-05-23  1:03 UTC (permalink / raw)
  To: Adrian Robert; +Cc: emacs-devel

>>> (And if you want to try out what this hypothetical Gnome VCS situation
>>> might be like, you can use a Mac running Time Machine.
>> I have no intention to use such a proprietary software, and encourage
>> other people to stay away from it as well, especially as a form of
>> archival since that traps you into this proprietary platform.
> I apologize, I should have thought before tossing this comment off.
> I did not mean to advocate use of Mac OS in general, just point out
> that it could be a testbed for evaluating a feature that was being
> implemented or considered for implementation on a free platform.
> Or not even using it, but just reading what others say about it
> positive or negative.

No need for an apology.  FWIW, you can already get similar results if you
put your home under a VCS and run commit from a cron job.  I don't have
my whole home under a VCS and don't run commit from cron, but I do have
most of my home under a VCS and have a commit-script which I run
manually very often (because I also use it as a form of distributed FS
rather than only for archival purposes).

> Regarding trapping, Time Machine uses standard unix hard links

Thanks, I had no idea.  This is very good to hear.


        Stefan


PS: I'm actually surprised that Time Machine uses hardlinks since HFS+
supports them very poorly (i.e. with poor performance, at least that was
my experience back when I used GNU Arch under Mac OS X, where the
revision-library used hardlinks intensively and was much slower than
under GNU/Linux on otherwise comparable hardware).



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

* Re: delete-file to trash
  2010-05-23  0:09   ` Chong Yidong
  2010-05-23  0:27     ` David De La Harpe Golden
@ 2010-05-23  1:06     ` Stefan Monnier
  2010-05-23  2:16       ` Chong Yidong
  2010-05-27 23:36       ` Chong Yidong
  2010-05-23  8:20     ` Leo
  2 siblings, 2 replies; 48+ messages in thread
From: Stefan Monnier @ 2010-05-23  1:06 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Leo, emacs-devel

> So, it seems better to flip the new FORCE argument to delete-file.  We
> could change it to an argument ALLOW-TRASH, and change the doc of
> delete-by-moving-to-trash to say that it will only take effect on calls
> to `delete-file' that use the ALLOW-TRASH argument.  This is backward
> incompatible but I don't see any better solution.

100% agreed.

> If we do this, I'd also like to turn the trash on by default, on systems
> where there is a trash (i.e. on Windows, and on machines where a
> Freedesktop trash is detected).

Fine by me.


        Stefan


PS: And yes, for interactive calls to delete-file, the `allow-trash'
should be non-nil, I think.



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

* Re: delete-file to trash
  2010-05-23  1:06     ` Stefan Monnier
@ 2010-05-23  2:16       ` Chong Yidong
  2010-05-23  5:00         ` David Kastrup
                           ` (2 more replies)
  2010-05-27 23:36       ` Chong Yidong
  1 sibling, 3 replies; 48+ messages in thread
From: Chong Yidong @ 2010-05-23  2:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> PS: And yes, for interactive calls to delete-file, the `allow-trash'
> should be non-nil, I think.

Yeah, but omitted means nil.  Hmm.

Here's an idea: allow the variable `delete-by-moving-to-trash' to be a
list of values of `this-command', for which to trash instead of delete.
Then we could set the default value of this list to be `delete-file',
`dired-do-flagged-delete', etc.



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

* Re: delete-file to trash
  2010-05-23  2:16       ` Chong Yidong
@ 2010-05-23  5:00         ` David Kastrup
  2010-05-23  8:57         ` Leo
  2010-05-23 13:37         ` Stefan Monnier
  2 siblings, 0 replies; 48+ messages in thread
From: David Kastrup @ 2010-05-23  5:00 UTC (permalink / raw)
  To: emacs-devel

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> PS: And yes, for interactive calls to delete-file, the `allow-trash'
>> should be non-nil, I think.
>
> Yeah, but omitted means nil.  Hmm.

If you pickup the arguments using &rest instead of &optional in the
argument list, you can distinguish between omitted and nil args.

Whether this is a good idea is another question.

> Here's an idea: allow the variable `delete-by-moving-to-trash' to be a
> list of values of `this-command', for which to trash instead of
> delete.  Then we could set the default value of this list to be
> `delete-file', `dired-do-flagged-delete', etc.

-- 
David Kastrup




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

* Re: delete-file to trash
  2010-05-23  0:09   ` Chong Yidong
  2010-05-23  0:27     ` David De La Harpe Golden
  2010-05-23  1:06     ` Stefan Monnier
@ 2010-05-23  8:20     ` Leo
  2010-05-23 10:00       ` Lennart Borgman
  2 siblings, 1 reply; 48+ messages in thread
From: Leo @ 2010-05-23  8:20 UTC (permalink / raw)
  To: emacs-devel

On 2010-05-23 01:09 +0100, Chong Yidong wrote:
> (It was probably a mistake to include the trashing feature, the first
> time, without turning it on by default. If we'd done that, the
> problems would have been clarified much more quickly, and we could
> have figured out something more appropriate.)

When 23.2 was about to release I deliberately went through the NEWS to
try the new features that I haven't been using. Sadly I didn't use most
of them. For example, I quite like to use visual-line-mode for editing
TeX, but the fact that the line goes to window edge makes it almost
unusable in this scenario since I tend to maximise emacs frames.

I think it will be good for emacs to turn on all new features in the
devel repo so people who use the devel (which is for testing anyway) can
speak about their merits and propose changes. If a feature is no good,
turn it off or even remove it. New features require more testing and if
they are not enabled during development they only get tested in the
released version if someone turn it on accidentally and get annoyed.

Best wishes,

Leo




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

* Re: delete-file to trash
  2010-05-23  2:16       ` Chong Yidong
  2010-05-23  5:00         ` David Kastrup
@ 2010-05-23  8:57         ` Leo
  2010-05-23 13:37         ` Stefan Monnier
  2 siblings, 0 replies; 48+ messages in thread
From: Leo @ 2010-05-23  8:57 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel

On 2010-05-23 03:16 +0100, Chong Yidong wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> PS: And yes, for interactive calls to delete-file, the `allow-trash'
>> should be non-nil, I think.
>
> Yeah, but omitted means nil.  Hmm.

If the interactive-form is like the following:

 (interactive (list (read-file-name "Delete file: " nil default-directory
     (confirm-nonexistent-file-or-buffer)) 'allow-trash))

it is not omitted and the doc-string can say when called interactively
it always respects delete-by-moving-to-trash. Then

> Here's an idea: allow the variable `delete-by-moving-to-trash' to be a
> list of values of `this-command', for which to trash instead of
> delete. Then we could set the default value of this list to be
> `delete-file', `dired-do-flagged-delete', etc.

we can avoid maintaining a list of commands and make
delete-by-moving-to-trash a much easier to customise option since it
requires less information to customise. It looks to me delete-file is
almost exclusively used non-interactively.

Leo



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

* Re: delete-file to trash
  2010-05-23  8:20     ` Leo
@ 2010-05-23 10:00       ` Lennart Borgman
  2010-05-23 10:15         ` Leo
  2010-05-23 13:39         ` Stefan Monnier
  0 siblings, 2 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-23 10:00 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

On Sun, May 23, 2010 at 10:20 AM, Leo <sdl.web@gmail.com> wrote:
>
> of them. For example, I quite like to use visual-line-mode for editing
> TeX, but the fact that the line goes to window edge makes it almost
> unusable in this scenario since I tend to maximise emacs frames.


I also like `visual-line-mode´ and most of the time has Emacs
maximized so I wrote `wrap-to-fill-column-mode' for this (part of
nXhtml). With it you are editing in a middle column (like in Dark Room
etc).



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

* Re: delete-file to trash
  2010-05-23 10:00       ` Lennart Borgman
@ 2010-05-23 10:15         ` Leo
  2010-05-23 11:12           ` Lennart Borgman
  2010-05-23 13:39         ` Stefan Monnier
  1 sibling, 1 reply; 48+ messages in thread
From: Leo @ 2010-05-23 10:15 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: emacs-devel

On 2010-05-23 11:00 +0100, Lennart Borgman wrote:
> On Sun, May 23, 2010 at 10:20 AM, Leo <sdl.web@gmail.com> wrote:
>>
>> of them. For example, I quite like to use visual-line-mode for editing
>> TeX, but the fact that the line goes to window edge makes it almost
>> unusable in this scenario since I tend to maximise emacs frames.
>
>
> I also like `visual-line-mode´ and most of the time has Emacs
> maximized so I wrote `wrap-to-fill-column-mode' for this (part of
> nXhtml). With it you are editing in a middle column (like in Dark Room
> etc).

Does your code re-use word-wrap code?

Leo



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

* Re: delete-file to trash
  2010-05-23 10:15         ` Leo
@ 2010-05-23 11:12           ` Lennart Borgman
  2010-05-23 12:14             ` Leo
  0 siblings, 1 reply; 48+ messages in thread
From: Lennart Borgman @ 2010-05-23 11:12 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

On Sun, May 23, 2010 at 12:15 PM, Leo <sdl.web@gmail.com> wrote:
> On 2010-05-23 11:00 +0100, Lennart Borgman wrote:
>> On Sun, May 23, 2010 at 10:20 AM, Leo <sdl.web@gmail.com> wrote:
>>>
>>> of them. For example, I quite like to use visual-line-mode for editing
>>> TeX, but the fact that the line goes to window edge makes it almost
>>> unusable in this scenario since I tend to maximise emacs frames.
>>
>>
>> I also like `visual-line-mode´ and most of the time has Emacs
>> maximized so I wrote `wrap-to-fill-column-mode' for this (part of
>> nXhtml). With it you are editing in a middle column (like in Dark Room
>> etc).
>
> Does your code re-use word-wrap code?


The basic idea of it is very simple. It just sets margin on both sides
of the middle column. (And then it does a bit more to "bullets" and
such things to make the text more readable.)



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

* Re: delete-file to trash
  2010-05-23 11:12           ` Lennart Borgman
@ 2010-05-23 12:14             ` Leo
  2010-05-23 12:23               ` Lennart Borgman
  0 siblings, 1 reply; 48+ messages in thread
From: Leo @ 2010-05-23 12:14 UTC (permalink / raw)
  To: emacs-devel

On 2010-05-23 12:12 +0100, Lennart Borgman wrote:
>> Does your code re-use word-wrap code?
>
> The basic idea of it is very simple. It just sets margin on both sides
> of the middle column. (And then it does a bit more to "bullets" and
> such things to make the text more readable.)

There are a few workarounds and none of them is ideal. I think the
wrapping length should be customisable in visual-line-mode and then
longlines-mode can be obsoleted.

Leo




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

* Re: delete-file to trash
  2010-05-23 12:14             ` Leo
@ 2010-05-23 12:23               ` Lennart Borgman
  0 siblings, 0 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-23 12:23 UTC (permalink / raw)
  To: Leo; +Cc: emacs-devel

On Sun, May 23, 2010 at 2:14 PM, Leo <sdl.web@gmail.com> wrote:
> On 2010-05-23 12:12 +0100, Lennart Borgman wrote:
>>> Does your code re-use word-wrap code?
>>
>> The basic idea of it is very simple. It just sets margin on both sides
>> of the middle column. (And then it does a bit more to "bullets" and
>> such things to make the text more readable.)
>
> There are a few workarounds and none of them is ideal. I think the
> wrapping length should be customisable in visual-line-mode and then
> longlines-mode can be obsoleted.


(It must be a mistake that longlines-mode is not marked obsolete alreay.)

longlines-mode uses fill-column. IMO visual-line-mode should use
fill-column as the max width.



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

* Re: delete-file to trash
  2010-05-23  2:16       ` Chong Yidong
  2010-05-23  5:00         ` David Kastrup
  2010-05-23  8:57         ` Leo
@ 2010-05-23 13:37         ` Stefan Monnier
  2010-05-23 23:20           ` Chong Yidong
  2 siblings, 1 reply; 48+ messages in thread
From: Stefan Monnier @ 2010-05-23 13:37 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Leo, emacs-devel

>> PS: And yes, for interactive calls to delete-file, the `allow-trash'
>> should be non-nil, I think.
> Yeah, but omitted means nil.  Hmm.

We're talking interactive calls, so it doesn't have to be omitted.
We can set its value to anything we want.

> Here's an idea: allow the variable `delete-by-moving-to-trash' to be a
> list of values of `this-command', for which to trash instead of delete.
> Then we could set the default value of this list to be `delete-file',
> `dired-do-flagged-delete', etc.

I'd rather avoid relying on this-command.


        Stefan



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

* Re: delete-file to trash
  2010-05-23 10:00       ` Lennart Borgman
  2010-05-23 10:15         ` Leo
@ 2010-05-23 13:39         ` Stefan Monnier
  2010-05-23 13:53           ` Lennart Borgman
  1 sibling, 1 reply; 48+ messages in thread
From: Stefan Monnier @ 2010-05-23 13:39 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: Leo, emacs-devel

> I also like `visual-line-mode´ and most of the time has Emacs
> maximized so I wrote `wrap-to-fill-column-mode' for this (part of
> nXhtml). With it you are editing in a middle column (like in Dark Room
> etc).

You can also split the window to set its width as desired.  That will
let you use the extra horizontal space for something useful.


        Stefan



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

* Re: delete-file to trash
  2010-05-23 13:39         ` Stefan Monnier
@ 2010-05-23 13:53           ` Lennart Borgman
  0 siblings, 0 replies; 48+ messages in thread
From: Lennart Borgman @ 2010-05-23 13:53 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

On Sun, May 23, 2010 at 3:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I also like `visual-line-mode´ and most of the time has Emacs
>> maximized so I wrote `wrap-to-fill-column-mode' for this (part of
>> nXhtml). With it you are editing in a middle column (like in Dark Room
>> etc).
>
> You can also split the window to set its width as desired.  That will
> let you use the extra horizontal space for something useful.


Yes, that is useful too. How about adding `set-window-width-to-fill-column'?



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

* Re: delete-file to trash
  2010-05-22 19:37         ` Adrian Robert
  2010-05-23  1:03           ` Stefan Monnier
@ 2010-05-23 14:54           ` Harald Hanche-Olsen
  2010-05-24 13:17             ` Stefan Monnier
  1 sibling, 1 reply; 48+ messages in thread
From: Harald Hanche-Olsen @ 2010-05-23 14:54 UTC (permalink / raw)
  To: emacs-devel

+ Adrian Robert <adrian.b.robert@gmail.com>:

> Regarding trapping, Time Machine uses standard unix hard links, and
> the default FS format for Mac OS is HFS+, the specs for which are
> published here
> (http://developer.apple.com/mac/library/technotes/tn/tn1150.html);
> a GNU/linux driver has been developed.

Actually, it is a bit more complicated than that. As an optimization
feature, if a directory and all its contents are unchanged since the
previous backup, that directory in the latest backup becomes a hard
link to the corresponding directory in the previous backup. This is
one reason Time Machine can only use HFS volumes for Time Machine.
Example:

; ls -1id */mach/System
[...]
14828147 2010-05-19-062015/mach/System/
14828147 2010-05-20-083504/mach/System/
15557200 2010-05-21-184651/mach/System/
15557200 2010-05-22-075716/mach/System/
15808642 2010-05-22-131850/mach/System/
15808642 2010-05-22-144139/mach/System/
15808642 2010-05-22-154126/mach/System/
15808642 2010-05-22-164134/mach/System/
[...]

- Harald



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

* Re: delete-file to trash
  2010-05-23 13:37         ` Stefan Monnier
@ 2010-05-23 23:20           ` Chong Yidong
  2010-05-24 13:16             ` Stefan Monnier
  0 siblings, 1 reply; 48+ messages in thread
From: Chong Yidong @ 2010-05-23 23:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> PS: And yes, for interactive calls to delete-file, the `allow-trash'
>>> should be non-nil, I think.
>> Yeah, but omitted means nil.  Hmm.
>
> We're talking interactive calls, so it doesn't have to be omitted.
> We can set its value to anything we want.

Yeah, there are commands (e.g. shell-command-on-region and clone-buffer)
for which an omitted prefix argument means t.  I was hoping we could
avoid adding more, because most commands do the opposite.  But I guess
there's no completely clean solution to this particular problem.



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

* Re: delete-file to trash
  2010-05-23 23:20           ` Chong Yidong
@ 2010-05-24 13:16             ` Stefan Monnier
  2010-05-24 14:02               ` Leo
  0 siblings, 1 reply; 48+ messages in thread
From: Stefan Monnier @ 2010-05-24 13:16 UTC (permalink / raw)
  To: Chong Yidong; +Cc: Leo, emacs-devel

> Yeah, there are commands (e.g. shell-command-on-region and clone-buffer)
> for which an omitted prefix argument means t.  I was hoping we could

Yes, it's even the recommended way to detect interactive calls (as
explained in the docstring of called-interactively-p):

   This function is meant for implementing advice and other
   function-modifying features.  Instead of using this, it is sometimes
   cleaner to give your function an extra optional argument whose
   `interactive' spec specifies non-nil unconditionally ("p" is a good
   way to do this), or via (not (or executing-kbd-macro noninteractive)).


-- Stefan



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

* Re: delete-file to trash
  2010-05-23 14:54           ` Harald Hanche-Olsen
@ 2010-05-24 13:17             ` Stefan Monnier
  0 siblings, 0 replies; 48+ messages in thread
From: Stefan Monnier @ 2010-05-24 13:17 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

>> Regarding trapping, Time Machine uses standard unix hard links, and
>> the default FS format for Mac OS is HFS+, the specs for which are
>> published here
>> (http://developer.apple.com/mac/library/technotes/tn/tn1150.html);
>> a GNU/linux driver has been developed.

> Actually, it is a bit more complicated than that. As an optimization
> feature, if a directory and all its contents are unchanged since the
> previous backup, that directory in the latest backup becomes a hard
> link to the corresponding directory in the previous backup. This is
> one reason Time Machine can only use HFS volumes for Time Machine.
> Example:

> ; ls -1id */mach/System
> [...]
> 14828147 2010-05-19-062015/mach/System/
> 14828147 2010-05-20-083504/mach/System/
> 15557200 2010-05-21-184651/mach/System/
> 15557200 2010-05-22-075716/mach/System/
> 15808642 2010-05-22-131850/mach/System/
> 15808642 2010-05-22-144139/mach/System/
> 15808642 2010-05-22-154126/mach/System/
> 15808642 2010-05-22-164134/mach/System/
> [...]

Interesting.  So it can't be implemented above just any POSIX filesystem
(where hardlinks are only guaranteed to work for files but not for
directories).


        Stefan



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

* Re: delete-file to trash
  2010-05-24 13:16             ` Stefan Monnier
@ 2010-05-24 14:02               ` Leo
  0 siblings, 0 replies; 48+ messages in thread
From: Leo @ 2010-05-24 14:02 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel

On 2010-05-24 14:16 +0100, Stefan Monnier wrote:
>> Yeah, there are commands (e.g. shell-command-on-region and clone-buffer)
>> for which an omitted prefix argument means t.  I was hoping we could
>
> Yes, it's even the recommended way to detect interactive calls (as
> explained in the docstring of called-interactively-p):

I have modified my local emacs-23 branch according to this discussion.
It's been working great. I have only found two additional changes namely
dired and eshell: http://paste.pocoo.org/show/217693.

Thanks.

Leo



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

* Re: delete-file to trash
  2010-05-23  1:06     ` Stefan Monnier
  2010-05-23  2:16       ` Chong Yidong
@ 2010-05-27 23:36       ` Chong Yidong
  2010-05-28 13:44         ` Michael Albinus
  2010-05-30 18:37         ` Juri Linkov
  1 sibling, 2 replies; 48+ messages in thread
From: Chong Yidong @ 2010-05-27 23:36 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Leo, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So, it seems better to flip the new FORCE argument to delete-file.  We
>> could change it to an argument ALLOW-TRASH, and change the doc of
>> delete-by-moving-to-trash to say that it will only take effect on calls
>> to `delete-file' that use the ALLOW-TRASH argument.  This is backward
>> incompatible but I don't see any better solution.
>
> 100% agreed.

I've just committed a change to do this.  Now, we have to whitelist the
commands that should use trashing.  So far, this includes interactive
calls to `delete-file' and `delete-directory', `speedbar-item-delete',
and `dired-do-flagged-delete' and `dired-do-delete'.

One problem: it would be nice to have a simple interactive way to
inhibit trashing in `dired-do-delete', just like `C-u M-x delete-file'
inhibits trashing.  However, currently the prefix argument is used by
`dired-do-delete' to specify deleting the next N files.



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

* Re: delete-file to trash
  2010-05-27 23:36       ` Chong Yidong
@ 2010-05-28 13:44         ` Michael Albinus
  2010-05-28 17:29           ` Chong Yidong
  2010-05-30 18:37         ` Juri Linkov
  1 sibling, 1 reply; 48+ messages in thread
From: Michael Albinus @ 2010-05-28 13:44 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel, Stefan Monnier, Leo

Chong Yidong <cyd@stupidchicken.com> writes:

> I've just committed a change to do this.

Thanks for doing this also for Tramp. I've seen that you have enabled
the 'trash argument inside tramp-smb-handle-delete-directory. Looks like
it would be desirable to move those files to the recycle bin on MS
Windows systems.

However, I don't know how to do this with smbclient. There are just the
"rm" and "posix_unlink" commands, and they don't have a special handling
for recycle bins. I fear we cannot implement the 'trash argument in
tramp-smb-handle-delete-file.

Best regards, Michael.



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

* Re: delete-file to trash
  2010-05-28 13:44         ` Michael Albinus
@ 2010-05-28 17:29           ` Chong Yidong
  0 siblings, 0 replies; 48+ messages in thread
From: Chong Yidong @ 2010-05-28 17:29 UTC (permalink / raw)
  To: Michael Albinus; +Cc: emacs-devel, Stefan Monnier, Leo

Michael Albinus <michael.albinus@gmx.de> writes:

> Thanks for doing this also for Tramp. I've seen that you have enabled
> the 'trash argument inside tramp-smb-handle-delete-directory. Looks like
> it would be desirable to move those files to the recycle bin on MS
> Windows systems.
>
> However, I don't know how to do this with smbclient. There are just the
> "rm" and "posix_unlink" commands, and they don't have a special handling
> for recycle bins. I fear we cannot implement the 'trash argument in
> tramp-smb-handle-delete-file.

I don't think we should try too hard, then.  Could you update the
sources with comments that say this?



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

* Re: delete-file to trash
  2010-05-27 23:36       ` Chong Yidong
  2010-05-28 13:44         ` Michael Albinus
@ 2010-05-30 18:37         ` Juri Linkov
  1 sibling, 0 replies; 48+ messages in thread
From: Juri Linkov @ 2010-05-30 18:37 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel, Stefan Monnier, Leo

> One problem: it would be nice to have a simple interactive way to
> inhibit trashing in `dired-do-delete', just like `C-u M-x delete-file'
> inhibits trashing.  However, currently the prefix argument is used by
> `dired-do-delete' to specify deleting the next N files.

Maybe `M-0 dired-do-delete'?

-- 
Juri Linkov
http://www.jurta.org/emacs/



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

end of thread, other threads:[~2010-05-30 18:37 UTC | newest]

Thread overview: 48+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-21 19:48 delete-file to trash Leo
2010-05-21 20:15 ` Tassilo Horn
2010-05-21 20:57   ` Leo
2010-05-21 21:12   ` Lennart Borgman
2010-05-21 21:32     ` Tassilo Horn
2010-05-21 21:44       ` Lennart Borgman
2010-05-21 21:58         ` Tassilo Horn
2010-05-21 22:13           ` Lennart Borgman
2010-05-21 23:14             ` Andreas Schwab
2010-05-22  5:36         ` Eli Zaretskii
2010-05-22 10:25           ` Lennart Borgman
2010-05-22  5:37       ` Eli Zaretskii
2010-05-22  9:17         ` Tassilo Horn
2010-05-21 21:39 ` Eli Zaretskii
2010-05-21 21:46   ` Lennart Borgman
2010-05-22  0:52   ` Stefan Monnier
2010-05-22  6:42     ` Adrian Robert
2010-05-22 13:03       ` Stefan Monnier
2010-05-22 19:37         ` Adrian Robert
2010-05-23  1:03           ` Stefan Monnier
2010-05-23 14:54           ` Harald Hanche-Olsen
2010-05-24 13:17             ` Stefan Monnier
2010-05-22  7:32     ` Stephen J. Turnbull
2010-05-22  1:00   ` Drew Adams
2010-05-22  1:50   ` Leo
2010-05-22  0:38 ` Stefan Monnier
2010-05-23  0:09   ` Chong Yidong
2010-05-23  0:27     ` David De La Harpe Golden
2010-05-23  1:06     ` Stefan Monnier
2010-05-23  2:16       ` Chong Yidong
2010-05-23  5:00         ` David Kastrup
2010-05-23  8:57         ` Leo
2010-05-23 13:37         ` Stefan Monnier
2010-05-23 23:20           ` Chong Yidong
2010-05-24 13:16             ` Stefan Monnier
2010-05-24 14:02               ` Leo
2010-05-27 23:36       ` Chong Yidong
2010-05-28 13:44         ` Michael Albinus
2010-05-28 17:29           ` Chong Yidong
2010-05-30 18:37         ` Juri Linkov
2010-05-23  8:20     ` Leo
2010-05-23 10:00       ` Lennart Borgman
2010-05-23 10:15         ` Leo
2010-05-23 11:12           ` Lennart Borgman
2010-05-23 12:14             ` Leo
2010-05-23 12:23               ` Lennart Borgman
2010-05-23 13:39         ` Stefan Monnier
2010-05-23 13:53           ` Lennart Borgman

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.