GNU bug report logs - #42578
28.0.50; [suggestion] allow dired-do-shell-command on directory line

Previous Next

Full log

View this message in rfc822 format

From: Arthur Miller <arthur.miller <at> live.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 42578 <at> debbugs.gnu.org, Marco Wahl <marcowahlsoft <at> gmail.com>
Subject: bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line
Date: Wed, 29 Jul 2020 20:02:59 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> All that you suggest is fine to suggest, IMO.
> I didn't mean to discourage such suggestion.
>
> It's true that a dir heading has few associated
> actions, by default.  (Movement among such headings
> is about the only such action, I think, by default.)
>
> It's also true that to act on a dir/subdir you
> generally need to be on its `.' line.  Or else (for
> some other commands) it doesn't matter where, within
> its listing, you are.
>
> I personally don't have a problem with the default
> behavior of `M-<' or `C-<home' moving to the
> beginning of the buffer (as in other buffers).  But
> if you think a better default behavior would be to
> move to its `.' line, then suggest that.  (Vanilla
> Emacs also doesn't allow most actions on `.', but
> that's a different problem/story.)
>
> In that case, you'd probably want dir navigation
> keys (`C-M-n' etc.) to also move to the `.' line
> of a dir listing, and not to the heading line.
>
> In a way, a dir heading line and its `.' line
> both represent the same thing.  One shows the dir
> name (absolute), and the other shows the attributes
> (permissions, date, size etc.).
>
> I also agree that there's room for further enhancing
> Dired.  In particular, some of the commands that act
> by default relative to the top-most directory listed
> (e.g. `find-name-dired') could instead act by default
> on the subdir of the listing where point is.
>
> E.g., `M-x find-name-dired' could use, as default,
> the subdir of the current listing (wrt point).
>
> Whether such a change would be for the better, I
> don't know.  But it's possible, and maybe worth
> thinking about.  One thing you might do is code such
> changes for your own use (e.g. a mini-library), and
> try it for a while.
>
> So far, dir headings are just that: they serve only
> to identify a particular listing within the buffer,
> and they serve as movement destinations, when moving
> among such listings.
>
> (Dired+, unlike vanilla Emacs, allows some actions
> on `.' and `..'.  But it too doesn't bother to do
> so on a heading line.  IOW, it doesn't treat a
> heading line the same as the `.' line.)

I can't tell much about . and .. in a dired buffer since I hide those
per default in my setup. So I have just heading and list of file names
following below. Maybe it is usefull to do some actions on ., .. and
heading, but I don't seem to miss that functionality. I use Dired just
like standard file manager to rename, cut, copy, move, and open files,
and in that context I have never had use of header (or . and ..).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.