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

[Ruijie Yu]

Drew Adams <drew.adams@oracle.com> writes:

>> In response to this, I want to propose a change to the logic under which
>> trashing is performed rather than deletion.  However, I am not sure
>> which one of my following two ideas is more appropriate.
>>
>> 1. Allow the user to disable "moving to local trash" only for remote
>> files....
>> 2. Use a dedicated local trash directory for each remote, optionally
>> behind a toggle.
>
> (Caveat: I'm not knowledgeable about sending
> files to trash.)
>
> I would have thought that we already have a way
> for users to customize which files and dirs get
> sent to trash.
>
> Now I see that option `delete-by-moving-to-trash'
> is just a simple nil/t Boolean, as opposed to
> being nil (for don't trash) and non-nil for the
> possibility of filtering.
>
> Not trashing remote files is just one kind of
> filtering.  And you say that you want to do that
> in particular because some of your remote files
> are large.  Filtering out large files (local or
> remote) is another possibility (logically not
> the same as filtering out remote files).
>
> Users could have any number of criteria they
> want to use, to filter inclusion/exclusion of
> files to move to trash.
>
> Why not use a mechanism similar to what we use
> with `recentf.el'?  There, we have user option
> `recentf-exclude'.  That lets you use multiple
> regexps and predicates to specify the files
> you want to exclude from inclusion in the list
> of recent files.

Yes, that sounds like a good idea as well.  To expand on your idea, here
are my thoughts.

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:

1. If both variables are nil, disable trashing;

2. If `dbmtt-include' is not a list, issue a warning (because now we
want a list) and enable universal trashing;

3. Handle predicates and regexps in `dbmtt-include' and `dbmtt-exclude'
similar to how these in `recentf-include' and `recentf-exclude' are
handled in "recentf.el".

One concern I have with this approach is the added complexity to file
deletion logic.  That is, whenever a file needs to be deleted with
trashing potential (TRASH is passed in as non-nil for the relevant
functions), the two lists need to be consulted for this file and all
predicates and regexps need to be run against its filename.

Best,


RY