From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Question about handling file deletion Date: Thu, 27 Jun 2013 00:36:57 +0200 Message-ID: <87mwqc5wja.fsf@rosalinde.fritz.box> References: <87zjud5aej.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1372286236 1469 80.91.229.3 (26 Jun 2013 22:37:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Jun 2013 22:37:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 27 00:37:16 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 1UryKx-0000kr-Ly for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2013 00:37:15 +0200 Original-Received: from localhost ([::1]:35071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UryKx-00083X-Aa for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2013 18:37:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UryKn-00081W-Mm for emacs-devel@gnu.org; Wed, 26 Jun 2013 18:37:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UryKi-0002HX-IJ for emacs-devel@gnu.org; Wed, 26 Jun 2013 18:37:05 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:57087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UryKi-0002Gz-71 for emacs-devel@gnu.org; Wed, 26 Jun 2013 18:37:00 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mee5m-1UcVsp101Y-00OKDG for ; Thu, 27 Jun 2013 00:36:59 +0200 Original-Received: (qmail invoked by alias); 26 Jun 2013 22:36:58 -0000 Original-Received: from i59F57B02.versanet.de (EHLO rosalinde.fritz.box) [89.245.123.2] by mail.gmx.net (mp033) with SMTP; 27 Jun 2013 00:36:58 +0200 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1/N3SBp8ZfNHQF53ltZNieC7GvW2T5ZTVxdcHVBaf M5kQ5WMfHcNLaS In-Reply-To: (Stefan Monnier's message of "Wed, 26 Jun 2013 10:33:19 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.20 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:161115 Archived-At: On Wed, 26 Jun 2013 10:33:19 -0400 Stefan Monnier wrote: >> 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 > > There's no rule, but usually it's OK for Emacs to misbehave slightly in > such circumstances, tho it's also usually he case that Emacs tries to > handle such cases gracefully. > > IOW it depends: should it be obvious to the user that just "rm"ing the > file will lead to an error? > E.g. can she still see a reference to the file somewhere else)? If the > remaining ("dangling") reference to the lost file is not shown to the > user, than Emacs should work harder to try and handle the > disappearance seamlessly. I'm not sure I understand what you mean by "reference to the lost file". The Todo mode state includes a list of all todo files, which is exposed to users for e.g. minibuffer completion. If a file is deleted from outside of Todo mode, this list won't be updated, so in that sense it contains a "reference to the lost file", which the user can see. But while the user presumably knows the file is missing, Todo mode doesn't, and that can lead to errors, especially if a live buffer is still holding the content of the deleted file and the user calls a Todo command to manipulate the buffer. This problem can be avoided with a todo-delete-file command which updates the file list. But that doesn't help if it's possible to delete a file behind Todo mode's back. What would help is a delete-file-hook, but that doesn't exist AFAIK. The only other alternative I can think of is to build the needed checks into each Todo command that could manipulate a file or a buffer visiting a file. Do other packages go to such lengths? Some don't, e.g., if you delete a mail file without telling Gnus, Gnus will try to open it and signal an error (and not what you might think: gnus-request-expire-articles: Wrong type argument: stringp, nil). I guess it's taken for granted that you're only supposed to delete mail files by using commands provided by the mail client. I would like the same kind of assumption to be made for Todo mode; but maybe that's asking too much. Steve Berman