From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Question about handling file deletion Date: Fri, 28 Jun 2013 18:40:42 -0400 Message-ID: References: <87zjud5aej.fsf@rosalinde.fritz.box> <87mwqc5wja.fsf@rosalinde.fritz.box> <87d2r6zl5j.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1372459252 11193 80.91.229.3 (28 Jun 2013 22:40:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Jun 2013 22:40:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Berman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 29 00:40:52 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 1UshLU-0002CY-8v for ged-emacs-devel@m.gmane.org; Sat, 29 Jun 2013 00:40:48 +0200 Original-Received: from localhost ([::1]:42896 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UshLT-0002hA-Mn for ged-emacs-devel@m.gmane.org; Fri, 28 Jun 2013 18:40:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UshLQ-0002h5-Q7 for emacs-devel@gnu.org; Fri, 28 Jun 2013 18:40:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UshLP-0003oH-PC for emacs-devel@gnu.org; Fri, 28 Jun 2013 18:40:44 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:31861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UshLP-0003oD-KN for emacs-devel@gnu.org; Fri, 28 Jun 2013 18:40:43 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCppA/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2NDYN9A6R6gV6DE4FK X-IPAS-Result: Av4EABK/CFFMCppA/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2NDYN9A6R6gV6DE4FK X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="17416405" Original-Received: from 76-10-154-64.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([76.10.154.64]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Jun 2013 18:40:37 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 7BBE3AE2E1; Fri, 28 Jun 2013 18:40:42 -0400 (EDT) In-Reply-To: <87d2r6zl5j.fsf@rosalinde.fritz.box> (Stephen Berman's message of "Fri, 28 Jun 2013 10:36:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:161254 Archived-At: > E.g. bug#14688. If you have debug-on-error enabled, you get the two > backtraces Leo reported (wrong-type-argument due to (find-file-noselect > nil), followed by file-error "Removing old name" "no such file or > directory" due to calling delete-file on the file that was already > deleted). But if debug-on-error is disabled, you just get "Removing old > name: no such file or directory, /data/steve/.emacs.d/todo/Todo.todo" in > the echo area and above it a buffer in Todo mode whose name is the todo > file you just created. If you try to add a category, you get > "find-file-noselect: Wrong type argument: stringp, nil". If you > mistakenly think there is a category and try to navigate with `f' or > `b', you get "todo-forward-category: Arithmetic error"; if you try to > insert an item with e.g. `i i' you get prompted but after typing the > item text and hitting RET, you get "todo-basic-insert-item: Args out of > range: 1, 2". Similar errors and other odd behavior can occur if you > leave the Todo mode buffer live after deleting the file, and can arise > later, after adding more todo files and using other commands. So I > guess I have to bite the bullet and make Todo mode catch these errors. Indeed, these errors seem annoying enough that we should try to handle it a bit better. Stefan