From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#39902: 28.0.50; Marking in dired with active region Date: Sun, 15 Mar 2020 13:50:51 -0700 (PDT) Message-ID: <0066d43a-5f97-4c9d-a4b7-84c6b0ecf356@default> References: <87d09suras.fsf@web.de> <87tv33r8e2.fsf@mail.linkov.net> <87eeu6hpjf.fsf@web.de> <875zfixuoy.fsf@mail.linkov.net> <87h7z1jadw.fsf@web.de> <87y2sbloaa.fsf@mail.linkov.net> <877dzvgd4l.fsf@web.de> <8736aiqu3y.fsf@mail.linkov.net> <7a0a6f19-f958-4b38-beaf-3d60dc8a279f@default> <87d09lb1ts.fsf@mail.linkov.net> <87a74n4vet.fsf@web.de> <87eetzah2s.fsf@mail.linkov.net> <87zhcn9229.fsf@mail.linkov.net> <6d82d04a-db94-4df4-82cc-3ea13a78a4dd@default> <877dzqidzn.fsf@mail.linkov.net> <1e37a524-80d3-445f-8f81-a18539105ac3@default> <87pndhhyvk.fsf@mail.linkov.net> <1ce62594-cc2a-4e95-b2b3-d022fa65decd@default> <87bloybivx.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="5930"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , 39902@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 15 21:54:46 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 1jDaHU-0001Op-18 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Mar 2020 21:54:44 +0100 Original-Received: from localhost ([::1]:58650 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDaHS-00012W-Mr for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Mar 2020 16:54:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60956) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDaGp-00011O-Sx for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 16:54:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jDaGo-0007Zu-J7 for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 16:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57941) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jDaGo-0007Yh-7r for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 16:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jDaGo-0008EZ-6P for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 16:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Mar 2020 20:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39902 X-GNU-PR-Package: emacs Original-Received: via spool by 39902-submit@debbugs.gnu.org id=B39902.158430558531585 (code B ref 39902); Sun, 15 Mar 2020 20:54:02 +0000 Original-Received: (at 39902) by debbugs.gnu.org; 15 Mar 2020 20:53:05 +0000 Original-Received: from localhost ([127.0.0.1]:35681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDaFs-0008DM-QO for submit@debbugs.gnu.org; Sun, 15 Mar 2020 16:53:05 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:33904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDaFr-0008CD-0w for 39902@debbugs.gnu.org; Sun, 15 Mar 2020 16:53:03 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02FKqidI118711; Sun, 15 Mar 2020 20:52:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=ITluQfPApcXfyPmof5ulrhaavu0mDNs2sGV0o3ZnMwY=; b=L0jvsCXhn19VLRTutU9p2wo2L2o7yJDSXFEJ4LzWt4qH95XnEBO6CNWFPE0JtCJckybJ Pq5c8HNwmokmRU58K573X3JS+xEwPADdFmxSD/OcgPbmom6H6Q4+8kYFurs0h5IN6e9R 4OlPUB7S7xcPpB4KJQa/wnkUVg+9IKXYpZ/P66Ysw4Doqcr2cEOwj6c+CTH7uzuI4+Hr JCMGBVJ07l+cMXkJmZgAwLbAQY7I4K2HKoaU2hprCpeOumImDh6opAcsJH24W+BaxjPo /yNMxTxAo+949JYuQX/d4jksKGmJlzkg9FJP7Z151yOONiohthy5q+lwCkq0nKISYa5C 6g== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2yrq7kkw36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Mar 2020 20:52:56 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02FKoVia009187; Sun, 15 Mar 2020 20:50:55 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2ys8ravvu5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Mar 2020 20:50:55 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 02FKoqRO013583; Sun, 15 Mar 2020 20:50:53 GMT In-Reply-To: <87bloybivx.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9561 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003150113 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9561 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 malwarescore=0 mlxscore=0 phishscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003150114 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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:177389 Archived-At: > >> The most obvious way for users to mark e.g. next 2 files > >> is to type S-down 2 times, then type 'm', especially > >> convenient when arrow keys are located near the 'm' key. > > > > I don't have a problem with users doing that. What's the > > problem with that? What habit would be broken? >=20 > The habit of typing S-down twice to mark two files, not three. S-down doesn't mark anything. `m' and other keys mark files. And the fact of `m' marking files in the region is relatively recent. And there are many ways to define an active region, and for most of them the corner case you cited would be very rare. To me, this is a (minor) bug fix; nothing more. You can proclaim it backward-incompatible in terms of interactive behavior. That doesn't bother me. And as someone else pointed out, we usually don't cry "backward incompatible" when it comes to changing use behavior; we typically use that term for code changes. Emacs developers change behavior of user interactions fairly often (you among them), with nary a blink - and especially when it's about a bug fix. But if you are truly worried about that, and you honestly think that either (1) many users will be shocked by such a behavior fix or (2) you strongly hate the fix, then just add an option to provide the old, broken behavior. I'm not in favor of such an option, but if that's the price to pay to get this fixed, so be it. > > What we're talking about, I thought, is that, IF you use > > `m' (or other mark-changing keys) AFTER you do that (or > > after something else that selects parts of contiguous > > file lines as the active region), THEN that marking > > command acts on each file that has ANY part of its line > > selected. That's what the behavior should be, IMO. >=20 > 1. > > That second image, where point is not at bol, _should_ > > result in the 3rd file being marked, IMO - and it does. >=20 > 2. > > For me, it's about whether ANY (non-empty, hence the > > bolp fix) part of a file's line is selected. >=20 > Aren't the above two sentences contradicting? > Because on the second image there is only empty space > before the file name, so according to your second sentence, > the 3rd file should NOT be marked. What part of "ANY (non-empty...) part of a file's line" is unclear? I didn't say any non-whitespace part. > > (An action, such as renaming, might affect only the > > file-name portion as its _result_. But it takes > > effect on the file designated by that line. And other > > actions (e.g. chmod, touch) can affect other parts of > > the line (e.g. permissions, date). > > > > We've been around and around about the question now. > > I think those who have spoken up in this thread, > > including OP Michael - with you as the exception, feel > > the same way: Act on each file when any non-empty part > > of its line is in the active region. >=20 > Why non-empty part of the line? It's more logical about > the non-empty part of the file name, because dired > commands don't act on lines, but on files. Quite the contrary, as I and others have explained several times now. And in fact that's one of the main points: that's how Dired behaves. As I said in the very same paragraph as your cited #2, above: Actions in Dired are generally (maybe even only) apply to a file line, not to its file-name portion. (An action, such as renaming, might affect only the file-name portion as its _result_. But it takes effect on the file designated by that line. And other actions (e.g. chmod, touch) can affect other parts of the line (e.g. permissions, date).) Dired actions act directly on file/directory lines. Typically they do something to the file or dir. But in terms of the UI they act on the line. A mark on a line is, in UI or behavior terms, a mark on the line. It is only actions that _use_ marks that then act on the file/dir whose line is marked. The act of marking is not an action on the file/dir. But I (and others) have said this more than once. You remain unconvinced. And you are the one, I guess, who will or won't fix this, so you are the one who needs convincing. In terms of arguing for/against this, I think we're about done, no?