delete-file default to buffer-file-name if non-nil

delete-file default to buffer-file-name if non-nil

[Deniz Dogan]

Could we change the behavior of delete-file so that it defaults to
buffer-file-name if non-nil, otherwise the current directory, if
called interactively?

If not, could we make it do so if the command is given an argument?

-- 
Deniz Dogan

Re: delete-file default to buffer-file-name if non-nil

[Davis Herring]

> Could we change the behavior of delete-file so that it defaults to
> buffer-file-name if non-nil, otherwise the current directory, if
> called interactively?

Doesn't it already do that?  M-x delete-file RET does attempt to delete
the current buffer's file or its directory if it has no file.  Personally,
I find this default sort of dangerous, although at least C-x C-w often
fixes it.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: delete-file default to buffer-file-name if non-nil

[Deniz Dogan]

2010/5/15 Davis Herring <herring@lanl.gov>:
>> Could we change the behavior of delete-file so that it defaults to
>> buffer-file-name if non-nil, otherwise the current directory, if
>> called interactively?
>
> Doesn't it already do that?  M-x delete-file RET does attempt to delete
> the current buffer's file or its directory if it has no file.  Personally,
> I find this default sort of dangerous, although at least C-x C-w often
> fixes it.
>
> Davis
>

It seems you are right. The prompt confused me, as it defaults to the
directory which the file is in.

So new suggestion... :) Either the prompt displays the file name for
the current buffer OR the documentation for delete-file is updated to
describe this (in my opinion) non-intuitive behavior. The info node
which briefly describes delete-file says the following:

   `M-x delete-file' deletes the specified file, like the `rm' command
in the shell.  If you are deleting many files in one directory, it may
be more convenient to use Dired rather than `delete-file'.  *Note
Dired::.

What do you say?

-- 
Deniz Dogan

Re: delete-file default to buffer-file-name if non-nil

[Richard Stallman]

    Doesn't it already do that?  M-x delete-file RET does attempt to delete
    the current buffer's file or its directory if it has no file.  Personally,
    I find this default sort of dangerous, although at least C-x C-w often
    fixes it.

It seems dangerous to me too.

RE: delete-file default to buffer-file-name if non-nil

[Drew Adams]

>     Doesn't it already do that?  M-x delete-file RET does 
>     attempt to delete the current buffer's file or its directory
>     if it has no file.  Personally, I find this default sort of
>     dangerous, although at least C-x C-w often fixes it.
> 
> It seems dangerous to me too.

But it seems the most appropriate default value, in terms of what one might want
to delete. Don't you think so?

If it is also dangerous, then some reasonable way should be found to deal with
the danger - as opposed to simply changing the default value.

Two (alternative) solutions that come to mind:

1. Insert the default value in the minibuffer. This assumes that the greatest
danger is hitting RET without seeing what the file to be deleted is.

2. Require confirmation if RET is hit with no file name in the minibuffer.

Perhaps there are other, better alternatives. Of these two, I think #1 is
preferable. 

Re: delete-file default to buffer-file-name if non-nil

[Juri Linkov]

>>     M-x delete-file RET does attempt to delete the current buffer's
>>     file or its directory if it has no file.  Personally, I find this
>>     default sort of dangerous, although at least C-x C-w often
>>     fixes it.
>>
>> It seems dangerous to me too.
>
> But it seems the most appropriate default value, in terms of what one might want
> to delete. Don't you think so?

I think `read-file-name' should not use the default value when it is
not visible either in the prompt (displayed with the standard text
" (default filename): ") or in the minibuffer.

> If it is also dangerous, then some reasonable way should be found to deal
> with the danger - as opposed to simply changing the default value.
>
> Two (alternative) solutions that come to mind:
>
> 1. Insert the default value in the minibuffer. This assumes that the
> greatest danger is hitting RET without seeing what the file to be
> deleted is.

The argument INITIAL-CONTENTS is obsolete and should not be used.
It's possible to insert the default value to the minibuffer with `M-n'.

