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, 22 Mar 2020 16:33:56 -0700 (PDT) Message-ID: <4dd30e49-9a6a-4962-a6f2-1a68a41ce5e2@default> References: <87d09suras.fsf@web.de> <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> <8736a7ajn5.fsf@web.de> <87fte52pbf.fsf@mail.linkov.net> <87o8sruchv.fsf@mail.linkov.net> <875zexf6l3.fsf@web.de> 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="41657"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39902@debbugs.gnu.org To: Michael Heerdegen , Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 23 00:35:14 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 1jGA7e-000Aje-2F for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 23 Mar 2020 00:35:14 +0100 Original-Received: from localhost ([::1]:54932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGA7c-0005HW-Ns for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Mar 2020 19:35:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60489) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGA7T-0005HO-4F for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 19:35:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jGA7R-000614-UO for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 19:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45179) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jGA7R-00060t-Pu for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 19:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jGA7R-000278-Nv for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 19:35:01 -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, 22 Mar 2020 23:35:01 +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.15849200518043 (code B ref 39902); Sun, 22 Mar 2020 23:35:01 +0000 Original-Received: (at 39902) by debbugs.gnu.org; 22 Mar 2020 23:34:11 +0000 Original-Received: from localhost ([127.0.0.1]:51152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jGA6c-00025f-Ol for submit@debbugs.gnu.org; Sun, 22 Mar 2020 19:34:11 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:42370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jGA6b-00025S-2L for 39902@debbugs.gnu.org; Sun, 22 Mar 2020 19:34:09 -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 02MNS8ok024091; Sun, 22 Mar 2020 23:34:02 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=JCr3Ngyl7ysQivOx9ZwPR0ZZY0qqJsQbdLqdAFu73sc=; b=gfH1KaUDIuoaIQ9/CbD6BynAiUukQYY263yEuV4OV+tC1iwb57G0cxgSBpaFXsO5YCQl AapsaAjlsQNkj5hyi32VouJOg0Umyn1xnG+UuGgCFjFYtjUp18TSCM7nx3tsnTmCp11y czl/QmwZ5rhyYmioDAEfN80eWRwYJuDJsYUgIGAlQO5llyuI6zMvXzGu3js2QGkMTQne HdEWoV8ZnDfi4rv/OAcHEyCEF2WSMxhPTPVrEtKFaynvASnAybsxtacIseWiq4fRM/yC G0FPR3IHQYLDa/6zXLuQ+2Nvkims4Mnhwwxp0PskZ5MEEo5tZOE92UgzpUbH3wYYI+0n vg== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2yx8abrub0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Mar 2020 23:34:02 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 02MNNA7O034324; Sun, 22 Mar 2020 23:34:02 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2ywwuh0phc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 22 Mar 2020 23:34:02 +0000 Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 02MNXvb6004694; Sun, 22 Mar 2020 23:33:58 GMT In-Reply-To: <875zexf6l3.fsf@web.de> 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=9568 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003220143 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9568 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003220143 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:177634 Archived-At: > > Here is a complete implementation, please try if it works for you: >=20 > Yes, works well, thank you very much. Also other marking commands seem > to work well with the new option. >=20 > The docstring of `dired-mark-inclusive' should be enhanced a bit I > think. You could add one sentence about what "inclusive" means, and > another saying that other (un-)marking commands are also covered. I took a quick look - didn't check much. =20 Seems OK to me too (but I'd prefer a non-nil default value for the option, as already mentioned). --- However, I notice one thing that seems like a bug (didn't notice it before) - and the bug is present even without the patch: If `use-empty-active-region' is non-nil, and the region is empty, then `m' marks the current line only sometimes, depending on where point is. And the behavior differs, depending on the value of option `dired-mark-inclusive': `dired-mark-inclusive' =3D nil: marks line only if point is on the 2nd file-name char or any char after that (including eol, i.e., _after_ the file name) `dired-mark-inclusive' =3D t: marks only if point is not at bol IMO, the behavior should be the same, regardless of the cursor position on the line. I think it should mark the line: * for any position, if `dired-mark-inclusive' =3D t * for any position on the file name, otherwise Juri, you decide the behavior for the nil case, but I think it should be consistent. Personally, I see no reason that point on the first file-name char would act differently from point on the second. And by the logic of non-inclusive I'd think that an empty region _after_ the file name wouldn't mark the line (no part of the file name is in the region). For the non-nil case, I think it's important that the line get marked even when point is at bol. Why? Consistency. And it's easy to hit `C-SPC' without realizing that you've done so - there's no good visual signal (just the "Mark activated" msg). In the non-nil case, especially, I really feel that a user expects the line to be marked, even if the region is empty (when `use-empty-active-region' is non-nil). --- As I said earlier, I really suspect that Emacs may have lurking bugs because stuff that makes use of `use-region-p' might not get tested with non-nil `use-empty-active-region'. And yet the reason for creating that option was for the addition of that function (or vice versa). [Frankly, I think things were clearer in the code before `use-region-p' and that option were added. `region-active-p' was clear; `use-region-p' hides use of an option, and I suspect that the non-nil case doesn't get tested much. When just `region-active-p' was used, it kinda invited testing whether the region was empty.] (FWIW, I don't use non-nil `use-empty-active-region'. But I imagine some people do.)