Re: Question about handling file deletion

[Stephen Berman <stephen.berman@gmx.net>]

On Wed, 26 Jun 2013 10:33:19 -0400 Stefan Monnier <monnier@iro.umontreal.ca> 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