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: Why @#! is not Emacs using the Recycle bin on w32? Date: Sun, 31 Aug 2008 07:55:51 +0100 Message-ID: <48BA4077.5040309@harpegolden.net> References: <48B7288E.3040503@gmail.com> <48B73D8F.90501@gmail.com> <48B7AC10.6090800@gmail.com> <48B7B08B.6050103@gmail.com> <48B7F905.7060605@gmail.com> <001301c909e8$d63092e0$0200a8c0@us.oracle.com> <20080829155801.05fabc31.taylor@metasyntax.net> <48B85740.8060309@gmail.com> <20080829164637.4211a5b7.taylor@metasyntax.net> <48B86366.7040303@gmail.com> <87ljyfxz25.fsf@shellarchive.co.uk> <48B87432.6050902@gmail.com> <20080830100336.17179835.taylor@metasyntax.net> <48B95505.50808@gmail.com> <87iqtijfr9.fsf@anzu.internal.golden-gryphon.com> <48B9D20A.6080604@harpegolden.net> <87abetkg7j.fsf@anzu.internal.golden-gryphon.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220165792 16969 80.91.229.12 (31 Aug 2008 06:56:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 06:56:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 08:57:25 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 1KZgrz-0007x9-8I for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 08:57:07 +0200 Original-Received: from localhost ([127.0.0.1]:60984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZgr0-0002RU-Do for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 02:56:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZgqw-0002RP-Cu for emacs-devel@gnu.org; Sun, 31 Aug 2008 02:56:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZgqt-0002RD-U3 for emacs-devel@gnu.org; Sun, 31 Aug 2008 02:56:01 -0400 Original-Received: from [199.232.76.173] (port=36296 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZgqt-0002RA-Nw for emacs-devel@gnu.org; Sun, 31 Aug 2008 02:55:59 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:21967) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZgqs-0005aq-LW for emacs-devel@gnu.org; Sun, 31 Aug 2008 02:55:58 -0400 Original-Received: from harpegolden.net ([65.99.215.13]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZgqr-0000Ib-3o for emacs-devel@gnu.org; Sun, 31 Aug 2008 02:55:57 -0400 Original-Received: from golden1.harpegolden.net (unknown [86.45.10.133]) (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 78C9B81DE for ; Sun, 31 Aug 2008 07:55:54 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <87abetkg7j.fsf@anzu.internal.golden-gryphon.com> X-Enigmail-Version: 0.95.0 X-detected-kernel: by mx20.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-detected-kernel: by monty-python.gnu.org: 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:103299 Archived-At: I don't even _like_ trashcans, sigh... Manoj Srivastava wrote: [quoted out of order] > Sure, I can graft on a trash can, not just to my fvwm based UI, > but also to the console (smallish hack to the unlink system call), but > assuming that such addenda exist would be ... dangerous. I don't think we're really talking about _that_ sort of trashcan implementation (see: libtrash). (They also tend to hoard too many files - using heavy-handed heuristics like "it was in /tmp" to decide whether a file is a temporary/system file that shouldn't be backed up to trash when an app unlinks something - only the individual app or user really knows that for sure...) But... why would we or should we assume that sort of trash exists or otherwise? And wouldn't it be pretty much emacs-transparent anyway? What could emacs do about it? The discussion is about emacs' (existing) support for emacs' "deleting" to trashcans that need (or are basically instantiated by!) _explicit_ application support, where there is an operation or sequence of operations distinct from a simple unlink() that an application uses to explictly try to move something to trash rather than truly deleting it. Like <> Windows [1], MacOSX [2] and Freedesktop.org-specced [3] ones. [1] http://msdn.microsoft.com/en-us/magazine/cc301415.aspx (midway down page, SHFileOperation) [2] NSWorkspaceRecycleOperation http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWorkspace_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSWorkspaceRecycleOperation [3] http://www.freedesktop.org/wiki/Specifications/trash-spec (though presumably apps coded against e.g. the GNOME or KDE framework APIs should be reusing the relevant framework implementation of that spec rather than reimplementing it. Emacs isn't one of those apps though) > Nevertheless, if you assume that Emacs is running in an > environment where there is a trashcan, you will be incorrect. > How much does that matter? If a user turns on emacs' support for his platforms' trashcan*, the trashcan is either: Already there, Or maybe, as per fd.o trashcan spec, emacs creates "it" (that is to say, its specced on-disk representation) upon use if it's not, Or emacs fails to create and/or use it and being an interactive application with a UI and all, can say so and ask the user what to do. "Trashcan unusable because XYZ. Irreversibly delete?" Having it on by default would violate longtime-emacs-user expectations IMO (and be yet another thing for me to turn off in my .emacs), but suggesting much in the way of dire consequences in the event a trashcan doesn't or can't exist but emacs tries to use one is quite unwarranted. If it's on-by-default there are small problems, undoubtedly - most likely, emacs creating and using a trashcan without the user realising** or wanting it to, or, less likely, hitting the user with a "Trashcan unusable..." query as above. On a practical level, that doesn't seem very much different to emacs causing ~/.emacs.d to spring into existence though, or its habit of leaving backup~ files strewn about. Also, the user might not have any means to comfortably browse and restore from the trashcan emacs creates and/or uses if they don't use other programs with a trashcan browser, though hacking dired to provide an emacs-internal trash view looks pretty doable on freedesktop.org-trashcan-using systems (looks harder on macosx and windows, but hey, both of those virtually always have a system trashcan browser). Another way of looking at that case is that in the absence of any other platform trashcan, emacs could be said to be using an fd.o-compliant interoperable trashcan as the "emacs platform" trashcan. * and remember, some basic support is already in-tree, though presently seems to me to be quite broken on my desktop - that has to be fixed before considering turning it on by default. Actually, it has to be fixed regardless... ** Though "File Deleted" messages could be changed to "Moved to Trash" when it is used...