From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.bugs Subject: bug#41097: 28.0.50; (dired-toggle-marks) not working after copy Date: Mon, 11 May 2020 08:26:15 +0300 Message-ID: <20200511052615.GB2820@protected.rcdrun.com> References: <83sgg7ddtz.fsf@gnu.org> <20200510153311.GH28606@protected.rcdrun.com> <83r1vrdbc0.fsf@gnu.org> <6bc132d3-2d2d-4eb3-86dd-b818c1b856a2@default> <83mu6fd9q6.fsf@gnu.org> <83k11jd8bs.fsf@gnu.org> <744818d3-e904-43a1-a3c1-a0a4a550ada1@default> <20200510195409.GD6298@protected.rcdrun.com> <5ac3067a-2f37-4122-8920-ca93d010c0dc@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114640"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.14.0 (2020-05-02) Cc: michael_heerdegen@web.de, 41097@debbugs.gnu.org, tomasn@posteo.net, arthur.miller@live.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 11 07:27:08 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jY0y4-000Thl-Lh for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 07:27:08 +0200 Original-Received: from localhost ([::1]:40794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jY0y3-0003zQ-8l for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 May 2020 01:27:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jY0xy-0003zI-36 for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 01:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39420) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jY0xx-0004Mp-Q2 for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 01:27:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jY0xx-0001Ze-MN for bug-gnu-emacs@gnu.org; Mon, 11 May 2020 01:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jean Louis Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 May 2020 05:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41097 X-GNU-PR-Package: emacs Original-Received: via spool by 41097-submit@debbugs.gnu.org id=B41097.15891747976000 (code B ref 41097); Mon, 11 May 2020 05:27:01 +0000 Original-Received: (at 41097) by debbugs.gnu.org; 11 May 2020 05:26:37 +0000 Original-Received: from localhost ([127.0.0.1]:50966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY0xY-0001Yg-HO for submit@debbugs.gnu.org; Mon, 11 May 2020 01:26:36 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:49089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jY0xV-0001YJ-IC for 41097@debbugs.gnu.org; Mon, 11 May 2020 01:26:35 -0400 Original-Received: from localhost ([::ffff:41.210.154.28]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000006FD13.000000005EB8E1FD.00007742; Sun, 10 May 2020 22:26:20 -0700 Content-Disposition: inline In-Reply-To: <5ac3067a-2f37-4122-8920-ca93d010c0dc@default> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180054 Archived-At: * Drew Adams [2020-05-11 00:16]: > > > Words matter. I gave a reason why I think > > > Emacs chose to use "flag" for `D' - and only > > > for `D': > > > to flag something is to draw special attention > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > to it. > > > > Your are rights that word matters. Then if I may ask, why is then > > "flag" introduced instead of "Delete mark"? > > I said what I _think_ is the reason "flag" was > used for `D' (and ONLY for `D') - see above. > > https://en.wiktionary.org/wiki/flag#Verb: > > "To mark with a flag, especially to indicate the > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > importance of something." > ^^^^^^^^^^ > > Not just to indicate something - to point it out - > but to point it out as being of special importance. > > In this sense, and especially when used in contrast > to "mark", it means to mark _specially_, i.e., more > than the way other Dired marks mark. I found the definition in the Merriam Webster, thank you, that is right, to flag means to mark it to attract attention. Attracting attention only relates to deletion in Emacs. But the logics is individual in my opinion. For example I like to mark files so that they are renamed or copied, and that is what matters to me, that is where I need my attention. On files marked for deletion, I have less attention, well, why? Because the files are marked for deletion, they are less important. Even if I by accident remove the D flag, it does not matter, as those files are less important. So to use "flag" for "Mark for deletion" in my individual case is not same meaning and is not marking for attention. > > How "flag" makes the deleting action more clear? It does not, if you > > ask me. > > Ask whomever wrote Dired and maintained it for 35 > years. > > It may not make "the deleting action" more clear, > especially to someone for whom English is not the > first language. Both "mark" and "flag" point > something out - that's true. The meaning of "to mark with special attention" is not synonym to "to mark for deletion". The menu items like "Mark -> Flag" is ambiguous. You pointed out yourself to the definition of the "to flag" -- and there is one good on Merriam-Webster too, so none of those definitons are saying that "flagging" is equivalent to "marking for deletion", they are saying that there is some special mark, not which one. > But the fact that ONLY `D' is referred to as a > "flag", and only it (not `C' or any other mark) > is referred to as "flagging" the file for the > given action, should draw _special_ attention to > it - should flag it (!) as being of particular > importance or meriting special attention. >From a viewpoint of user-friendly menus, I don't think that introduction of a "flag" with special meaning only in Emacs is helping users. > In any case, your argument is not with me. It's > not I who chose "flag". My point is only that > that's what Emacs does and has always done, and > Emacs is quite consistent about it. I am reading quote from the Emacs manual: ‘x’ Delete files flagged for deletion (‘dired-do-flagged-delete’). This could mean that there can be other flags, not only `D' because `x' is deleting files flagged for deletion, and that could, from viewpoint of a user, imply that there are other flags, not only for deletion. To summarize, for me, the manual is pretty clear, and user menu "Mark" is not intuitively clear, as without reading the manual one cannot know what means "Flag". > What's not OK, IMO, is to use both, but not use > them in a consistent way. After Eli's change, we > now have 2, and only 2, marks (`D' and `C') which > we are calling "flags". dired-toggle-marks is an interactive compiled Lisp function in ‘dired.el’. (dired-toggle-marks) Toggle marks: marked files become unmarked, and vice versa. Files marked with other flags (such as ‘D’) are not affected. ‘.’ and ‘..’ are never toggled. As always, hidden subdirs are not affected. The inconsistency is already in that documentation: - "marked with other flags (such as 'D')" implies that the C is also flag. Isn't that already inconsistency? > It could be argued that there's something special > about deleting. It's hard to argue that there's > something special about copying and deleting (as > opposed to renaming/moving and linking). You look individually, for your own needs. For me the files marked for deletion are not special, they are less special, well they go to "trash", right? Those files which have to be copied or marked for processing, are for me special files. And I use * mark for that as it is offered so. So most important marks, which require special attention are never "D" files, but those marked with "m", the marked files with "*". > Would you have preferred this? > > Mark > Unmark > Mark for Deletion > Mark Auto-save Files for Deletion > Mark Backup Files for Deletion > Mark Garbage Files for Deletion > Mark Executables > Mark Old Backups > Mark Directories > Mark Symlinks > Unmark All > Change Marks... > > That would have been OK, if a bit noisier and > less readable. Again, I'm not the one who > decided such things (long, long ago). That looks logical and understandable, it removes the ambiguity from the menu "Mark" and becomes user friendly. And I guess it would remove manual sections that are trying to explain the difference between flagging and marking too. If there would be clear English definition of "to flag" that it means "to mark for deletion", there would be no difference to introduce new special Emacs definition to tell users what flagging means. I am not against new definitions of words, I am just saying how I see that from viewpoint of a user. User in the first place, is not reading the manual, and what if manual is not distributed together with the emacs? > > Now these are not clear to me: > > > > - Flag extension -- how that can be clear what it does? Sure that I > > will find after some time what is meant, but I am saying, it is > > confusing and not user friendly. > > > > The Wordnet does not indicate that "flag" has the definition that you > > want, in the manner to distinguish it from "mark". It says "provide > > with a flag" and flag would be what? > > See above. It's English. If it's not > understandable to some people then that's > not great. But keep in mind that it is a > common verb, and Dired has used it this way > for decades (and Emacs has had lots of users > for whom English is not the first language). I am saying it only from user friendly view point. Myself I have marked extension many times. The menu "Flag extension" is not clear because if all others become clear that "to flag" means "to mark for deletion", then "mark extension" would mean "to mark extension for deletion". That menu item should be "Flag by extension" and not "Flag extension", because rarely somebody wish to "mark extension for deletion". If Dired and Emacs used it for decades, that does not necessarily mean that menu items are clear and user friendly. Menu item need not be short, some probably less important menu items are very long like "Use directory names in bufer names" is pretty long and is there all the time. Jean