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 18:46:47 -0700 (PDT) Message-ID: 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> <0066d43a-5f97-4c9d-a4b7-84c6b0ecf356@default> <87bloxgp9g.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="18200"; 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 Mon Mar 16 03:08:41 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 1jDfBI-0004eN-FU for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Mar 2020 03:08:40 +0100 Original-Received: from localhost ([::1]:33258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDfBH-00074P-4C for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Mar 2020 22:08:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43803) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDerN-00025c-17 for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 21:48:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jDerL-0002oH-Jy for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 21:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jDerK-0002n4-Dp for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 21:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jDerK-00014h-Am for bug-gnu-emacs@gnu.org; Sun, 15 Mar 2020 21:48: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: Mon, 16 Mar 2020 01:48: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.15843232244042 (code B ref 39902); Mon, 16 Mar 2020 01:48:02 +0000 Original-Received: (at 39902) by debbugs.gnu.org; 16 Mar 2020 01:47:04 +0000 Original-Received: from localhost ([127.0.0.1]:35886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDeqO-000138-Ew for submit@debbugs.gnu.org; Sun, 15 Mar 2020 21:47:04 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:55784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDeqL-00012d-VC for 39902@debbugs.gnu.org; Sun, 15 Mar 2020 21:47:03 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02G1hW2n057067; Mon, 16 Mar 2020 01:46:55 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=E+osz3t+m82Alt19PRmOkAEgN7Osf2gBREzOFbCUgrQ=; b=LoYTQJsRA0wsSkAK2vUzffdEQm9Bc56LS51XbrdwnUBlCFZctQvGdOVPK3aYkTHs8+Ig 7tvPuhcm0Ml4BPdDBeFfoI5CMyyLp5DWoPXfEomsT5o5OMsqILHdaNa0SZM5lxP5GHrJ Y0YtmEb33SwgDFa8Uucfm2mghqYLB82qS1NPl0Gl3Hj+/H0vp9kknQFHCR72/tj8xXLQ W7kTCbl0iklZKIZHyqUyhlWUsHkaHihhthc7/E83qB/KsTM9K6pJ6UJ9Dkrq53xBzXQJ t1CttQ3dbUJ3pVIwUGOf10Zg5E66a2xIWUAxg2H1PhWlA71/yXYydk0hUvJxxDOmnxlN zg== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2yrqwmv5uu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Mar 2020 01:46:55 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02G1fh8n087665; Mon, 16 Mar 2020 01:46:54 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2ys927yxya-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Mar 2020 01:46:54 +0000 Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 02G1kmsX030828; Mon, 16 Mar 2020 01:46:51 GMT In-Reply-To: <87bloxgp9g.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 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003160006 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9561 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 phishscore=0 spamscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003160006 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:177403 Archived-At: > > Actions in Dired are generally (maybe even > > only) apply to a file line, not to its > > file-name portion. >=20 > When you are marking files, at what part of > the Dired buffer do you look? I'm sure at > file-names. Therefore actions in Dired apply > to file-names. No. 1. You may look at file names, file-name extensions, dates, permissions, sizes, symlink targets, marks, deletion flags,... - any and all of the info on a file line. 2. In particular, when multiple lines are marked you may well look at the marks. Or at the ranges of marks, when contiguous lines are marked. 3. Even if/when you do "look at file names" it does not follow ("therefore") that the UI actions you perform apply to file names. As I said, they can apply to marks (change, add, remove), and they can apply to lines (omit, delete, insert). And as I said, beyond UI actions, sure, many of the Dired actions ultimately act on files. Even in that case, they typically do not act directly on files. But only very few actions (in particular, renaming) apply to file names (as opposed to files). > > In terms of arguing for/against this, > > I think we're about done, no? >=20 > I already provided 2 strong arguments > that support the current implementation: >=20 > 1. the number of repeated keystrokes is equal > to the number of selected files, e.g. > 'm m' selects 2 files, 'C-SPC n n' selects 2 files, > 'S-down S-down' selects 2 files, etc. So what? The question before us has nothing whatsoever to do with repeated `m'. That's no argument for supporting the current behavior wrt using the region for marking. This is about a completely different way of marking a group of lines from using repeated `m'. The only things they have in common are (1) in both cases the lines acted on are consecutive, and (2) in both cases point is on the first or last of those lines. > This is an important property of the current > implementation. It's not at all a property of the behavior of using a region to select. Irrelevant. Apples & oranges. > 2. consistent visual feedback, i.e. when the > file name is not inside the selected region, > it should not be marked. It's not about the file name. As Michael said, you have a different opinion about that. OK. But that doesn't provide an argument for the behavior. That's just saying that you prefer the current behavior. Opinion cannot be a _reason supporting_ itself. > You provided only 1 argument for changes: >=20 > 1. mark the file name when the end of the > region is before the file name but not on > the beginning of the file line. I said nothing about marking file names. I don't believe that Dired marks are about marking file names. But yes, my opinion (not a reason for my opinion) is that it's clearer to act on each line that has some of it selected. Why? 1. That's what, I think, users expect, and it's what (I think) they're used to in other, similar UIs. 2. It's consistent with what happens in the rest of Dired. When you hit `m' - or perform nearly any other action - does it matter where point is on the line? No, of course not. Do we expect that point needs to be on the file name itself because that's where you should be looking? No. > And I agreed that this makes sense as well. So we agree on the fix? Any line, any (non-empty) part of which is selected, gets the mark action? > Then I proposed to add a new option, but > you disagreed. Please, add any options you like, if the default behavior is to fix this (minor) bug as just mentioned. That doesn't mean that I agree that we need such an option, or that it's a good idea to add it. But (as I said already) if that's the price for getting the bug fixed, so be it.