From: Drew Adams <drew.adams@oracle.com>
To: Tino Calancha <tino.calancha@gmail.com>
Cc: 30285@debbugs.gnu.org, jidanni@jidanni.org
Subject: bug#30285: dired-do-chmod vs. top line of dired
Date: Mon, 29 Jan 2018 20:43:06 -0800 (PST) [thread overview]
Message-ID: <1dd0ec16-7f13-4753-beef-0daeaf84ed8d@default> (raw)
In-Reply-To: <alpine.DEB.2.20.1801301240040.29669@calancha-pc>
> > The `dired-do-*' commands already DTRT wrt the marked-files-or-file-
> > at-point.
>
> No, they don't. They annoying users asking a useless prompt, like:
>
> Change mode of * [0 files] to:
> ;; Just to notify the user after his input:
> No file on this line
I see that only for the reported places (this bug).
Dunno if that's what you meant.
Otherwise I don't see that at all. With point on a file
or dir line (even on `.' or `..') and no files marked I
get this prompt, where THE-FILE-OR-DIR is the name of
the file or directory:
Change mode of `THE-FILE-OR-DIR' to:
IOW, except for the bug case it works fine, and there
is no function `dired-marked-files-or-file-at-point-p'.
Likewise, for other `dired-do-*' commands.
The marked-files-or-file-at-point behavior is done by
`dired-get-marked-files'. That's exactly what it does.
(defun dired-do-chmod (&optional arg)
"..."
(interactive "P")
(let* ((files (dired-get-marked-files t arg)) ; <======
...))
All that's needed is to test for FILES = nil.
> This bug report is just about the unnecessary prompt in the top line.
OK. We agree that the bug is only about the top line (or
top two lines, if details are not hidden).
Well, not really. It's really about point on any line where
there is no file or dir. That includes:
1. The empty line at the end of the buffer.
2. The empty line before each inserted subdir listing.
3. The first two lines of the main dir and of each inserted
subdir - that is, the highlighted line with the full
(sub)dir name and the "total..." information line that
follows it.
The right thing to do is to test first for whether point
is on a file or dir line. There are several ways to do
that.
One is shown above: (dired-get-marked-files t arg), and
that's already used by commands such as `dired-do-chmod'.
We just need to test its return value.
Another is to use (dired-move-to-filename). One of the
main uses of that simple function is to test whether or
not point is on a file or dir line.
A third way, more costly, is to use `dired-get-filename',
Some of these ways give you a choice of whether to raise
an error or just return nil when point is not on a file
or dir line, i.e., when we are in one of the cases where
we don't want to try to act on the indicated file(s),
because there are none.
For `dired-do-chmod' and similar, I'd say just test the
return value of `dired-get-marked-files' which is already
called at the beginning of the function. If, in some
other `dired-do-*' command that function is not called at
the beginning anyway, just use `dired-move-to-filename':
(defun dired-do-whatever (&optional arg)
"..."
(interactive (progn (dired-move-to-filename 'RAISE-ERROR)
(list current-prefix-arg))))
...)
next prev parent reply other threads:[~2018-01-30 4:43 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1dd0ec16-7f13-4753-beef-0daeaf84ed8d@default \
--to=drew.adams@oracle.com \
--cc=30285@debbugs.gnu.org \
--cc=jidanni@jidanni.org \
--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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).