bug#60460: 30.0.50; [FR] avoid putting remote files to local trash

[Jean Louis <bugs@gnu.support>]

* Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> [2023-01-01 23:39]:
> Similar to what we have for "recentf.el" today, we can have two
> variables `delete-by-moving-to-trash-include' and
> `delete-by-moving-to-trash-exclude', and make
> `delete-by-moving-to-trash' a deprecated alias to
> `delete-by-moving-to-trash-include'.  In this case, we can have the
> following logic:

It is better keeping the variable `delete-by-moving-to-trash' as it
is, and then just add different options:

- If TRUE move all files to trash
- If NIL, don't use trash
- If 'local-only move only local files to trash
- If FUNCTION filter files by FUNCTION 

I have not seen you closed the other bug, and that this one is active
when I was answering first time, so here I repeat it:

* Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors
<bug-gnu-emacs@gnu.org> [2023-01-01 11:37]:
> I have been organizing my files lately over multiple devices using
> tramp.  One issue I find with my current setup is that since I set
> `delete-by-moving-to-trash' to t, all files, even the remote ones, are
> moved to my trash directory.

Which does not make sense, and which should be user option.

Look at this bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56511

Where Lars said:

> As the doc string of move-file-to-trash says:

> If the function `system-move-file-to-trash' is defined, call it
>  with FILENAME as an argument.

> So just define a function that checks whether FILENAME is a Tramp
> file name or not, and delete the file if it is, but trash otherwise.

IMHO, in my opinion there will be always more users that know how to
use M-x customize, but not know how to define functions.

I don't think that decision to delete remote files to trash is user
friendly in the first place, and that people using M-x customize are
supposed to even understand "only when the function
`system-move-file-to-trash' is not defined". Defined by who? What
would that mean for somebody who is not Emacs Lisp programmer?!
Probably nothing. User remains helpless here.

Hide Trash Directory: Choice: Value Menu Directory: /home/data1/protected/tmp/Wastebasket/
    State : SAVED and set.
   Directory for ‘move-file-to-trash’ to move files and directories to. Hide
   This directory is used only when the function ‘system-move-file-to-trash’
   is not defined.
   Relative paths are interpreted relative to ‘default-directory’.
   If the value is nil, Emacs uses a freedesktop.org-style trashcan.

I have define my `system-move-file-to-trash' as following, so the
problem is solved individually.

(defun system-move-file-to-trash (filename)
  "Delete only local files.

This is custom local function as recommended by
`move-file-to-trash'."
  (cond ((file-remote-p filename)
         (delete-file filename))
        ((and trash-directory
              (not (string-prefix-p
                    (directory-file-name
                    (file-name-nondirectory
                     (expand-file-name filename)))
                    trash-directory)))
         (make-directory (file-name-as-directory trash-directory) t)
         (rename-file filename (file-name-as-directory trash-directory) t))
        (t (when (y-or-n-p (format "Delete `%s'? "))
             (delete-file filename)))))

However, as you have found out, and I have found out, this problem is
likely to be discovered over and over again by new Tramp users who
wish to use Wastebasket.

> This, unfortunately, harms my workflow because the files I wanted to
> delete include some random multi-gig files, as well as many .git
> directories, both of which greatly bottleneck my file-deletion process.
> I also don't want to disable trashing globally, because I think putting
> local files to trash (which do not introduce a significant delay) is
> still a good idea.

That is how I work as well.

> 1. Allow the user to disable "moving to local trash" only for remote
> files.  I imagine this would entail allowing the user to set
> `delete-by-moving-to-trash' to 'local, and modifying `delete-file',
> `delete-directory', `dired-internal-do-deletions' among other functions
> accordingly.  Alternatively we can have a dedicated variable for this
> purpose.

Good ideas, I wish it could be adopted to become user friendly, one
mouse click and customization and user can be sure that remote files
will not be moved to local Trash.

However we have to think that some users may be using only remote
files and that Trash could eventually be remote as well, right?

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/