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

From: "Drew Adams" <[email-masked]>
Date: Sat, 15 Sep 2012 21:47:00 -0700

> > What's more, if I read your code correctly, when there is no active
> > mark you are still picking up the first of the marked files 
> > and using its data as the default.
> 
> No, you read code incorrectly.  You could pay more attention to the
> line with (= (length files) 1)

I meant when there are multiple marked files.  When there is only one, if it is
not explicitly marked in any way but just the current-line file then that is
even less interesting (since it is also the target of the action).

Using the current line file as the source of the default attributes is something
I suggested, but only when there are other, explicitly marked files.

> > 2. Minimal, easy to do now: Use the attributes of the file 
> > on the current line, providing them as the default for the
> > marked files according to the particular command (mod time,
> > various permission fields, etc.).
> 
> This makes sense, but it might be too confusing.  For instance,
> in the following scenario: type `m' to select a file, after that
> point moves to the next line with an arbitrary unselected file
> whose attributes will be used as the default value.  This would be
> unexpected.

Not if it is expected. ;-)

Clearly, the default must come from somewhere (or else take my other, simplest
suggestion and get rid of any default).

And unless you adopt something like my main suggestion, which lets the user
explicitly set the default (and save that until the next setting action), the
current-line file makes the most sense, to me.

At least I haven't seen a better suggestion.  Clearly (to me anyway), just
picking the first of the explicitly marked files, as we have been doing, is
downright silly.

We should provide some predictable way for the user to choose which file to use
as the source of the default values.

> > 3. More complex, but more useful: Let the user hit a key to 
> > "copy" the attributes of a given file (on the current line -
> > the "source" file), as if to a clipboard.  Then use those
> > attributes for subsequent "paste" operations,
> 
> I suppose a key to copy the attributes to use as the default value
> would be like `w' (`dired-copy-filename-as-kill').  It is 
> worth thinking about.

I have used that approach in my use of delicious-style tags for files, for quite
some time now:

`T c' or `T M-w' copies the tags from the current-line file.

`T p' or `T C-y' pastes those tags to another current-line file,
adding them to any existing tags for that file.

`T q' pastes similarly, but replaces any existing tags for the target file.

`T > p' (`T > C-y') and `T > q' do the same pasting thing, but for the marked
files.

> But it has one drawback that is not too obvious.

Which is what?  Or should we guess, because it is not too obvious?

> > The point is to (a) have a reasonable source-file choice 
> > from which attributes are taken for the default and
> > (b) push those attributes to the marked files as
> > defaults for an operation, in a operation-pertinent way.
> 
> Using the mark in transient-mark-mode is a reasonable 
> source-file choice from which attributes are taken for the
> default, and could be added among other possible methods.

Well, we can agree to disagree about your choice.  But I agree that it _is_ one
way to let users predictably choose which file to pull the defaults from.

You are doing the same thing I suggest, but your key choice is `C-SPC', making
that key do double duty.  And distracting the user with the (irrelevant) region
display, to boot.  This has nothing to do with the region.

And if a user sets the mark for some other reason (uh, for the region, for
example) then - whoop! - the copy defaults are changed again at the same time.

It is far better to separate the keys for these two totally unrelated purposes:
(1) setting the region and making it active, and (2) copying attributes from the
current-line file to use as defaults for subsequent operations.

We and the user gain nothing by coupling those two meanings/uses of `C-SPC'.
(Well, perhaps we save a key binding.)  And the user loses the possibility of
setting and activating the region without also copying defaults (and vice
versa).

Just bind a new key for such copying - that's still my suggestion.