> 2. Require confirmation if RET is hit with no file name in the minibuffer.

Deleting from Dired requires confirmation, so perhaps `delete-file'
should require confirmation too.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: delete-file default to buffer-file-name if non-nil

[Drew Adams]

> > 1. Insert the default value in the minibuffer. This assumes that the
> > greatest danger is hitting RET without seeing what the file to be
> > deleted is.
> 
> The argument INITIAL-CONTENTS is obsolete and should not be used.
> It's possible to insert the default value to the minibuffer 
> with `M-n'.

So it is.  But I happen to disagree that it should be obsolete. ;-)

A better approach is to let the user decide the behavior.
I have this option (FWIW):

,----
| icicle-default-value is a variable defined in `icicles-opt.el'.
| Its value is t
| 
| Documentation:
| How to treat the default value when reading minibuffer input.
| 
| When the default value argument to functions such as
| `completing-read', `read-file-name', `read-from-minibuffer', and
| `read-string' is non-nil and the initial-input argument is nil or
| "", the default value can be added to the prompt as a hint or
| inserted into the minibuffer as the initial input.
| 
| Adding it to the prompt is the default behavior and corresponds to the
| behavior of vanilla Emacs.
| 
| Inserting the default value in the minibuffer as the initial input has
| the advantage of not requiring you to use `M-n' to retrieve it.  It
| has the disadvantage of making you use `M-p' (or do something else) to
| get rid of the default value in the minibuffer if you do not want to
| use or edit it.  If you often want to use or edit the default value,
| then set `icicle-default-value' to non-nil and non-t.  If you rarely
| do so, then set it to nil or t.
| 
| If inserted in the minibuffer, the value of this option also
| determines whether or not the inserted text is preselected and where
| the cursor is left: at the beginning or end of the text.
| 
| These are the possible option values:
| 
|   nil               - Do not insert default value or add it to prompt.
|   t                 - Add default value to prompt.  Do not insert it.
|   `insert-start'    - Insert default value and leave cursor at start.
|   `insert-end'      - Insert default value and leave cursor at end.
|   `preselect-start' - Insert and preselect default value;
|                       leave cursor at beginning.
|   `preselect-end'   - Insert and preselect default value;
|                       leave cursor at end.
| 
| My own preference is `insert-end'.
| 
| Preselection can be useful in Delete Selection mode or PC Selection
| mode.  It makes it easy to replace the value by typing characters, or
| delete it by hitting `C-d' or `DEL' (backspace).  However, all of the
| initial input is lost if you type or hit `C-d' or `DEL'.  That is
| inconvenient if you want to keep most of it and edit it only slightly.
| 
| You can customize this variable.
`----

Re: delete-file default to buffer-file-name if non-nil

[Stefan Monnier]

>> The argument INITIAL-CONTENTS is obsolete and should not be used.
>> It's possible to insert the default value to the minibuffer
>> with `M-n'.
> So it is.  But I happen to disagree that it should be obsolete. ;-)

You're wrong, of course.

> A better approach is to let the user decide the behavior.
> I have this option (FWIW):
> | When the default value argument to functions such as
> | `completing-read', `read-file-name', `read-from-minibuffer', and
> | `read-string' is non-nil and the initial-input argument is nil or
> | "", the default value can be added to the prompt as a hint or
> | inserted into the minibuffer as the initial input.

IIUC this is not using the initial-contents argument (more to the
point, it's only active if this arg is nil, i.e. if the caller properly
treats it a deprecated).
So this is perfectly compatible with initial-contents's obsolescence.


        Stefan

RE: delete-file default to buffer-file-name if non-nil

[Drew Adams]

> > A better approach is to let the user decide the behavior.
> > I have this option (FWIW):
> >
> > | When the default value argument to functions such as
> > | `completing-read', `read-file-name', `read-from-minibuffer', and
> > | `read-string' is non-nil and the initial-input argument is nil or
> > | "", the default value can be added to the prompt as a hint or
> > | inserted into the minibuffer as the initial input.
> 
> IIUC this is not using the initial-contents argument (more to the
> point, it's only active if this arg is nil, i.e. if the 
> caller properly treats it a deprecated). So this is perfectly
> compatible with initial-contents's obsolescence.

