GNU bug report logs -
#21746
24.5; purpose of dired-keep-marker-copy?
Previous Next
Reported by: "Roland Winkler" <winkler <at> gnu.org>
Date: Fri, 23 Oct 2015 19:45:02 UTC
Severity: wishlist
Found in version 24.5
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21746 in the body.
You can then email your comments to 21746 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Fri, 23 Oct 2015 19:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Roland Winkler" <winkler <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 23 Oct 2015 19:45:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
While I have used emacs for many years, I have never figured out a
reason why copying a file in dired gives the copied file a marker
`C'. So today I wanted to find out, but I failed: the docstring of
dired-do-copy does not explain it, dired-keep-marker-copy does not
explain it, and in the emacs info manual I could not find anything
useful either. What is the purpose of this feature? It appears to
me that it is a feature for experts which is at best distracting for
ordinary users. I suggest: either explain it somewhere that is not
too hard to find or give dired-keep-marker-copy a default value of
nil (and similar for dired-keep-marker-hardlink,
dired-keep-marker-symlink).
In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
of 2015-05-27 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.11600000
System Description: Ubuntu 14.04.3 LTS
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Fri, 23 Oct 2015 20:31:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> I have never figured out a
> reason why copying a file in dired gives the copied file a marker
> `C'.
The reason (IMO) is that the marker indicates what the
operation was, so you can easily identify - *and then
operate on* the files that were copied (or whatever
the operation was).
What might be missing for you is this bit of info:
`* c' lets you change the char that is used for a given
mark. So you can, for example, change all `C' marks at
a given moment to, say, `*' marks, and then use any
action on the marked files (which acts on `*'-marked
files). Or change it to `D' and then delete the flagged
files.
Because mark `C' is used, there is no confusion with
files that might be marked with `*' or any other mark.
You can have any number of different marks at any time,
giving them any conceptual meaning you like. Change
any of them to `*' to convert their files and dirs to
a set that you then act on in some way.
Dunno how much of this is documented in the manual,
but once you look at `C-h m' and then its mention
of `* c', you can pretty much imagine how it can be
put to good use.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Fri, 23 Oct 2015 20:56:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 21746 <at> debbugs.gnu.org (full text, mbox):
On Fri Oct 23 2015 Drew Adams wrote:
> What might be missing for you is this bit of info:
> `* c' lets you change the char that is used for a given
> mark. So you can, for example, change all `C' marks at
> a given moment to, say, `*' marks, and then use any
> action on the marked files (which acts on `*'-marked
> files). Or change it to `D' and then delete the flagged
> files.
Thank you, indeed I was missing this piece of info. I am just
wondering: how often are you using this? Is this a feature which
should be exposed to all emacs beginners? If yes, it needs to be
documented better.
> Dunno how much of this is documented in the manual, but once you
> look at `C-h m' and then its mention of `* c', you can pretty much
> imagine how it can be put to good use.
Yes, you are probably right. dired-change-marks bound to `* c'
seems to be the command that needs to be advertised better in order
to make these marks useful. (In my every-day usage of dired,
I still do not see actual benefits from this feature.)
Roland
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Fri, 23 Oct 2015 21:59:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Thank you, indeed I was missing this piece of info. I am just
> wondering: how often are you using this? Is this a feature which
> should be exposed to all emacs beginners? If yes, it needs to be
> documented better.
There is a lot in Dired that I think should be exposed/documented
better/more. By default we don't even load dired-x.el or
dired-aux.el, and they provide lots of stuff useful even for
beginners, including lots of menus.
I would be in favor of our loading both of these Dired libraries
by default. There is lots in Dired that users can benefit from,
but they are typically unaware of it.
(Also, we provide only rudimentary font-lock highlighting.)
> > Dunno how much of this is documented in the manual, but once you
> > look at `C-h m' and then its mention of `* c', you can pretty much
> > imagine how it can be put to good use.
>
> Yes, you are probably right. dired-change-marks bound to `* c'
> seems to be the command that needs to be advertised better in order
> to make these marks useful. (In my every-day usage of dired,
> I still do not see actual benefits from this feature.)
Marking with `C' is still useful, even if you never do
anything with those marks. It provides a clear indication
of the copied files.
You can always remove just the `C' marks (using `M-DEL',
aka `<M-backspace>'), if they get in your way. Or remove
all marks (using `C-u M-DEL'). `M-DEL' is another key that
is not as well known as it should be, IMO.
All in all, we don't advertise much of what Dired has to offer.
(FWIW, Stefan made it clear that he never uses Dired.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 01:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 21746 <at> debbugs.gnu.org (full text, mbox):
On Fri Oct 23 2015 Drew Adams wrote:
> There is a lot in Dired that I think should be exposed/documented
> better/more. By default we don't even load dired-x.el or
> dired-aux.el, and they provide lots of stuff useful even for
> beginners, including lots of menus.
>
> I would be in favor of our loading both of these Dired libraries
> by default. There is lots in Dired that users can benefit from,
> but they are typically unaware of it.
There is a big difference between exposing and documenting more
features from dired. I immediately agree on better documentation of
dired features. But I am not sure it will make new emacs users
happy when they get overwhelmed by features they do not understand.
Advanced users, on the other hand, know how to read the manuals and
then get the customization they want.
> Marking with `C' is still useful, even if you never do anything
> with those marks. It provides a clear indication of the copied
> files.
That's exactly why these C's are irritating and inconsistent: the
properly documented marks `*' and `D' serve the purpose of
indicating that an action _will be_ performed on certain files. The
C's indicate that an action _has been_ performed and they get into
the way when you are using the other marks.
Say, before marking files for some new action I type `g'
(revert-buffer). If this gives me an unmodified buffer, there are
no left-over marks floating around that I have overlooked. The C's
are just in the way for how marks are used otherwise.
Roland
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 05:27:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 23 Oct 2015 14:57:35 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 21746 <at> debbugs.gnu.org
>
> > Thank you, indeed I was missing this piece of info. I am just
> > wondering: how often are you using this? Is this a feature which
> > should be exposed to all emacs beginners? If yes, it needs to be
> > documented better.
>
> There is a lot in Dired that I think should be exposed/documented
> better/more. By default we don't even load dired-x.el or
> dired-aux.el, and they provide lots of stuff useful even for
> beginners, including lots of menus.
>
> I would be in favor of our loading both of these Dired libraries
> by default. There is lots in Dired that users can benefit from,
> but they are typically unaware of it.
Aren't the commands and options there autoloaded? If not, we could
autoload them, which would solve the visibility problem without
bloating the minimal memory footprint too much. Patches welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 06:11:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 23 Oct 2015 13:30:29 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
>
> > I have never figured out a
> > reason why copying a file in dired gives the copied file a marker
> > `C'.
>
> The reason (IMO) is that the marker indicates what the
> operation was, so you can easily identify - *and then
> operate on* the files that were copied (or whatever
> the operation was).
>
> What might be missing for you is this bit of info:
> `* c' lets you change the char that is used for a given
> mark. So you can, for example, change all `C' marks at
> a given moment to, say, `*' marks, and then use any
> action on the marked files (which acts on `*'-marked
> files). Or change it to `D' and then delete the flagged
> files.
>
> Because mark `C' is used, there is no confusion with
> files that might be marked with `*' or any other mark.
>
> You can have any number of different marks at any time,
> giving them any conceptual meaning you like. Change
> any of them to `*' to convert their files and dirs to
> a set that you then act on in some way.
>
> Dunno how much of this is documented in the manual,
> but once you look at `C-h m' and then its mention
> of `* c', you can pretty much imagine how it can be
> put to good use.
Patches to document this are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:05:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > There is a lot in Dired that I think should be exposed/documented
> > better/more. By default we don't even load dired-x.el or
> > dired-aux.el, and they provide lots of stuff useful even for
> > beginners, including lots of menus.
> >
> > I would be in favor of our loading both of these Dired libraries
> > by default. There is lots in Dired that users can benefit from,
> > but they are typically unaware of it.
>
> There is a big difference between exposing and documenting more
> features from dired.
We generally don't document stuff in the manual that is not
exposed by default. Loading dired-x.el and dired-aux.el
along with dired.el would help users, IMO. (We are not in
1985 anymore, when it might have made sense to reduce the
default footprint of Dired.)
> I immediately agree on better documentation of
> dired features. But I am not sure it will make new emacs users
> happy when they get overwhelmed by features they do not understand.
> Advanced users, on the other hand, know how to read the manuals and
> then get the customization they want.
There is no overwhelming by dired-x.el or dired-aux.el.
No one requires anyone to use or even be aware of a
particular command or key that is available.
The proof: `* c' has been available to you since Day One,
as part of dired.el, and you admit that you just learned
about it today. So clearly its presence did not overwhelm
you all these years. ;-)
> > Marking with `C' is still useful, even if you never do anything
> > with those marks. It provides a clear indication of the copied
> > files.
>
> That's exactly why these C's are irritating and inconsistent: the
> properly documented marks `*' and `D' serve the purpose of
> indicating that an action _will be_ performed on certain files.
No, they just mark files, in particular ways (different ways).
They indicate that actions _might_ be performed on the files.
> The C's indicate that an action _has been_ performed
And that actions might be performed on the files they mark.
Via `* c'.
There is nothing unique about `C' marks in that context.
Once you know about `* c' you know that any mark can serve to
both (a) mark files in a particular way, distinguishing them
and (b) allow you to act on them (via `* c'). You can, in
effect, temporarily tag sets of files in different ways
(using different marks), and then act on them.
> and they get into the way when you are using the other marks.
No, not in terms of actions that use those marks. An action
that acts on `*' marks or `D' marks does not act on `C' marks.
(I assume you meant only `*' and `D' by "the other marks",
though there can be any number of other marks.)
> Say, before marking files for some new action I type `g'
> (revert-buffer). If this gives me an unmodified buffer, there are
> no left-over marks floating around that I have overlooked. The C's
> are just in the way for how marks are used otherwise.
You could make a reasonable argument that all marks should
be removed by `g', but that is a separate question. I might
disagree with that argument, but it is a reasonable one.
(FWIW, if you want to remove all marks you can use `C-x C-v',
but that updates the listing, which `g' does not do.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:05:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > > Thank you, indeed I was missing this piece of info. I am just
> > > wondering: how often are you using this? Is this a feature which
> > > should be exposed to all emacs beginners? If yes, it needs to be
> > > documented better.
> >
> > There is a lot in Dired that I think should be exposed/documented
> > better/more. By default we don't even load dired-x.el or
> > dired-aux.el, and they provide lots of stuff useful even for
> > beginners, including lots of menus.
> >
> > I would be in favor of our loading both of these Dired libraries
> > by default. There is lots in Dired that users can benefit from,
> > but they are typically unaware of it.
>
> Aren't the commands and options there autoloaded?
No.
> If not, we could autoload them, which would solve the
> visibility problem without bloating the minimal memory
> footprint too much. Patches welcome.
No, it would not solve the visibility or discoverability
problem, IMO. Users are much more likely to find and use
the commands and keys they provide when they are (a) in
the menus and (b) documented in `C-h m'.
As for the minimal footprint: dired.el is not even loaded
by default (`C-x d' is autoloaded). These 3 libraries
are no big deal, footprint-wise.
*IF* a user chooses to use `C-x d', and thus pay the cost
of loading dired.el, it is not a big deal to load the other
two at the same time and get the benefit of their menu
additions, keys, and commands. (IMHO.)
But hey, it's been like this for 40 years. I have no
problem with it continuing like this for another 40. ;-)
(I use Dired+, which does load the other 2, in addition
to adding more stuff to bloat the memory. ;-))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:12:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 01:04:06 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 21746 <at> debbugs.gnu.org
>
> > There is a big difference between exposing and documenting more
> > features from dired.
>
> We generally don't document stuff in the manual that is not
> exposed by default.
That's not true, there are a lot of stuff documented in the manual
that isn't exposed by default. Rmail, for instance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:14:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 01:04:08 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: winkler <at> gnu.org, 21746 <at> debbugs.gnu.org
>
> > > There is a lot in Dired that I think should be exposed/documented
> > > better/more. By default we don't even load dired-x.el or
> > > dired-aux.el, and they provide lots of stuff useful even for
> > > beginners, including lots of menus.
> > >
> > > I would be in favor of our loading both of these Dired libraries
> > > by default. There is lots in Dired that users can benefit from,
> > > but they are typically unaware of it.
> >
> > Aren't the commands and options there autoloaded?
>
> No.
>
> > If not, we could autoload them, which would solve the
> > visibility problem without bloating the minimal memory
> > footprint too much. Patches welcome.
>
> No, it would not solve the visibility or discoverability
> problem, IMO. Users are much more likely to find and use
> the commands and keys they provide when they are (a) in
> the menus and (b) documented in `C-h m'.
>
> As for the minimal footprint: dired.el is not even loaded
> by default (`C-x d' is autoloaded).
You said above that we don't load dired-x and dired-aux, so I thought
you meant this in contrast with dired.el itself which is preloaded. I
should have checked, sorry.
But if none of them is preloaded, what is it that we do with dired.el
and don't do with the other two packages?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:18:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > > There is a big difference between exposing and documenting more
> > > features from dired.
> >
> > We generally don't document stuff in the manual that is not
> > exposed by default.
>
> That's not true, there are a lot of stuff documented in the manual
> that isn't exposed by default. Rmail, for instance.
There is some such stuff. But there is certainly a lot more
that is not. I stand by my statement, which intentionally said
that we "_generally_" do not document stuff that is not exposed
by default.
We certainly do not _generally document_ stuff in the manual
that is not exposed by default.
But if you want to document all, or even some, of the keys
and commands provided by dired-x.el and dired-aux.el, even
without loading them along with dired.el, that's fine by me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:23:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> But if none of them is preloaded, what is it that we do with dired.el
> and don't do with the other two packages?
We load dired.el when you use `C-x d' (or `C-x 4 d' etc.).
We do not load the other two when you do that. I think we
should. We should consider them an integral part of Dired,
including for documentation purposes. I see no reason not
to.
I don't even see any reason for the division into 3 files
at this point. But it doesn't bother me that there are 3.
I just think they should be treated together, as if one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:25:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 01:17:05 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: winkler <at> gnu.org, 21746 <at> debbugs.gnu.org
>
> We certainly do not _generally document_ stuff in the manual
> that is not exposed by default.
>
> But if you want to document all, or even some, of the keys
> and commands provided by dired-x.el and dired-aux.el, even
> without loading them along with dired.el, that's fine by me.
Would you like to propose documentation patches for the Dired stuff
you think is important, but is missing from the manual? TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:29:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 01:21:52 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: winkler <at> gnu.org, 21746 <at> debbugs.gnu.org
>
> > But if none of them is preloaded, what is it that we do with dired.el
> > and don't do with the other two packages?
>
> We load dired.el when you use `C-x d' (or `C-x 4 d' etc.).
> We do not load the other two when you do that. I think we
> should. We should consider them an integral part of Dired,
> including for documentation purposes. I see no reason not
> to.
Would adding to dired.el autoload cookies for the commands and options
in the other 2 packages have the same effect, as far as
discoverability is concerned, as loading them? If not, what will be
missing?
> I don't even see any reason for the division into 3 files
> at this point.
The 2 additional files almost double the size of the Dired-related
byte code. That's pretty significant, IMO, although not a
catastrophe.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:31:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Would you like to propose documentation patches for the Dired stuff
> you think is important, but is missing from the manual? TIA.
No, sorry.
What would presumably be easy to do would be to load all
of the Dired files together. I think that would be an
easy way to help understanding, discovery, and visibility.
More doc could be helpful too, but it is less important than
loading the files automatically (upon using `C-x d'), and it
requires more work (by someone).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:35:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > > But if none of them is preloaded, what is it that we do with dired.el
> > > and don't do with the other two packages?
> >
> > We load dired.el when you use `C-x d' (or `C-x 4 d' etc.).
> > We do not load the other two when you do that. I think we
> > should. We should consider them an integral part of Dired,
> > including for documentation purposes. I see no reason not
> > to.
>
> Would adding to dired.el autoload cookies for the commands and options
> in the other 2 packages have the same effect, as far as
> discoverability is concerned, as loading them? If not, what will be
> missing?
If I understand you correctly, no. The point is to make
their commands and menu items apparent from the outset in
Dired. IIUYC, what you describe would have Dired start
without them, and only if someone used one of their commands
would they be loaded. That doesn't help discovery of what
they have to offer.
> > I don't even see any reason for the division into 3 files
> > at this point.
>
> The 2 additional files almost double the size of the Dired-related
> byte code. That's pretty significant, IMO, although not a
> catastrophe.
Yes.
I think that people who use Dired would be willing to pay
that price (if they knew about the features). And people
who do not use Dired would not pay any Dired price.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 08:52:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 01:34:01 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: winkler <at> gnu.org, 21746 <at> debbugs.gnu.org
>
> > > > But if none of them is preloaded, what is it that we do with dired.el
> > > > and don't do with the other two packages?
> > >
> > > We load dired.el when you use `C-x d' (or `C-x 4 d' etc.).
> > > We do not load the other two when you do that. I think we
> > > should. We should consider them an integral part of Dired,
> > > including for documentation purposes. I see no reason not
> > > to.
> >
> > Would adding to dired.el autoload cookies for the commands and options
> > in the other 2 packages have the same effect, as far as
> > discoverability is concerned, as loading them? If not, what will be
> > missing?
>
> If I understand you correctly, no. The point is to make
> their commands and menu items apparent from the outset in
> Dired. IIUYC, what you describe would have Dired start
> without them, and only if someone used one of their commands
> would they be loaded. That doesn't help discovery of what
> they have to offer.
The commands will be apparent if we use autoload cookies, if by
"apparent" you mean the help command will know about them (if you mean
something else, please tell). If we want them to be in the menus, we
could perhaps add the missing menu items (I didn't check if that will
work, though).
Once again, patches are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 09:36:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 21746 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> (FWIW, if you want to remove all marks you can use `C-x C-v',
M-DEL
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 16:07:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > > Would adding to dired.el autoload cookies for the commands and options
> > > in the other 2 packages have the same effect, as far as
> > > discoverability is concerned, as loading them? If not, what will be
> > > missing?
> >
> > If I understand you correctly, no. The point is to make
> > their commands and menu items apparent from the outset in
> > Dired. IIUYC, what you describe would have Dired start
> > without them, and only if someone used one of their commands
> > would they be loaded. That doesn't help discovery of what
> > they have to offer.
>
> The commands will be apparent if we use autoload cookies, if by
> "apparent" you mean the help command will know about them (if you mean
> something else, please tell). If we want them to be in the menus, we
> could perhaps add the missing menu items (I didn't check if that will
> work, though).
By "apparent" I mean (and I think I said so) not only that help
commands know about these features (keys, commands), but that
their submenus and their menu items are also available in Dired
from the outset.
But yes, I almost mentioned, along the lines of what you are
suggesting, that if you prefer to do all of the following,
instead of simply loading all dired*.el files together, then
that would be fine too:
1. Add all of the menu stuff to dired.el (or use some equivalent
way to include them from the outset).
2. Ensure that :keys is used for them (or some equivalent), so
that the associated keys are mentioned in the menus.
3. Autoload all of the commands.
A third possibility is to merge all of the other two files
into dired.el.
Both of these two possibilities are a lot more work than
just ensuring that when dired.el is loaded (however it
might be) the other two are loaded immediately also.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 16:07:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > (FWIW, if you want to remove all marks you can use `C-x C-v',
>
> M-DEL
Yes, I already mentioned that earlier. Specifically `C-u M-DEL',
if you want to remove all marks of any kind.
And that is exactly what I do, FWIW, if I no longer want to
see `C' marks or similar.
I mentioned `C-x C-v' in the context of mentioning `g' (and
I pointed out the differences).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 16:15:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > > (FWIW, if you want to remove all marks you can use `C-x C-v',
> >
> > M-DEL
>
> Yes, I already mentioned that earlier. Specifically `C-u M-DEL',
> if you want to remove all marks of any kind.
>
> And that is exactly what I do, FWIW, if I no longer want to
> see `C' marks or similar.
FWIW: In fact, I use this behavior so much, and I like it
and the rest of the Dired model of marking and acting on
files and dirs so much, that I added the same thing,
including the key bindings (e.g. `C-u M-DEL') to the
bookmark display list (`*Bookmark List*'), in Bookmark+.
A user familiar with either Dired or Bookmark+ is thus
familiar with the other from the outset (wrt marking and
acting on the listed entries).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 20:52:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 21746 <at> debbugs.gnu.org (full text, mbox):
On Sat Oct 24 2015 Drew Adams wrote:
> > > (FWIW, if you want to remove all marks you can use `C-x C-v',
> >
> > M-DEL
>
> Yes, I already mentioned that earlier. Specifically `C-u M-DEL',
> if you want to remove all marks of any kind.
This thread has moved in a different direction from why I originally
submitted this bug report. I know that there are various ways to
get rid of the C's when copying files in dired. But nobody showed
why they are useful in the first place in some common usage scenario
justifying the current default. Therefore I think that the default
of dired-keep-marker-copy should be changed to nil:
- The C's are irritating and inconsistent:
The marks `*' and `D' indicate that an action _will be_ performed
on certain files. The C's indicate that an action _has been_
performed.
- There is no future action associated with the C's (nor has anybody
shown that this would be desirable)
Roland
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 21:11:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 21746 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" <winkler <at> gnu.org> writes:
> - There is no future action associated with the C's (nor has anybody
> shown that this would be desirable)
You can move among them with M-{ and M-}.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 21:31:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> I know that there are various ways to
> get rid of the C's when copying files in dired. But nobody showed
> why they are useful in the first place in some common usage scenario
> justifying the current default.
I did. But you apparently don't want to recognize this use as
being useful. I'll repeat it, just in case you didn't hear it:
To distinguish/identify the files that were copied. And to do
so in a way that they can be further acted on in Dired. IOW,
in a Dired-consistent way. Both parts of this are useful:
(1) easily see which were copied and (2) easily act on them
or on any subset of them. #2 requires #1, but #1 is useful
on its own.
How else could Dired distinguish the copied files? That is,
what are the alternatives? We can imagine a few:
1. Highlight their lines in some way. Reasonable. And with
similar behavior needs: users need a way to remove the
highlighting.
And some might find the higlighting annoying. But they
could of course customize its face to remove its effect.
2. Use `*' instead of `C'. Confusion with other, pre-existing
`*' marks - no distinction. Likewise, for `D'.
3. List the copied files only in a separate log buffer.
You can probably come up with some additional ways.
None of these give you the ability to do something with just
those files or a subset of them.
For any proposal you might make, you would need to include some
way to (a) get the list of copied files, (b) perhaps selectively
edit it, and then (c) act on the remaining files in that list. I.e.,
you need some way to let users act on any subset of those files.
> Therefore
"Therefore"? Because no one has shown how `C' marking is useful?
See above.
> I think that the default of dired-keep-marker-copy should be
> changed to nil:
>
> - The C's are irritating and inconsistent:
>
> The marks `*' and `D' indicate that an action _will be_ performed
> on certain files. The C's indicate that an action _has been_
> performed.
Again, `*' and `D' do _not at all_ indicate that any action
_will be_ performed on the marked files. They indicate that
you _can_ act on them. Nothing more than that.
And `C' indicates the same thing: you can, with one command/key,
change `C' to `*' or `D', putting all of those files in the
same situation as your beloved (even if untrue) "_will be_
performed" situation.
That's the point of `C' marking: to _indicate_ the copied files.
Not marking the copied files gives you NO way to choose them
for subsequent action. If they are not marked (or equivalent)
then you cannot distinguish them - they do not stand out from
the rest.
> - There is no future action associated with the C's (nor has anybody
> shown that this would be desirable)
On the contrary. There are a great many future actions that
you can perform on the files marked with `C' (by changing `C'
to `*' or `D').
But you certainly cannot do anything to that set of files (or
to a subset) if you cannot distinguish it. Not identifying
the copied files apparently irritates you less, but it does
not help anyone do anything with them.
It is _not_ that it would always be desirable to do something
additional with all of the files marked `C' (see your claim
that no one has shown that that is desirable). That's part
of the point: no such hard-coded behavior is appropriate.
What is appropriate is to _be able_ to perform _any_ Dired
action on _any_ of those files (and not only on all of them).
Prerequisites for this ability are (1) being able to
distinguish the copied files and (2) being able to choose
which of them, if any, to act on in some other way.
It sounds to me like you should just customize
`dired-keep-marker-copy' to nil for yourself. I see no good
argument for changing the default value. Your only reason to
use `nil' is a personal one: you are irritated by the marks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 21:35:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > - There is no future action associated with the C's (nor has anybody
> > shown that this would be desirable)
>
> You can move among them with M-{ and M-}.
You can, but that action is not specific to `C' marks.
You can of course move among only the `C'-marked files using,
say, `C-M-s ^C'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sat, 24 Oct 2015 22:01:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 21746 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> > - There is no future action associated with the C's (nor has anybody
>> > shown that this would be desirable)
>>
>> You can move among them with M-{ and M-}.
>
> You can, but that action is not specific to `C' marks.
Like a lot of other things you can do with them.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 00:17:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 21746 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> On the contrary. There are a great many future actions that you can
> perform on the files marked with `C' (by changing `C' to `*' or `D').
I totally agree that the marks are useful. OTOH, I think they confuse
nearly everyone when first using dired. The intention should be spoken
out in the docs if this isn't the case (didn't check), but I guess we
all agree about that anyway.
And AFAICT nil is not a valid value for `dired-keep-marker-copy', but a
space character should "work".
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 04:02:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 21746 <at> debbugs.gnu.org (full text, mbox):
On Sat Oct 24 2015 Drew Adams wrote:
> I did. But you apparently don't want to recognize this use as
> being useful. I'll repeat it, just in case you didn't hear it:
>
> To distinguish/identify the files that were copied. And to do
> so in a way that they can be further acted on in Dired. IOW,
> in a Dired-consistent way. Both parts of this are useful:
> (1) easily see which were copied and (2) easily act on them
> or on any subset of them. #2 requires #1, but #1 is useful
> on its own.
>
> How else could Dired distinguish the copied files?
It shouldn't. Marks are for new actions in the future, not for old
ones from the past.
If you nonetheless like inconsistent behavior, don't make it the
default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 05:14:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > To distinguish/identify the files that were copied. And to do
> > so in a way that they can be further acted on in Dired. IOW,
> > in a Dired-consistent way. Both parts of this are useful:
> > (1) easily see which were copied and (2) easily act on them
> > or on any subset of them. #2 requires #1, but #1 is useful
> > on its own.
> >
> > How else could Dired distinguish the copied files?
>
> It shouldn't. Marks are for new actions in the future, not
> for old ones from the past.
Apparently whoever designed Dired 30-40 years ago didn't
agree. But that's beside the point (your point, at least).
_You_ don't think marks should be used for this - fine.
Or rather, you don't think they should be used for this by
_default_. That's it, right?
You at least don't begrudge users the ability to choose for
themselves, do you? You wouldn't suggest we take away options
`dired-keep-marker-copy', `dired-keep-marker-hardlink',
`dired-keep-marker-relsymlink', `dired-keep-marker-rename',
and `dired-keep-marker-symlink', would you?
If you would, i.e., even if you don't want Emacs to ever use
marks for such confirmation/indication, surely you can imagine
that it can make sense to _somehow_ confirm which files were
successfully copied (or hardlinked or symlinked or relsymlinked
or renamed). What other way would you prefer to do that?
But if you wouldn't, and you just want to change the default
behavior, then I'd suggest that you come up with a good reason
for doing so. Something more than the fact that such marks
"irritate" you.
> If you nonetheless like inconsistent behavior, don't make it the
> default.
Blah. Just because _you_ never made use of such marks, that
does not mean they are not useful or their use is "inconsistent".
Far from it. They have been used consistently for decades,
throughout Dired - witness the 5 options I just mentioned.
This use of marks conflicts with your limited notion of what
Dired marks are for. OK. But you really have nothing useful
to say about _this_ particular use of marks, because you have
never taken advantage of it.
It's certainly your right to go on ignoring this feature, and
if you don't want to be "irritated" by such marks, customize
the relevant options to remove them. Easy. End of story.
Or else come up with a good reason why your personal
preference should be foisted on everyone as a new default
behavior, reversing longstanding practice.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 12:56:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 21746 <at> debbugs.gnu.org (full text, mbox):
"Roland Winkler" <winkler <at> gnu.org> writes:
> Marks are for new actions in the future,
Exactly. That's why they are there.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 17:41:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 21746 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
The reason I make Dired commands put marks on newly created file names
is so that you can use those marks to choose those files for another
operation.
Of course, people only occasionally want to do that. When you don't
want to do another operation on those files, you can simply ignore the
marks, or unmark the files.
It seems to be a useful benefit in a fraction of cases, and no loss
in the rest.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Sun, 25 Oct 2015 18:41:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 24 Oct 2015 23:01:12 -0500
> From: "Roland Winkler" <winkler <at> gnu.org>
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 21746 <at> debbugs.gnu.org
>
> > How else could Dired distinguish the copied files?
>
> It shouldn't. Marks are for new actions in the future, not for old
> ones from the past.
>
> If you nonetheless like inconsistent behavior, don't make it the
> default.
We are arguing here about the default value of a defcustom. Moreover,
this value was introduced 23 years ago, never changed since then, and
I don't remember any complaints about that default (but if you find
any, please point to them).
So it doesn't sound wise to me to change that default based on the
fact that you, Roland, dislike it. You can always customize this
variable (and other similar dired-keep-marker-* options) to you
heart's content, right? OTOH, changing this long-standing default
would be an incompatible change, something that we only do when the
community as a whole requests. Which is not the case here, I think.
Thus, I think we should document this subtlety, both in the doc
strings of the corresponding dired-do-* commands and in the user
manual, and otherwise leave the existing default alone.
Patches for the documentation are welcome.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Thu, 29 Oct 2015 00:16:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> Yes, I already mentioned that earlier. Specifically `C-u M-DEL',
> if you want to remove all marks of any kind.
Have you really tried `C-u M-DEL'? I see this error:
dired-unmark-all-files: Symbol’s value as variable is void: query
A bug?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Thu, 29 Oct 2015 00:39:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 21746 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
> dired-unmark-all-files: Symbol’s value as variable is void: query
Indeed. And in some cases, I don't even get a minibuffer prompt but
only
C-u M-DEL
key feedback in the echo area (though typing RET works in the sense that
I still get the above error).
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Thu, 29 Oct 2015 00:54:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 21746 <at> debbugs.gnu.org (full text, mbox):
> > Yes, I already mentioned that earlier. Specifically `C-u M-DEL',
> > if you want to remove all marks of any kind.
>
> Have you really tried `C-u M-DEL'?
I'm sorry. I meant `M-DEL RET'. It's automatic for my fingers,
but not for my brain.
> I see this error:
> dired-unmark-all-files: Symbol’s value as variable is void: query
> A bug?
Yes, I see the same as you. Indeed, it seems to be a bug.
As Michael indicated, I get no prompt to enter the mark character,
and when I nevertheless do so (e.g. I hit `*'), I get the error
you cited.
Please file a separate bug for that. It is unrelated to this
thread. Sorry I mistyped the key sequence for removing all
marks (which is `M-DEL RET'). But glad it led you your finding
this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21746; Package
emacs.
(Thu, 28 Apr 2022 11:51:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 21746 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thus, I think we should document this subtlety, both in the doc
> strings of the corresponding dired-do-* commands and in the user
> manual, and otherwise leave the existing default alone.
I've now done this in Emacs 29, and am closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
21746 <at> debbugs.gnu.org and "Roland Winkler" <winkler <at> gnu.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 28 Apr 2022 11:52:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 27 May 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 332 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.