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