bug#9361: 24.0.50; default value of `dired-do-chmod'

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

This command was better before we added a default value (in Emacs 23).
 
For one thing, the default value is a bit confusing - it uses one of the
several possible syntaxes for `chmod' - the most verbose one, which
means the most editing.
 
For another thing, the default value comes from the current permissions
of the first file that is marked.  Privileging that file makes little or
no sense when there are multiple files marked.  A better value would
come from the _minimum_ permissions for each of u, g, o, among all the
files marked.  A different argument could be made that the permissions
of the current line should be used - to apply them without editing to
all of the marked files.
 
But even with such possible changes, I think it's a bad idea to provide
any default for this command.
 
For a third thing, if someone picks up that default value then more
editing is required than just starting from nothing.  It is a lot easier
to type `g-w' than it is to back up the right number of chars and edit
the `g=rw' (or whatever the current `g' permissions are) part of the
default value, to get the proper new absolute permissions value for `g'.
 
For a fourth thing, if the permissions are currently the same (for the
first file, which is privileged here), then `a=rw' (or whatever the
current permissions are) is a better default than `u=rw, g=rw, o=rw'.
For one thing it is quicker to read and manipulate.  For another, it
teaches users that they can use `a' as a shortcut.
 
The best approach is not to provide any default value here.  A user of
this Emacs command needs to know UNIX `chmod' anyway, and if known then
it is not hard to type the permissions from scratch.
 
If you really want to improve this, then let, say, `?' give some short
help about `chmod' - e.g. present an example.  But a default value is
not helpful here.
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-08-22 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt'
 

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

> For another thing, the default value comes from the current permissions
> of the first file that is marked.  Privileging that file makes little or
> no sense when there are multiple files marked.  A better value would
> come from the _minimum_ permissions for each of u, g, o, among all the
> files marked.  A different argument could be made that the permissions
> of the current line should be used - to apply them without editing to
> all of the marked files.

It's intended to do something like this in 24.2 as described in
http://thread.gmane.org/gmane.emacs.devel/81414/focus=82988

> The best approach is not to provide any default value here.  A user of
> this Emacs command needs to know UNIX `chmod' anyway, and if known then
> it is not hard to type the permissions from scratch.

If you don't want the default value, just don't use it, don't type M-n.
But for those who like to reduce typing and remembering different
syntaxes it intentionally uses the most verbose and easy to remember syntax
that is closest to the syntax of modes displayed in the left column
of the Dired buffer.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Lars Magne Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> If you don't want the default value, just don't use it, don't type M-n.

I agree, so I'm closing this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

> I agree, so I'm closing this report.

I disagree, so I'm reopening it.

In the _very_ long thread cited by Juri, there was only one comment on this
proposal for a default value for `dired-do-chmod' etc. It was from RMS:

 "I am not sure that this is very useful.  What are the values
  you think of providing?"

There was no followup, and this was never approved.

Juri makes the argument that this is handy because it lets you easily copy the
permissions from "the marked file" and reuse them elsewhere.

That is no argument when more than one file is marked.  In fact it might be an
argument for using as default the file of the current (cursor) line.  It makes
absolutely no sense to privilege the first of a non-singleton set of marked
files.

In reality, it is an argument for having a separate command to copy the settings
(all of them) from the current line and then having, as default value for each
of the `*ch*' commands, the value taken from that copied setting.  And this
would apply across Dired buffers, giving you an easy way to apply a particular
set of values (settings).  It could perhaps also apply to other Dired commands,
such as `touch' (dunno).

The point is that if we are going to copy settings from a particular file in
order to make them available for, essentially, pasting operations to other
files, then the target file being copied from should be clear.  The copy
operation should be an explicit user choice, not something implicit, based only
on the first marked file (why not the last? or the 23rd?).

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Chong Yidong]

I think there's a problem here, indeed.  It's a bad idea to take an
empty input to mean a certain default permission---especially when that
default permission is not displayed in the prompt.

The following patch makes dired-do-chmod demand a non-empty input.  The
precomputed permission is still available in the M-n `future history'.

*** lisp/dired-aux.el	2011-08-04 00:58:07 +0000
--- lisp/dired-aux.el	2011-09-11 21:38:35 +0000
***************
*** 267,272 ****
--- 267,280 ----
  	 (format "%s: error" operation)
  	 nil))))
  
