[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directo
From: |
Arthur Miller |
Subject: |
bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line |
Date: |
Wed, 29 Jul 2020 20:02:59 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Drew Adams <drew.adams@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 ..).
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, (continued)
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Marco Wahl, 2020/07/29
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Michael Albinus, 2020/07/29
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Marco Wahl, 2020/07/29
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Michael Albinus, 2020/07/29
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Marco Wahl, 2020/07/30
- bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, Marco Wahl, 2020/07/31
bug#42578: 28.0.50; [suggestion] allow dired-do-shell-command on directory line, arthur miller, 2020/07/28