bug#30285: dired-do-chmod vs. top line of dired

[Drew Adams]

> > Yes, it makes sense for such commands to do nothing or to show an
> > error message when on the "top line of dired", as described in the
> > bug report.
> 
> Instead of doing nothing or showing an error message, how about
> doing a more useful thing: when on the top line, ‘dired-do-chmod’
> could do chmod on all files in the dir.

Not a good idea, IMO.  Too easy to do accidentally.  At the
very least it would need to ask for confirmation specially.

`m', `d', and `w', which are the keys that you are talking
about, to not do anything to the files in question.  They
affect only the Dired listing or the `kill-ring'.  That's
quite different from something like `chmod'.

And in any case, such shortcut behavior is not needed at all
(see next).

> This is exactly what other Dired commands already do: e.g. typing ‘m’
> on the top line or on any other subdir headerline, they perform
> their actions on all files.

Which is why what you propose isn't needed.  Just `m' then `M'.

If someone is going to act on lots of files, s?he had better
be aware of that.  Best is that they are first marked before
acting on them.

But yes, it's true that not needing to change marks can be
handy.  I.e., you have some files marked for a given reason
already, and you want to keep those markings.  (You could
use `* c' to temporarily change marks, but that's a bit
roundabout.)

That handiness (not losing existing markings) is the reason
why in my Dired+ code, for commands that normally act on the
marked files (or the N next files, with numeric prefix arg N),
you can use multiple plain `C-u' to act on all files, ignoring
markings:

Just what "all" files means changes with the number of `C-u',
as follows:

 `C-u C-u'         - Use all files present, but no directories.
 `C-u C-u C-u'     - Use all files and dirs except `.' and `..'.
 `C-u C-u C-u C-u' - use all files and dirs, `.' and `..'.

 (More than four `C-u' act the same as two.)

But I don't think that's a good idea in the current context.
I'd suggest that we just let someone use `m' (on that
non-file line) followed by `M' etc.

I think that this bug should be handled by doing what Dired
usually does when point is on a non-file line (_anywhere_,
not just on a directory header line or its "total..." line) -
as I said earlier: just raise a `user-error'.

You'll note too that `m' on a non-file line other than
the dir header line does _not_ do what you describe.

* On the "total..." line it marks the first file line
  (which is now `..' in Windows but used to be `.').

* On the blank line before an inserted subdir header it
  does the same thing: it marks the first file line of
  that subdir listing.

* On any other non-file line, such as the blank line at
  the end of the buffer, it does nothing at all.

So the `m' (`dired-mark') behavior is quite variable, even
if it can be useful.

Note too that the other two commands that act specially on
a (sub)dir header line do not do the same thing as `dired-mark'.

* `dired-copy-filename-as-kill' does not act similarly at all.
  It copies the subdir name instead of names of any files in
  its listing.

* `dired-flag-file-deletion' does act somewhat similarly to
  `dired-mark': it flags all of the files (other than `.' and
  `..') in the subdir listing - except if the region is active.
  In the latter case it flags the files in the region.  And that
  need not mean any files in the subdir listing - it could be
  just files in the previous listing.  Or it could be files in
  the subdir listing plus files in other, subsequent subdir
  listings.

> For example, see the docstring of ‘dired-mark’:
>   “If on a subdir headerline, mark all its files except `.'
>    and `..'.”
> 
> > No, we don't need a function `dired-marked-files-or-file-at-point-p',
> > for that or anything else.  The `dired-do-*' commands already DTRT
> > wrt the marked-files-or-file-at-point.
> 
> I agree that it's better to check the ‘files’ returned from
> ‘dired-get-marked-files’.