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

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'
 

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

[Drew Adams]

Let me include this bit also from bug #9361.  It offers a bit more in the way of
suggestion for the requested enhancement.

> 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#10624: 24.0.92; default value of `dired-do-ch*'

[Juri Linkov]

This request for enhancement is implemented with the following patch
where the user will be able to mark the target file with the mark.
Otherwise, the marked file is used as target only when it is a single file
in the list of marked files:

=== modified file 'lisp/dired-aux.el'
--- lisp/dired-aux.el	2012-09-13 23:42:39 +0000
+++ lisp/dired-aux.el	2012-09-14 23:45:05 +0000
@@ -223,10 +237,16 @@ (defun dired-do-chxxx (attribute-name pr
   ;; OP-SYMBOL is the type of operation (for use in `dired-mark-pop-up').
   ;; ARG describes which files to use, as in `dired-get-marked-files'.
   (let* ((files (dired-get-marked-files t arg))
+	 (default-file (or (if (and transient-mark-mode mark-active)
+			       (save-excursion (goto-char (mark t))
+					       (dired-get-filename t t)))
+			   (if (and (= (length files) 1)
+				    (stringp (car files)))
+			       (car files))))
 	 (default (and (eq op-symbol 'touch)
-		       (stringp (car files))
+		       default-file
 		       (format-time-string "%Y%m%d%H%M.%S"
-					   (nth 5 (file-attributes (car files))))))
+					   (nth 5 (file-attributes default-file)))))
 	 (prompt (concat "Change " attribute-name " of %s to"
 			 (if (eq op-symbol 'touch)
 			     " (default now): "

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

[Drew Adams]

> This request for enhancement is implemented with the following patch
> where the user will be able to mark the target file with the mark.
> Otherwise, the marked file is used as target only when it is 
> a single file in the list of marked files:
> 
> +	 (default-file (or (if (and transient-mark-mode mark-active)
> +			       (save-excursion (goto-char (mark t))
> +					        (dired-get-filename t t)))
> +			   (if (and (= (length files) 1)
> +				    (stringp (car files)))
> +			       (car files))))
>  	 (default (and (eq op-symbol 'touch)
> -		       (stringp (car files))
> +		       default-file
>  		       (format-time-string "%Y%m%d%H%M.%S"
> -					   (nth 5 
> (file-attributes (car files))))))
> +					   (nth 5 

Thanks for working on this, but I'm not crazy about that approach at all, IIUC.
And it does not implement the enhancement requested.

The Emacs mark is not something that is very useful in this context, IMO.  It's
not obvious and visible.  And why use the mark only when transient-mark-mode is
enabled?  That obviates use of the region for something more useful in Dired
(e.g., Dired-marking all files in the region).

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.

That is precisely the behavior that I filed this bug against.  It makes no sense
to use the 1st of the marked files, or the 13th, or any other file except the
current-line file.  That _is_ this bug.

I stand by my alternative suggestions:

1. Do not provide any default value at all.  (Easiest to do, but least
helpful improvement.)

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.).

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,
transferring the appropriate attributes (mod time, various permission fields,
etc.) to the "target" (i.e., marked) files according to the particular command.

For example (for #3), for `dired-do-chmod', the file permissions copied from the
source file would be the default value.  For `dired-do-touch', the mod time of
the source file would be the default value for the operation.  And so on.

See the original bug report for more details.

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.

If you cannot or do not want to do something like #3, please do #1 or something
like #2.  In the latter case (#1 or #2), or if you decide to do something
altogether different from what I suggested, please keep this enhancement request
open.

Thx.

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

[Juri Linkov]

> The Emacs mark is not something that is very useful in this context,
> IMO.  It's not obvious and visible.

It is visible when transient-mark-mode is enabled.

> And why use the mark only when transient-mark-mode is enabled?

Because when transient-mark-mode is enabled, it is possible
to deactivate the mark with C-g.

> That obviates use of the region for something more useful in Dired

It doesn't preclude from using the region in other Dired commands.

> 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)

> 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.

> 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.
But it has one drawback that 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.

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

[Juri Linkov]

> Dired-marking all files in the region

This is a feature that's sorely missing from Dired.
Currently marking a long list of files by pressing `m'
and holding it as long as the cursor eventually arrives
to the last file is too tedious (and the numeric prefix
doesn't help when the exact number of files to mark is not known).

Now with the following patch it's possible to mark a list of files
with normal region selection (and using isearch to speed it up)
and type `m' (or `u' to unmark) just once.

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-09-14 03:55:16 +0000
+++ lisp/dired.el	2012-09-15 22:54:12 +0000
@@ -3102,12 +3120,15 @@ (defun dired-mark (arg)
 and \\[dired-unmark] on a subdir to remove the marks in
 this subdir."
   (interactive "P")
+  (if (and transient-mark-mode mark-active)
+      ;; Mark files in the active region.
+      (dired-mark-files-in-region (region-beginning) (region-end))
   (if (dired-get-subdir)
       (save-excursion (dired-mark-subdir-files))
     (let ((inhibit-read-only t))
       (dired-repeat-over-lines
        (prefix-numeric-value arg)
-       (function (lambda () (delete-char 1) (insert dired-marker-char)))))))
+	 (function (lambda () (delete-char 1) (insert dired-marker-char))))))))
 
 (defun dired-unmark (arg)
   "Unmark the current (or next ARG) files.

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

[Drew Adams]

> > 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.

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

[Drew Adams]

> > Dired-marking all files in the region
> 
> This is a feature that's sorely missing from Dired.

Sorely missing from vanilla Dired, indeed.

But it's been a feature of Dired+ since at least 1999, and probably several
years before that.  And I've offered that and all other features of Dired+ to
Emacs Dev multiple times.  Still sorely missing, though.

1. `S-mouse-1' marks all of the files in the region (no need for it to be
active).

This is like Windows Explorer: click a file, S-click another file, to mark them
both and all between them.  And `C-mouse-1' marks/unmarks the clicked file, also
as in Windows Explorer.

2. `mouse-3' with an active region brings up a menu which includes items `Mark',
`Unmark', `Toggle Marked/Unmarked', and `Flag for Deletion'.

There are of course individual region commands to do each of those things - not
bound to any keys by default.  The mouse is handy enough - drag to select, then
act on the selected files.  Provided you use a mouse. ;-)

Screenshots & info here, if anyone is interested:
http://www.emacswiki.org/cgi-bin/wiki/DiredPlus


> Currently marking a long list of files by pressing `m'
> and holding it as long as the cursor eventually arrives
> to the last file is too tedious (and the numeric prefix
> doesn't help when the exact number of files to mark is not known).
> 
> Now with the following patch it's possible to mark a list of files
> with normal region selection (and using isearch to speed it up)
> and type `m' (or `u' to unmark) just once.

Now it's possible, indeed.  1999.

bug#10624: Dired-marking all files in the region

[Juri Linkov]

>>> Dired-marking all files in the region
>>
>> This is a feature that's sorely missing from Dired.
>
> But it's been a feature of Dired+ since at least 1999, and probably several
> years before that.  And I've offered that and all other features of Dired+ to
> Emacs Dev multiple times.  Still sorely missing, though.

The size of Dired+ is overwhelming, let's add its features to Dired
one at a time ;-)

Below is a complete tested patch for the region-marking feature:

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-09-14 03:55:16 +0000
+++ lisp/dired.el	2012-09-16 23:41:24 +0000
@@ -3097,21 +3115,37 @@ (defun dired-mark-files-in-region (start
 (defun dired-mark (arg)
   "Mark the current (or next ARG) files.
 If on a subdir headerline, mark all its files except `.' and `..'.
+If the region is active in Transient Mark mode, mark all files
+in the active region.
 
 Use \\[dired-unmark-all-files] to remove all marks
 and \\[dired-unmark] on a subdir to remove the marks in
 this subdir."
   (interactive "P")
-  (if (dired-get-subdir)
-      (save-excursion (dired-mark-subdir-files))
+  (cond
+   ;; Mark files in the active region.
+   ((and transient-mark-mode mark-active)
+    (save-excursion
+      (let ((beg (region-beginning))
+	    (end (region-end)))
+	(dired-mark-files-in-region
+	 (progn (goto-char beg) (line-beginning-position))
+	 (progn (goto-char end) (line-beginning-position))))))
+   ;; Mark subdir files from the subdir headerline.
+   ((dired-get-subdir)
+    (save-excursion (dired-mark-subdir-files)))
+   ;; Mark the current (or next ARG) files.
+   (t
     (let ((inhibit-read-only t))
       (dired-repeat-over-lines
        (prefix-numeric-value arg)
-       (function (lambda () (delete-char 1) (insert dired-marker-char)))))))
+       (function (lambda () (delete-char 1) (insert dired-marker-char))))))))
 
 (defun dired-unmark (arg)
   "Unmark the current (or next ARG) files.
-If looking at a subdir, unmark all its files except `.' and `..'."
+If looking at a subdir, unmark all its files except `.' and `..'.
+If the region is active in Transient Mark mode, unmark all files
+in the active region."
   (interactive "P")
   (let ((dired-marker-char ?\040))
     (dired-mark arg)))
@@ -3119,8 +3153,9 @@ (defun dired-unmark (arg)
 (defun dired-flag-file-deletion (arg)
   "In Dired, flag the current line's file for deletion.
 With prefix arg, repeat over several lines.
-
-If on a subdir headerline, mark all its files except `.' and `..'."
+If on a subdir headerline, flag all its files except `.' and `..'.
+If the region is active in Transient Mark mode, flag all files
+in the active region."
   (interactive "P")
   (let ((dired-marker-char dired-del-marker))
     (dired-mark arg)))
@@ -3128,7 +3163,9 @@ (defun dired-flag-file-deletion (arg)
 (defun dired-unmark-backward (arg)
   "In Dired, move up lines and remove marks or deletion flags there.
 Optional prefix ARG says how many lines to unmark/unflag; default
-is one line."
+is one line.
+If the region is active in Transient Mark mode, unmark all files
+in the active region."
   (interactive "p")
   (dired-unmark (- arg)))
 

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

[Juri Linkov]

> `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.

Oh no, a whole prefix map for such an auxiliary feature.

But I like the simplicity of your suggestion #2 - use the attributes of the
file on the current line.  It's implemented in a small patch below:

=== modified file 'lisp/dired-aux.el'
--- lisp/dired-aux.el	2012-09-13 23:42:39 +0000
+++ lisp/dired-aux.el	2012-09-16 23:47:32 +0000
@@ -223,10 +247,17 @@ (defun dired-do-chxxx (attribute-name pr
   ;; OP-SYMBOL is the type of operation (for use in `dired-mark-pop-up').
   ;; ARG describes which files to use, as in `dired-get-marked-files'.
   (let* ((files (dired-get-marked-files t arg))
-	 (default (and (eq op-symbol 'touch)
-		       (stringp (car files))
-		       (format-time-string "%Y%m%d%H%M.%S"
-					   (nth 5 (file-attributes (car files))))))
+	 ;; The source of default file attributes is the file at point.
+	 (default-file (dired-get-filename t))
+	 (default (when default-file
+		    (cond ((eq op-symbol 'touch)
+			   (format-time-string
+			    "%Y%m%d%H%M.%S"
+			    (nth 5 (file-attributes default-file))))
+			  ((eq op-symbol 'chown)
+			   (nth 2 (file-attributes default-file 'string)))
+			  ((eq op-symbol 'chgrp)
+			   (nth 3 (file-attributes default-file 'string))))))
 	 (prompt (concat "Change " attribute-name " of %s to"
 			 (if (eq op-symbol 'touch)
 			     " (default now): "
@@ -263,11 +294,15 @@ (defun dired-do-chxxx (attribute-name pr
 ;;;###autoload
 (defun dired-do-chmod (&optional arg)
   "Change the mode of the marked (or next ARG) files.
-Symbolic modes like `g+w' are allowed."
+Symbolic modes like `g+w' are allowed.
+Type M-n to pull the file attributes of the file at point
+into the minibuffer."
   (interactive "P")
   (let* ((files (dired-get-marked-files t arg))
-	 (modestr (and (stringp (car files))
-		       (nth 8 (file-attributes (car files)))))
+	 ;; The source of default file attributes is the file at point.
+	 (default-file (dired-get-filename t))
+	 (modestr (when default-file
+		    (nth 8 (file-attributes default-file))))
 	 (default
 	   (and (stringp modestr)
 		(string-match "^.\\(...\\)\\(...\\)\\(...\\)$" modestr)
@@ -297,7 +335,9 @@ (defun dired-do-chmod (&optional arg)
 
 ;;;###autoload
 (defun dired-do-chgrp (&optional arg)
-  "Change the group of the marked (or next ARG) files."
+  "Change the group of the marked (or next ARG) files.
+Type M-n to pull the file attributes of the file at point
+into the minibuffer."
   (interactive "P")
   (if (memq system-type '(ms-dos windows-nt))
       (error "chgrp not supported on this system"))
@@ -305,7 +345,9 @@ (defun dired-do-chgrp (&optional arg)
 
 ;;;###autoload
 (defun dired-do-chown (&optional arg)
-  "Change the owner of the marked (or next ARG) files."
+  "Change the owner of the marked (or next ARG) files.
+Type M-n to pull the file attributes of the file at point
+into the minibuffer."
   (interactive "P")
   (if (memq system-type '(ms-dos windows-nt))
       (error "chown not supported on this system"))
@@ -314,7 +356,9 @@ (defun dired-do-chown (&optional arg)
 ;;;###autoload
 (defun dired-do-touch (&optional arg)
   "Change the timestamp of the marked (or next ARG) files.
-This calls touch."
+This calls touch.
+Type M-n to pull the file attributes of the file at point
+into the minibuffer."
   (interactive "P")
   (dired-do-chxxx "Timestamp" dired-touch-program 'touch arg))
 

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

[Drew Adams]

> > `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.
> 
> Oh no, a whole prefix map for such an auxiliary feature.

Actually, there is a lot more on prefix key `T'.  But that prefix key pertains
only if you load Bookmark+.  All keys on `T' have to do with tagged files, where
tagging is understood in the Delicious sense.

The point of mentioning it in this thread was to show the use of a key to copy
stuff from one file to subsequently use over and over for pasting (by another
key) to other files.

Dired Mode Bindings Starting With T:
key             binding
---             -------

T C-y           diredp-paste-add-tags-this-file
T ESC           Prefix Command
T +             diredp-tag-this-file
T -             diredp-untag-this-file
T 0             diredp-remove-all-tags-this-file
T >             Prefix Command
T c             diredp-copy-tags-this-file
T m             Prefix Command
T p             diredp-paste-add-tags-this-file
T q             diredp-paste-replace-tags-this-file
T u             Prefix Command
T v             diredp-set-tag-value-this-file
T <backtab>     icicle-complete-keys

T u %           diredp-unmark-files-tagged-regexp
T u *           diredp-unmark-files-tagged-all
T u +           diredp-unmark-files-tagged-some
T u ~           Prefix Command
T u <backtab>   icicle-complete-keys

T m %           diredp-mark-files-tagged-regexp
T m *           diredp-mark-files-tagged-all
T m +           diredp-mark-files-tagged-some
T m ~           Prefix Command
T m <backtab>   icicle-complete-keys

T > C-y         diredp-do-paste-add-tags
T > +           diredp-do-tag
T > -           diredp-do-untag
T > 0           diredp-do-remove-all-tags
T > p           diredp-do-paste-add-tags
T > q           diredp-do-paste-replace-tags
T > v           diredp-do-set-tag-value
T > <backtab>   icicle-complete-keys

T M-w           diredp-copy-tags-this-file
T ESC <backtab>                 icicle-complete-keys

T u ~ *         diredp-unmark-files-tagged-not-all
T u ~ +         diredp-unmark-files-tagged-none
T u ~ <backtab>                 icicle-complete-keys

T m ~ *         diredp-mark-files-tagged-not-all
T m ~ +         diredp-mark-files-tagged-none
T m ~ <backtab>                 icicle-complete-keys

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

[Juri Linkov]

Installed and closed.  Thanks for the suggestion.

bug#10624: Dired-marking all files in the region

[Juri Linkov]

While testing changes for WDired, I noticed one potential problem
with marking all files in the region in the Dired buffer:
when the region is active before typing `C-c C-c' in WDired
it marks renamed files with the same marker, because currently
WDired uses `dired-add-entry' that calls `dired-mark'.

This is a rare problem, but I'd like to fix it properly.
IIUC, the right way to enable functionality only for interactive use
is to add an `interactive' arg (there were some reasons not to use
(called-interactively-p 'interactive) but I forgot the exact reasons).

This is not a regression, so I'm not sure about installing it
to the emacs-24 branch:

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-11-17 21:52:12 +0000
+++ lisp/dired.el	2012-11-22 09:49:38 +0000
@@ -3109,7 +3109,7 @@ (defun dired-mark-files-in-region (start
 	    (insert dired-marker-char)))
       (forward-line 1))))
 
-(defun dired-mark (arg)
+(defun dired-mark (arg &optional interactive)
   "Mark the file at point in the Dired buffer.
 If the region is active, mark all files in the region.
 Otherwise, with a prefix arg, mark files on the next ARG lines.
@@ -3119,10 +3119,10 @@ (defun dired-mark (arg)
 Use \\[dired-unmark-all-files] to remove all marks
 and \\[dired-unmark] on a subdir to remove the marks in
 this subdir."
-  (interactive "P")
+  (interactive (list current-prefix-arg t))
   (cond
    ;; Mark files in the active region.
-   ((and transient-mark-mode mark-active)
+   ((and interactive (use-region-p))
     (save-excursion
       (let ((beg (region-beginning))
 	    (end (region-end)))
@@ -3139,7 +3139,7 @@ (defun dired-mark (arg)
        (prefix-numeric-value arg)
        (function (lambda () (delete-char 1) (insert dired-marker-char))))))))
 
-(defun dired-unmark (arg)
+(defun dired-unmark (arg &optional interactive)
   "Unmark the file at point in the Dired buffer.
 If the region is active, unmark all files in the region.
 Otherwise, with a prefix arg, unmark files on the next ARG lines.
@@ -3147,11 +3147,11 @@ (defun dired-unmark (arg)
 If looking at a subdir, unmark all its files except `.' and `..'.
 If the region is active in Transient Mark mode, unmark all files
 in the active region."
-  (interactive "P")
+  (interactive (list current-prefix-arg t))
   (let ((dired-marker-char ?\040))
-    (dired-mark arg)))
+    (dired-mark arg interactive)))
 
-(defun dired-flag-file-deletion (arg)
+(defun dired-flag-file-deletion (arg &optional interactive)
   "In Dired, flag the current line's file for deletion.
 If the region is active, flag all files in the region.
 Otherwise, with a prefix arg, flag files on the next ARG lines.
@@ -3159,9 +3159,9 @@ (defun dired-flag-file-deletion (arg)
 If on a subdir headerline, flag all its files except `.' and `..'.
 If the region is active in Transient Mark mode, flag all files
 in the active region."
-  (interactive "P")
+  (interactive (list current-prefix-arg t))
   (let ((dired-marker-char dired-del-marker))
-    (dired-mark arg)))
+    (dired-mark arg interactive)))
 
 (defun dired-unmark-backward (arg)
   "In Dired, move up lines and remove marks or deletion flags there.

bug#10624: Dired-marking all files in the region

[Drew Adams]

> I noticed one potential problem
> with marking all files in the region in the Dired buffer:
> when the region is active before typing `C-c C-c' in WDired
> it marks renamed files with the same marker, because currently
> WDired uses `dired-add-entry' that calls `dired-mark'.
> 
> This is a rare problem, but I'd like to fix it properly.
> IIUC, the right way to enable functionality only for interactive use
> is to add an `interactive' arg

Just a quick reply - please excuse if my quick reading of this makes my reply
off-the-mark (so to speak).

What if some other function (perhaps a command) that someone has written takes
advantage of the intended active-region behavior (by activating the region, and
then...)?

With your change, IIUC, that code would now need to be changed to add an
additional argument to the call, to fake interactiveness.

I don't see the problem you cite as having to do with interactiveness, but as
having to do with WDired (or perhaps interactiveness when in WDired).  (But
again, I might be misunderstanding.)

If the problem you refer to is really that _in WDired_ the active region should
be handled this way only if interactive, then shouldn't you add an additional
condition that tests for WDired mode?

IOW, why change the behavior for Dired generally (i.e., including outside WDired
mode), for a problem that you found only inside WDired?

Again, excuse me if I've misunderstood the intention, behavior, or patch.  I
looked at your message quickly.  Thx.

bug#10624: Dired-marking all files in the region

[Stefan Monnier]

> is to add an `interactive' arg (there were some reasons not to use
> (called-interactively-p 'interactive) but I forgot the exact reasons).

One of the main reasons is reliability.  If you look at the code of
called-interactively-p, you'll see it's pretty hackish, so it's easy to
break it.  For example `called-interactively-p' may fail to work correctly
in the following known cases:
- when the function is advised (this was recently improved, so it will
  now fail sometimes rather than always).
- when inside a condition-case or catch in lexical-binding code.
- when inside a `pcase' branch (because pcase sometimes moves the
  branch to a lambda in order to avoid duplicating the code).

Another reason is that it makes it more flexible for non-interactive
callers, which can control whether to run the function "as if the
arguments had been provided interactively".

`called-interactively-p' is handy when you can't add an argument, but
otherwise it's much better to add an `interactive' argument.


        Stefan

bug#10624: Dired-marking all files in the region

[Juri Linkov]

> IOW, why change the behavior for Dired generally (i.e., including outside WDired
> mode), for a problem that you found only inside WDired?

This problem is not WDired specific.  It is better to opt-in this functionality
by setting the `interactive' arg than to opt-out it in specific packages
because this feature makes sense only for interactive use in Dired.

bug#10624: Dired-marking all files in the region

[Juri Linkov]

> `called-interactively-p' is handy when you can't add an argument, but
> otherwise it's much better to add an `interactive' argument.

I added an `interactive' argument to the emacs-24 branch
since its lack might cause regressions in external packages.

bug#10624: Dired-marking all files in the region

[Drew Adams]

> > IOW, why change the behavior for Dired generally (i.e., 
> > including outside WDired mode), for a problem that you
> > found only inside WDired?
> 
> This problem is not WDired specific.

I have not seen a description of "this" problem, other than a description of a
problem for WDired.  Can you characterize "this problem" for Dired generally?

This is the only description I've seen, and it seems quite WDired-specific:

>> when the region is active before typing `C-c C-c'
>> in WDired it marks renamed files with the same marker,
   ^^^^^^^^^
>> because currently WDired uses `dired-add-entry'
           ^^^^^^^^^^^^^^^^
>> that calls `dired-mark'.

How is "this problem" manifested for Dired, other than for WDired?

And I don't understand this:

> It is better to opt-in this functionality by setting the
> `interactive' arg than to opt-out it in specific packages
> because this feature makes sense only for interactive use in Dired.

What is the argument as to why this makes sense only for interactive use in
Dired?  Or that it makes sense always for interactive use in Dired?

Sorry, but this is not yet clear to me.  Seems like maybe some steps are missing
from your argument.  They are no doubt obvious to you, but not yet to me.  Could
you please fill in the blanks a bit?  Again, excuse me for not grasping this
quickly.

bug#10624: Dired-marking all files in the region

[Juri Linkov]

> What is the argument as to why this makes sense only for interactive use in
> Dired?  Or that it makes sense always for interactive use in Dired?

Sorry, I don't understand whether your questions are rhetorical.
If you disagree with this change, please provide counterexamples
that support your point.

bug#10624: Dired-marking all files in the region

[Drew Adams]

> > What is the argument as to why this makes sense only for 
> > interactive use in Dired?  Or that it makes sense always for
> > interactive use in Dired?
> 
> Sorry, I don't understand whether your questions are rhetorical.

Not rhetorical at all.

> If you disagree with this change, please provide counterexamples
> that support your point.

It's not a question of disagreement at this point, but of trying to understand.

Please answer the questions.  Why only interactive?  Why always when
interactive?  What is the rationale for this design?

bug#10624: Dired-marking all files in the region

[Juri Linkov]

> Why only interactive?  Why always when interactive?

Because it fixed the problem that I described earlier.
I cannot think of a better fix.

bug#10624: Dired-marking all files in the region

[Drew Adams]

> > Why only interactive?  Why always when interactive?
> 
> Because it fixed the problem that I described earlier.
> I cannot think of a better fix.

Why is interactiveness as the exact condition important for your fix?  How is it
related to the problem you wanted to solve?

You are not helping understanding of the fix/design.
You are just saying that's what you did and it fixes the problem.