all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: 30285@debbugs.gnu.org, Tino Calancha <tino.calancha@gmail.com>,
	jidanni@jidanni.org
Subject: bug#30285: dired-do-chmod vs. top line of dired
Date: Wed, 31 Jan 2018 15:20:22 -0800 (PST)	[thread overview]
Message-ID: <5dd33d7a-b418-4c60-9891-ec2e21f21fe1@default> (raw)
In-Reply-To: <87fu6lwxxu.fsf@mail.linkov.net>

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





  reply	other threads:[~2018-01-31 23:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29 12:32 bug#30285: dired-do-chmod vs. top line of dired 積丹尼 Dan Jacobson
2018-01-29 15:14 ` Tino Calancha
2018-01-29 16:05   ` Eli Zaretskii
2018-01-29 23:21     ` Tino Calancha
2018-01-29 23:42       ` Drew Adams
2018-01-30  3:53         ` Tino Calancha
2018-01-30  4:43           ` Drew Adams
2018-01-30 15:15             ` Drew Adams
2018-01-31  9:49               ` Tino Calancha
2018-01-31 19:04                 ` Drew Adams
2018-01-31 21:35         ` Juri Linkov
2018-01-31 23:20           ` Drew Adams [this message]
2018-02-01  8:16           ` Tino Calancha
2018-02-01  9:17             ` Tino Calancha
2018-02-01 16:10             ` Drew Adams
2018-02-04 23:12               ` Tino Calancha
2018-02-05 16:45                 ` Drew Adams
2018-02-01 20:07             ` Juri Linkov
2018-02-01 20:50               ` Drew Adams
2018-02-01 21:35                 ` Juri Linkov
2018-02-01 22:23                   ` Drew Adams
2018-02-03 22:23                     ` Juri Linkov
2018-02-04 10:02                       ` martin rudalics
2018-02-04 21:44                         ` Juri Linkov
2018-02-06 21:32                         ` Juri Linkov
2018-02-04 23:08                   ` Tino Calancha
2018-02-05 21:01                     ` Juri Linkov
2018-02-05 21:52                       ` Drew Adams
2018-01-29 15:24 ` 積丹尼 Dan Jacobson
2018-01-29 23:14   ` Tino Calancha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5dd33d7a-b418-4c60-9891-ec2e21f21fe1@default \
    --to=drew.adams@oracle.com \
    --cc=30285@debbugs.gnu.org \
    --cc=jidanni@jidanni.org \
    --cc=juri@linkov.net \
    --cc=tino.calancha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.