unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Ruijie Yu <ruijie@netyu.xyz>
Cc: Drew Adams <drew.adams@oracle.com>,
	"60460@debbugs.gnu.org" <60460@debbugs.gnu.org>
Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Mon, 2 Jan 2023 06:40:44 +0300	[thread overview]
Message-ID: <Y7JSPBgq9zTtCjD+@protected.localdomain> (raw)
In-Reply-To: <sdvmt726v9j.fsf@fw.net.yu>

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





  parent reply	other threads:[~2023-01-02  3:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-31 16:34 bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 16:41 ` Drew Adams
2023-01-01 16:47   ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 18:20     ` Drew Adams
2023-01-02  3:40     ` Jean Louis [this message]
2023-01-02  9:09 ` Michael Albinus
2023-01-02 10:35   ` Jean Louis
2023-01-02 10:47     ` Michael Albinus
2023-01-02 16:28       ` Jean Louis
2023-01-02 18:30         ` Michael Albinus
2023-01-02 20:37           ` Jean Louis
2023-01-03  8:47             ` Michael Albinus
2023-01-03 13:53               ` Jean Louis
2023-01-07  3:53               ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-07 12:48                 ` Michael Albinus
2023-01-08  0:37                   ` Jean Louis
2023-01-08  9:20                     ` Michael Albinus
2023-01-08 18:29               ` Michael Albinus
2023-02-02  8:56                 ` Michael Albinus
  -- strict thread matches above, loose matches on Subject: below --
2023-01-01 14:20 bug#60462: " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-31 21:46 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]   ` <handler.60462.D60462.16726054692608.notifdone@debbugs.gnu.org>
2023-01-02  9:16     ` bug#60460: " Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7JSPBgq9zTtCjD+@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=60460@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=ruijie@netyu.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

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