+ (defun dired--read-permission-string (prompt default)
+   (let ((result ""))
+     (while (equal result "")
+       (setq result
+ 	    (read-from-minibuffer prompt nil nil
+ 				  nil nil default)))
+     result))
+ 
  ;;;###autoload
  (defun dired-do-chmod (&optional arg)
    "Change the mode of the marked (or next ARG) files.
***************
*** 284,292 ****
  			 (match-string 1 modestr)
  			 (match-string 2 modestr)
  			 (match-string 3 modestr)))))
! 	 (modes (dired-mark-read-string
! 		 "Change mode of %s to: " nil
! 		 'chmod arg files default))
  	 (num-modes (if (string-match "^[0-7]+" modes)
  			(string-to-number modes 8))))
      (dolist (file files)
--- 292,303 ----
  			 (match-string 1 modestr)
  			 (match-string 2 modestr)
  			 (match-string 3 modestr)))))
! 	 (modes
! 	  (dired-mark-pop-up nil 'chmod files
! 			     'dired--read-permission-string
! 			     (format "Change mode of %s to: "
! 				     (dired-mark-prompt arg files))
! 			     default))
  	 (num-modes (if (string-match "^[0-7]+" modes)
  			(string-to-number modes 8))))
      (dolist (file files)

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

> I think there's a problem here, indeed.  It's a bad idea to take an
> empty input to mean a certain default permission---especially when that
> default permission is not displayed in the prompt.
>
> The following patch makes dired-do-chmod demand a non-empty input.  The
> precomputed permission is still available in the M-n `future history'.

There are other demands that dired commands should not use `read-string'
that returns the default value for an empty input.  Please see
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01200.html

So we should either change `read-string' (backward-incompatible change)
or to change `dired-mark-read-string' not to use `read-string'.

Another solution is to add a new global variable that changes the default
behavior of `read-string' and let-bind it in `dired-mark-read-string'.

> +     (while (equal result "")
> +       (setq result
> + 	    (read-from-minibuffer prompt nil nil
> + 				  nil nil default)))

I think it should tell the user what's wrong, like `read-number' does
with "Please enter a number."

Too bad that currently semantically similar functions
`read-string' and `read-number' differ significantly
WRT handling an empty input and default values.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> I think there's a problem here, indeed.  It's a bad idea to take an
>> empty input to mean a certain default permission---especially when that
>> default permission is not displayed in the prompt.
>>
>> The following patch makes dired-do-chmod demand a non-empty input.  The
>> precomputed permission is still available in the M-n `future history'.
>
> There are other demands that dired commands should not use `read-string'
> that returns the default value for an empty input.  Please see
> http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01200.html
>
> So we should either change `read-string' (backward-incompatible change)
> or to change `dired-mark-read-string' not to use `read-string'.

I fixed up `dired-mark-read-string'; that's much safer, since there are
only three callers to worry about.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

> I fixed up `dired-mark-read-string'; that's much safer, since there are
> only three callers to worry about.

Thank you, it's now safer.

There are still two problems:

In `dired-do-chmod':

>        (modes (dired-mark-read-string
>                "Change mode of %s to: "
>                ;; Insert initial input if there's only one file.
>                (unless (cadr files) default)
>                'chmod arg files default))

Please don't insert the default value as initial input.
Most of the time, users type short symbolic modes that
add/remove permissions on one user part such as "a=rw" or "go-w".
It would be annoying for them to delete initial input
before typing symbolic modes.

Another problem in `dired-mark-read-string':

> STANDARD-VALUE, if non-nil, should be a \"standard\" value or
> list of such values, available via history commands.

STANDARD-VALUE is non-standard terminology.  According to
`read-from-minibuffer' it's named DEFAULT-VALUE.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Please don't insert the default value as initial input.
> Most of the time, users type short symbolic modes that
> add/remove permissions on one user part such as "a=rw" or "go-w".
> It would be annoying for them to delete initial input
> before typing symbolic modes.

Fair enough; deleted.

>> STANDARD-VALUE, if non-nil, should be a \"standard\" value or
>> list of such values, available via history commands.
>
> STANDARD-VALUE is non-standard terminology.  According to
> `read-from-minibuffer' it's named DEFAULT-VALUE.

I don't like DEFAULT-VALUE, because it's not the default returned by
empty input.  But I guess we should be consistent with
read-from-minibuffer, so I changed it.  We should revisit this issue at
some point (in read-from-minibuffer too).

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

>>> STANDARD-VALUE, if non-nil, should be a \"standard\" value or
>>> list of such values, available via history commands.
>>
>> STANDARD-VALUE is non-standard terminology.  According to
>> `read-from-minibuffer' it's named DEFAULT-VALUE.
>
> I don't like DEFAULT-VALUE, because it's not the default returned by
> empty input.  But I guess we should be consistent with
> read-from-minibuffer, so I changed it.  We should revisit this issue at
> some point (in read-from-minibuffer too).

Yes, we should revisit this issue later.  Nowadays established
terminology for functionality of accessing additional values
(like in web browser's autocompletion) is SUGGESTIONS.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

> In the _very_ long thread cited by Juri, there was only one comment on this
> proposal for a default value for `dired-do-chmod' etc. It was from RMS:
>
>  "I am not sure that this is very useful.  What are the values
>   you think of providing?"
>
> There was no followup, and this was never approved.

There was followup, but off-list unfortunately.  I replied to RMS with:

  "The values are file attributes of all marked files (modes for M,
   owners for O, groups or G, timestamps for T).  But now I see that
   these values are not very useful, so I withdraw my proposal."

