From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Timur Aydin Newsgroups: gmane.emacs.devel Subject: Re: Question about handling file deletion Date: Sat, 29 Jun 2013 16:37:25 +0300 Message-ID: <51CEE315.1020803@taydin.org> References: <87zjud5aej.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.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 1372513083 12492 80.91.229.3 (29 Jun 2013 13:38:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Jun 2013 13:38:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 29 15:38:03 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UsvLl-0005kq-6u for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2013 15:38:01 +0200 Original-Received: from localhost ([::1]:42717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsvLk-0004Zc-R8 for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2013 09:38:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UsvLh-0004ZC-BL for emacs-devel@gnu.org; Sat, 29 Jun 2013 09:37:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UsvLf-0006pM-NK for emacs-devel@gnu.org; Sat, 29 Jun 2013 09:37:57 -0400 Original-Received: from oproxy9.bluehost.com ([69.89.24.6]:55001) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1UsvLf-0006ot-F4 for emacs-devel@gnu.org; Sat, 29 Jun 2013 09:37:55 -0400 Original-Received: (qmail 29887 invoked by uid 0); 29 Jun 2013 13:37:31 -0000 Original-Received: from unknown (HELO box401.bluehost.com) (69.89.31.201) by oproxy9.bluehost.com with SMTP; 29 Jun 2013 13:37:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=taydin.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=1Lu3Tn7v2mLbQZXvDXy4ExdD6jrs9phKArGop8+QsWo=; b=bPzUkQVU4LVGdGOXrVg7cT3qaIyY3ksPrLk06IW93kVBtKJaCbovldUy3Q4wpoPVhYDtwFqWZ24/qbF3DzQhM6OfbjGTDLzWe126KzvACPW5R7G9l1n5qKJWsvg+YAYQ; Original-Received: from [176.41.233.165] (port=60770 helo=[10.2.1.100]) by box401.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsvLG-0005EF-HQ for emacs-devel@gnu.org; Sat, 29 Jun 2013 07:37:30 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: <87zjud5aej.fsf@rosalinde.fritz.box> X-Identified-User: {1590:box401.bluehost.com:taydinor:taydin.org} {sentby:smtp auth 176.41.233.165 authed with ta@taydin.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 69.89.24.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:161271 Archived-At: On 6/26/2013 3:22 PM, Stephen Berman wrote: > If a package provides functionality for deleting files used by it, is it > considered a bug in the package if it does not handle the situation > where a user deletes such files using a command outside of the package > and this causes errors when using the package which don't arise if the > package file-deletion functionality is used? I'm faced with this issue > in the new version of todo-mode.el (see bug#14688). If someone deletes > a todo file using e.g. Dired and then gets an error in Todo mode and > reports it as a bug, is it kosher for me reply "If it hurts, don't do > that. Use todo-delete-file." and close the bug? (That command doesn't > actually exist yet, but I think it will be much easier to implement than > trying to handle the result of deleting todo files outside of Todo > mode.) When I visit a file and then delete that file using "rm", the buffer of that file is still there and emacs doesn't do anything about it. So if somebody deletes a TODO file, why not let the todo information stay in the respective buffer? So what is different about todo-mode.el that makes it necessary to implement a different behavior? I'm not criticizing you motivation, only trying to understand the situation better. -- Timur