delete-file to trash

delete-file to trash

[Leo]

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

Re: delete-file to trash

[Tassilo Horn]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Lennart Borgman]

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.

Re: delete-file to trash

[Tassilo Horn]

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

Re: delete-file to trash

[Lennart Borgman]

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?

Re: delete-file to trash

[Tassilo Horn]

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

Re: delete-file to trash

[Lennart Borgman]

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.

Re: delete-file to trash

[Andreas Schwab]

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

Re: delete-file to trash

[Eli Zaretskii]

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

Re: delete-file to trash

[Lennart Borgman]

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.

Re: delete-file to trash

[Eli Zaretskii]

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

Re: delete-file to trash

[Tassilo Horn]

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

Re: delete-file to trash

[Eli Zaretskii]

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

Re: delete-file to trash

[Lennart Borgman]

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.

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Adrian Robert]

> 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

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Adrian Robert]

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

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Harald Hanche-Olsen]

+ 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

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Stephen J. Turnbull]

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

RE: delete-file to trash

[Drew Adams]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Stefan Monnier]

> 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

Re: delete-file to trash

[Chong Yidong]

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

Re: delete-file to trash

[David De La Harpe Golden]

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.

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Chong Yidong]

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.

Re: delete-file to trash

[David Kastrup]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Stefan Monnier]

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

Re: delete-file to trash

[Chong Yidong]

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.

Re: delete-file to trash

[Stefan Monnier]

> 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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Chong Yidong]

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.

Re: delete-file to trash

[Michael Albinus]

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.

Re: delete-file to trash

[Chong Yidong]

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?

Re: delete-file to trash

[Juri Linkov]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Lennart Borgman]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Lennart Borgman]

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

Re: delete-file to trash

[Leo]

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

Re: delete-file to trash

[Lennart Borgman]

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.

Re: delete-file to trash

[Stefan Monnier]

> 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

Re: delete-file to trash

[Lennart Borgman]

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'?