And RMS encouraged to do this for just one marked file:

  "When there is just one marked file, the feature could indeed be useful.
   So I suggest you limit it to that case, and document clearly where the
   default comes from, so that people will know how they can make use
   of the feature."

> In reality, it is an argument for having a separate command to copy the settings
> (all of them) from the current line and then having, as default value for each
> of the `*ch*' commands, the value taken from that copied setting.  And this
> would apply across Dired buffers, giving you an easy way to apply a particular
> set of values (settings).  It could perhaps also apply to other Dired commands,
> such as `touch' (dunno).

Isn't what `M-.' you proposed earlier should do, i.e. pull the value
from the buffer where the command was called?

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

> And RMS encouraged to do this for just one marked file:
> 
>   "When there is just one marked file, the feature could 
>    indeed be useful. So I suggest you limit it to that case,
>    and document clearly where the default comes from, so that
>    people will know how they can make use of the feature."

Great minds think alike. ;-)

That was also one of my points: it doesn't make sense to do this when more than
one file is marked.  There is no reason to privilege the "first" of the set of
marked files.

> > In reality, it is an argument for having a separate command 
> > to copy the settings (all of them) from the current line and
> > then having, as default value for each of the `*ch*' commands,
> > the value taken from that copied setting.  And this
> > would apply across Dired buffers, giving you an easy way to 
> > apply a particular set of values (settings).  It could perhaps
> > also apply to other Dired commands, such as `touch' (dunno).
> 
> Isn't what `M-.' you proposed earlier should do, i.e. pull the value
> from the buffer where the command was called?

No, I don't think so.  I don't recall just what I proposed, but `M-.' in Icicles
(on which I no doubt based my proposal) pulls into the minibuffer various things
at/near point.

In this case, that is not what I propose.  The user should not have to move
point to the permissions section to be able to get permissions etc.

More importantly, what I'm proposing here is a _copy_ command, which copies file
information for the file/dir of the current line.  All available and pertinent
file info would be copied.  Then, the individual commands (`chmod' etc.) would
have available, either (a) as default value (mentioned above) or (b) on-demand
via a different minibuffer key from `M-n', the pertinent part of the copied
info.  E.g., for command `chmod', it is the file permissions part of the copied
info that is pertinent, so (only) that would be used.  For command `touch', it
is the mod time of the copied file info that is pertinent, so that would be
used.

(This is akin to what is available in some editors for copying special
properties (e.g. XML attributes, face/font info, conditional text values) and
making them available via a `Paste Special' command.  Whatever the last type of
special copy, the `Paste Special' pastes that to its target.)

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

This bug has not at all been fixed - AFAICT, everything I reported is still a
problem.  It should not have been closed.

I tried to reopen this bug.  It was archived (that's what comes from waiting for
a response).  I unarchived it (successfully).  The unarchive message told me
that unarchiving does not reopen the bug.  So I then tried to reopen it again.
No reply to my "reopen" mail - no change: still not reopened.

I tried to reopen it again just now.  Still no reply message and no change.

There was never any response to what I reported as the bug.  Instead, as is all
too common, there was a side discussion... and that was it.  The bug was closed
without anyone ever addressing what I reported as the problem.

You apparently fixed your own choice of a problem, which was not the problem
that was reported.  The default value of `dired-do-chmod' is still the same,
inappropriate value. There is no reason to pick up the permissions from the
_first_ of the marked files - makes no sense at all.  And it is still not made
clear to users which file the permissions are being copied from.  Please read
the bug report, and the followup passage cited below.

Do I need to open a new bug and copy the 9361 report to it, i.e., to start over?

