GNU bug report logs - #60460
30.0.50; [FR] avoid putting remote files to local trash

Previous Next

Full log

Message #13 received at 60460 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: "60460 <at> debbugs.gnu.org" <60460 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#60460: 30.0.50; [FR] avoid putting remote files
 to local trash
Date: Sun, 1 Jan 2023 18:20:22 +0000

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

That's not similar to `recentf'.  There's no reason to 
have options for both include and exclude.  It's enough
to specify what to exclude (that's what `recentf' does).

> and make `delete-by-moving-to-trash' a deprecated alias
> to `delete-by-moving-to-trash-include'. 

I see no need for that.  We can just change the option's
non-nil value (meaning trash something) to be either:

1. A nonempty list of regexps & predicates (like
   `recentf-exclude'), saying what not to trash.
2. Any other non-nil value, meaning exclude nothing,
   i.e., trash everything.

#1 has to be nonempty, as nil means the opposite:
don't move anything to trash.

Alternatively, the option name could be changed, and
a nil (empty-list) value could mean move _everything_
to trash and `t' could mean move nothing to trash.

I don't think it's worth doing that.  I'd suggest
not renaming and just making the change I suggested.
That's backward-compatible: nil still means don't
trash, and non-nil always means trash (something,
maybe everything).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.