From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Concerning delete-by-moving-to-trash on free systems Date: Thu, 27 Nov 2008 14:35:14 +0000 Message-ID: <492EB022.8080905@harpegolden.net> References: <87od01tr8o.fsf@thinkpad.tsdh.de> <492E9E4D.7040108@harpegolden.net> <87d4ghtgkf.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227796574 17211 80.91.229.12 (27 Nov 2008 14:36:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Nov 2008 14:36:14 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 27 15:37:17 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L5hzK-0007Ui-PU for ged-emacs-devel@m.gmane.org; Thu, 27 Nov 2008 15:37:03 +0100 Original-Received: from localhost ([127.0.0.1]:37614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5hyA-0003TW-PP for ged-emacs-devel@m.gmane.org; Thu, 27 Nov 2008 09:35:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5hxh-0002yr-Q0 for emacs-devel@gnu.org; Thu, 27 Nov 2008 09:35:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5hxf-0002w2-MU for emacs-devel@gnu.org; Thu, 27 Nov 2008 09:35:21 -0500 Original-Received: from [199.232.76.173] (port=46121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5hxf-0002vo-Dd for emacs-devel@gnu.org; Thu, 27 Nov 2008 09:35:19 -0500 Original-Received: from harpegolden.net ([65.99.215.13]:50444) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5hxf-0003OE-05 for emacs-devel@gnu.org; Thu, 27 Nov 2008 09:35:19 -0500 Original-Received: from [87.198.54.45] (87-198-54-45.ptr.magnet.ie [87.198.54.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 90D4B81E2 for ; Thu, 27 Nov 2008 14:35:16 +0000 (GMT) User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) In-Reply-To: <87d4ghtgkf.fsf@thinkpad.tsdh.de> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106232 Archived-At: Tassilo Horn wrote: > Nice! Why do you fallback to ~/.local/share/ in > move-file-to-trash-freedesktop. With the predicate you already checked > that XDG_DATA_HOME is set. If it's not set in > move-file-to-trash-freedesktop I'd expect an error. > XDG_DATA_HOME is not guaranteed to be set in nonetheless freedesktop.org compliant environments (it's not set on my desktop running the generally-highly-fd.o XFCE4!): http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html | $XDG_DATA_HOME defines the base directory relative to which user | specific data files should be stored. If $XDG_DATA_HOME is either not | set or empty, a default equal to $HOME/.local/share should be used. So if it's not set, you're supposed to just go ahead and use the default. It's just an override to allow people to use something other than .local/share if they want to. Note the predicate didn't _only_ check if it's set, that check is one part of a fast+loose "so, is this a freedesktop.org desktop where using this kind of trashcan would be appropriate" cascade of tests in move-file-to-trash--freedesktop-p. I figured having XDG_DATA_HOME was adequate to indicate a fd.o desktop, but its absence does not mean a non-fd.o desktop. I guess really, the fd.o model is apps decide to be partially or fully fd.o compliant, not that there's an easy way to check for fd.o-ness... but I might be wrong there: If it's a thing that there's a more reliable way to tell "yes, nancy, this IS a freedesktop.org desktop", then move-file-to-trash--freedesktop-p could be simplified. If it's actually okay for emacs to use the freedesktop-style trashcan by default rather than the builtin emacs "fallback" trashcan support, then the move-file-to-trash--freedesktop-p test could be dropped and the patch slightly simplified. Note that it's really only one side of comprehensive trashcan support (the writing side). While it's not urgent (since most people interested in fd.o trashcans can presumably use their desktop environment file manager's trashcan interface), for the reading side, someone might conceivably want a dired that's trashcan-aware, so that you could browse the traschcan in a slightly extended dired view that offers a restore option (and at least with the metadata-available fd.o-style trashcan (and probably some others) it'd also be possible for dired to offer restorations of files when you're browsing a directory that has ex-members in the trashcan...). That's generally more complicated e.g. while my patch for _writing_ to trashcan avails of the option not to use per-volume trashcans in the relevant spec, _reading_ from trash properly should probably not disregard the existence of per-volume trash.