bug#10624: 24.0.92; default value of `dired-do-ch*'

[Drew Adams]

When multiple files are marked, the default value for `dired-do-chmod'
is taken from the permissions of the first of the marked files.
 
a. This is not helpful - why the first marked and not the last or the
23rd?
 
b. This is not clear - we don't let the user know which file the default
permissions correspond to.  (Not even any doc.)
 
An *immediate* fix would be one of these alternative approaches:
 
1. Do not provide any default value at all.  (Easiest to do, but least
helpful improvement.)
 
2. Use the permissions of the current file (cursor location) as default,
instead of the first marked file.  And document this.  This lets users
easily control which permissions are copied.
 
I prefer #2, but #1 is at least better than the current situation.
 

This bug report is a followup to bug #9361, which was diverted and never
addressed.  Here is the point (quoted from #9361, where it was ignored):
 
> 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?).
 

But again, #1 and #2 are only immediate, remedial, partial fixes.  They
are not the best approach.  A better fix is to do the following (and
yes, this IS part of this report, as an enhancement request):
 
3. Create a separate command to copy the settings (including the
permissions) from a particular file that the user can choose - e.g., the
current (cursor line) file.
 
4. Use those copied settings as the basis for the default values of
_all_ of the Dired `ch*' commands (`dired-do-chmod', `dired-do-chgrp',
etc.).  For each such command, use only the relevant part of the copied
data.
 
A single key would copy all of the displayed field info.  Only the
appropriate parts of that copied info would be used for the different
default values of the various application/modifying commands.
 
5. In the case where there is no such previous copy, use the approach of
#2 above as a fallback default - but, again, use it differently for each
`ch*' command: use only the appropriate info (field) from the current
(cursor line) file as the default value.
 
And of course state in the doc string for each such command where the
default value comes from.  IOW, let users know how they can control what
default value is made available.
 
Such a *generalized copy/paste feature* for Dired would be quite useful.
You could easily modify any set of files or directories according to any
of the displayed Dired/`ls' fields.
 
Even the file/dir name could be copied this way for reuse by editing
when renaming another file/dir.

(When there are multiple marked files to be renamed, the copied name
could perhaps be incremented with a seed string in some way (which
must be made clear to users).  E.g., if the copied file name is `foo'
and the (prompted for seed) is "-1000" then the renamed files could
be `foo-1000', `foo-1001', etc.  There are various possibities here.
I mention this part only as food for thought, for now.)
 
In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2012-01-22 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include --ldflags
 -LD:/devel/emacs/libs/gnutls-3.0.9/lib'