> ping.
> 
> > Juri makes the argument that this is handy because it lets 
> > you easily copy the permissions from "the marked file" and
> > reuse them elsewhere.
> > 
> > That is no argument when more than one file is marked.  In 
> > fact it might be an argument for using as default the file
> > of the current (cursor) line.  It makes absolutely no sense
> > to privilege the first of a non-singleton set of marked files.
> > 
> > In reality, it is an argument for having a separate command 
> > to copy the settings (all of them) from the current line and
> > then having, as default value for each of the `*ch*' commands,
> > the value taken from that copied setting.  And this would
> > apply across Dired buffers, giving you an easy way to apply a
> > particular set of values (settings).  It could perhaps also
> > apply to other Dired commands, such as `touch' (dunno).
> > 
> > The point is that if we are going to copy settings from a 
> > particular file in order to make them available for,
> > essentially, pasting operations to other files, then the
> > target file being copied from should be clear.  The copy
> > operation should be an explicit user choice, not something 
> > implicit, based only on the first marked file (why not the
> > last? or the 23rd?).

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

You are citing the message that I already replied to.
And it seems we are in full agreement on this issue.

But since this is not a regression, why are you asking to fix it now?

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

> You are citing the message that I already replied to.
> And it seems we are in full agreement on this issue.
> 
> But since this is not a regression, why are you asking to fix it now?

I'm only asking that it be fixed.  I'm not saying it needs to be fixed for 24.1.
I was unable to reopen the bug - AFAICT it is still closed and marked `notabug'.
If there is a plan to fix it, that's great - thx.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> This bug has not at all been fixed - AFAICT, everything I reported is
> still a problem.  It should not have been closed.

Your suggestion in the original post was

>> The best approach is not to provide any default value here.

As Juri noted, if you don't want the suggested value, just don't type
M-n.  Since this command no longer accepts empty input as a permission,
there is nothing else to fix.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Juri Linkov]

>> This bug has not at all been fixed - AFAICT, everything I reported is
>> still a problem.  It should not have been closed.
>
> Your suggestion in the original post was
>
>>> The best approach is not to provide any default value here.
>
> As Juri noted, if you don't want the suggested value, just don't type
> M-n.  Since this command no longer accepts empty input as a permission,
> there is nothing else to fix.

IIUC, the most recent Drew's suggestion was something different,
i.e. what to use as a default value when more than one file is marked.

Since this is a separate wish, then perhaps the best thing for Drew to do
is to create a new wishlist report.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

> IIUC, the most recent Drew's suggestion was something different,
> i.e. what to use as a default value when more than one file is marked.
> 
> Since this is a separate wish, then perhaps the best thing 
> for Drew to do is to create a new wishlist report.

It was not a separate wish.  It was the point of the #9361 report: The default
value is inappropriate when multiple files are marked.

Just saying that a user is not forced to _use_ the default value is simply a
cop-out.  You can close lots of reports as `notabug' by saying the user is not
forced to use some feature that is broken.

Anyway, I submitted a new report, since this one went nowhere: #10624.

bug#9361: 24.0.50; default value of `dired-do-chmod'

[Drew Adams]

> > This bug has not at all been fixed - AFAICT, everything I 
> > reported is still a problem.  It should not have been closed.
> > You apparently fixed your own choice of a problem, which
> > was not the problem that was reported.
> > 
> > The default value of `dired-do-chmod' is still the same,
> > inappropriate value. There is no reason to pick up the
> > permissions from the _first_ of the marked files - makes
> > no sense at all.  And it is still not made clear to users
> > which file the permissions are being copied from.  Please
> > read the bug report, and the followup passage cited below.
> 
> Your suggestion in the original post was
> 
> >> The best approach is not to provide any default value here.

You read what you want to read, apparently.  Which part of the above text about
our currently having an unclear, inappropriate default value did you not
understand?  

Nothing has changed wrt the default value, except the treatment of empty input.

> As Juri noted, if you don't want the suggested value, just don't type
> M-n.  Since this command no longer accepts empty input as a 
> permission, there is nothing else to fix.

See above - there is plenty to fix.  We should either provide no default value
or provide one that makes sense.  That's the bug that was reported.

I made pretty clear what the problem was, even quoting the description more than
once.  Here goes again:

>>> The point is that if we are going to copy settings from a 
>>> particular file in order to make them available for,
>>> essentially, pasting operations to other files, then the
>>> target file being copied from should be clear.  The copy
>>> operation should be an explicit user choice, not something 
>>> implicit, based only on the first marked file (why not the
>>> last? or the 23rd?).


> > Do I need to open a new bug and copy the 9361 report to it,
> > i.e., to start over?

Apparently so.  #10624