Yes, that option is only about using the default value.

But it was the general idea that it can sometimes be useful to put a value into
the minibuffer that I was trying to get across. I believe that feature can be
useful for the user (hence the default-value option) and in some cases it can be
useful for particular commands (using INIT-VALUE).

The latter cases are admittedly exceptions - I do not propose using INIT-VALUE
often. `delete-file' is a case in point. IMO, if the default file name is put in
the minibuffer as init value it is less likely that a user will inadvertently
hit RET and end up accidentally deleting the file.

You might disagree, but I think that putting the name in the minibuffer draws
more attention to it than just putting it in the prompt - particularly if
INIT-VALUE is seldom used. It is a good compromise between doing nothing
(default in prompt only) and requiring confirmation each time. It gives a little
more protection against accident than just mentioning the file in the prompt,
but it adds no confirmation delay/annoyance.

AFAIK, `delete-file' is not bound to any key by default. Anyone calling it
interactively is doing so either via M-x, via a user-defined key, or via some
other command that calls it interactively. I expect that requiring confirmation
would defeat the aim of quick interaction. 

Remember too: `delete-file' has been around since Day One with exactly the same
user interaction. That's a long time for something "dangerous" to be tolerated.
How many people actually use it interactively? Of those, how many have reported
problems due to the danger in question? Versus: how many of those interactive
users would be annoyed by needing to confirm?

I mentioned two suggestions: (1) put file name in minibuffer or (2) require
confirmation. I didn't see any other suggestions mentioned. I still think #1 is
better overall than #2.

Re: delete-file default to buffer-file-name if non-nil

[Deniz Dogan]

2010/5/17 Drew Adams <drew.adams@oracle.com>:
> I mentioned two suggestions: (1) put file name in minibuffer or (2) require
> confirmation. I didn't see any other suggestions mentioned. I still think #1 is
> better overall than #2.
>

How about #1 with the option of #2 (the default being no confirmation)?

-- 
Deniz Dogan

Re: delete-file default to buffer-file-name if non-nil

[Juri Linkov]

> I mentioned two suggestions:
> (1) put file name in minibuffer or
> (2) require confirmation.

(3) put file name in the prompt "(default filename): "
(4) don't use the default value when RET is typed with empty input.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: delete-file default to buffer-file-name if non-nil

[Juri Linkov]

> (4) don't use the default value when RET is typed with empty input.

This means using the same UI as is used by `find-file...'
with a function like `find-file-read-args' in the interactive spec:

=== modified file 'src/fileio.c'
--- src/fileio.c	2010-05-08 18:47:07 +0000
+++ src/fileio.c	2010-05-18 22:37:17 +0000
@@ -2194,7 +2194,10 @@ (directory-file-name (file-name-director
   return Qnil;
 }
 
-DEFUN ("delete-file", Fdelete_file, Sdelete_file, 1, 2, "fDelete file: \nP",
+DEFUN ("delete-file", Fdelete_file, Sdelete_file, 1, 2,
+       "(list (read-file-name \"Delete file: \" nil default-directory \
+                (confirm-nonexistent-file-or-buffer))                 \
+              current-prefix-arg)",
        doc: /* Delete file named FILENAME.  If it is a symlink, remove the symlink.
 If file has multiple names, it continues to exist with the other names.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: delete-file default to buffer-file-name if non-nil

[Richard Stallman]

    But it seems the most appropriate default value, in terms of what one might want
    to delete. Don't you think so?

That is true also, but it does not make the danger go away.

    2. Require confirmation if RET is hit with no file name in the minibuffer.

I like that solution.  But confirmation should be with y, not RET,
in order to follow Emacs conventions.