GNU bug report logs - #27896
25.2; `C-M-%' with `rectangle-mark-mode'

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: minor; Reported by: Drew Adams <drew.adams@HIDDEN>; dated Tue, 1 Aug 2017 04:18:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 27896 <at> debbugs.gnu.org:


Received: (at 27896) by debbugs.gnu.org; 2 Aug 2017 22:22:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Aug 02 18:22:37 2017
Received: from localhost ([127.0.0.1]:39020 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dd22H-000508-0y
	for submit <at> debbugs.gnu.org; Wed, 02 Aug 2017 18:22:37 -0400
Received: from userp1040.oracle.com ([156.151.31.81]:35355)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1dd22E-0004zu-WC
 for 27896 <at> debbugs.gnu.org; Wed, 02 Aug 2017 18:22:35 -0400
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71])
 by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id
 v72MMSXG029556
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <27896 <at> debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:29 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v72MMSeh013377
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <27896 <at> debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:28 GMT
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 v72MMR0W028416
 for <27896 <at> debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:28 GMT
MIME-Version: 1.0
Message-ID: <cf0b64a5-dab3-4a71-b49b-fd9b20e77b41@default>
Date: Wed, 2 Aug 2017 15:22:26 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: 27896 <at> debbugs.gnu.org
Subject: RE: bug#27896: 25.2; `C-M-%' with `rectangle-mark-mode'
References: <8b30a5cc-24db-4bca-94bd-50c79e65b43a@default>
In-Reply-To: <8b30a5cc-24db-4bca-94bd-50c79e65b43a@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 12.0.6770.5000 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Source-IP: userv0021.oracle.com [156.151.31.71]
X-Spam-Score: -5.1 (-----)
X-Debbugs-Envelope-To: 27896
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.1 (-----)

Clearly the current design of using a rectangular region to
limit replacing does not limit search for the replacement
commands in the same sense that the (normal) region limits
search.

The (normal) region limits the text that replacement search
tries to match, by bounding it.  The rectangular region keeps
the ordinary region as the domain of text that search tries
to match, and it filters the matches against that domain to
remove any matches that are not wholly within the limits of
the rectangle.

That's the design, and it's OK.  But it is misleading in
that we don't distinguish the two "region" behaviors.  It is
all too easy to expect that the rectangular region bounds
search in the same way that the ordinary region does.

To provide a different design, where the rectangular region
really limits the domain of text that we try to search,
would require some work.  It's OK that we stick to what we
have, at least for now, since it is anyway useful.

But I do think that users should be told what to expect (e.g.,
wrt regexp searching, in particular).  Currently there seems
to be NO doc about replacement over the rectangular region.

The code for this feature seems to have been added without
also providing doc and, as bug #27897 points out, it was
apparently only half-added.  Arg REGION-NONCONTIGUOUS-P
should also be added to other replacement commands, such as
`replace-string', `replace-regexp', `query-replace-regexp-eval',
and `map-query-replace-regexp'.  They too can benefit from
the new feature, and adding support for it is trivial (add
the optional arg and pass it to `perform-replace').

Please consider this bug report (#27896) to be a request
to add doc (in the Emacs manual) about replacing text over
a rectangular region.  That doc would be a good place to
point out that the rectangle limits do not limit the area
where searching is tried; they just provide post-matching
filtering to remove any matches that are not (wholly)
within the rectangle.

I think it's important to make this clear to users.  This
info should perhaps also be added to the doc strings of
the relevant commands.  (That's especially true if you
decide not to document this feature in the Emacs manual.)

> I think a user would expect the rectangle to define
> the region of possible query-replacing, not just define a clipping area
> from the full region of searching.  IOW, I think a user would expect the
> rectangular limits to be established first, and then searching to be
> limited to that rectangular space.
>=20
> If nothing else, if this is the intended design then I think the doc
> should be clear about it.  It should say, in that case, that matches are
> sought throughout the full, non-rectangular region, and only those
> matches that are wholly (?) within the rectangle are then retained as
> possible matches.
>=20
> My guess of what's happening is supported by this: If you do the same
> thing (same region) but without using `rectangle-mark-mode' then you see
> that rectangle mark mode just retains the matches for the normal,
> non-rectangular region, that are wholly within the rectangle.
>=20
> Here are the matches for the normal, non-rectangular region:
>=20
> ;; This buffer is for text that is not saved, and for Lisp evaluation.
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ;; To create a file, visit it with C-x C-f and enter text in its buffer.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ;; This buffer is for text that is not saved, and for Lisp evaluation.
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ;; To create a file, visit it with C-x C-f and enter text in its buffer.
>         ^^^
>=20
> This should be documented, as it is not, I think, what someone expects
> by searching a rectangular region (a region delimited by a rectangle).
> I think someone would expect that the search domain is limited by the
> rectangle, and then query-replace applies to matches within that domain.
>=20
> That's very different from the current behavior, which is to leave the
> search domain as the full region (undelimited by the rectangle) and then
> filter out (remove) any matches from that that are not wholly within the
> rectangle.
>=20
>=20
>=20
> In GNU Emacs 25.2.1 (x86_64-w64-mingw32)
>  of 2017-04-24 built on LAPHROAIG
> Windowing system distributor 'Microsoft Corp.', version 6.1.7601
> Configured using:
>  'configure --without-dbus --without-compress-install 'CFLAGS=3D-O2
>  -static -g3''
>=20
>=20
>=20




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#27896; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 1 Aug 2017 04:17:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 01 00:17:36 2017
Received: from localhost ([127.0.0.1]:35975 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dcOch-0007gc-Le
	for submit <at> debbugs.gnu.org; Tue, 01 Aug 2017 00:17:35 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42074)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1dcOcf-0007gN-Fi
 for submit <at> debbugs.gnu.org; Tue, 01 Aug 2017 00:17:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <drew.adams@HIDDEN>) id 1dcOcZ-0001eo-7W
 for submit <at> debbugs.gnu.org; Tue, 01 Aug 2017 00:17:28 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:34590)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <drew.adams@HIDDEN>)
 id 1dcOcZ-0001ek-3x
 for submit <at> debbugs.gnu.org; Tue, 01 Aug 2017 00:17:27 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33039)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <drew.adams@HIDDEN>) id 1dcOcX-00077d-VD
 for bug-gnu-emacs@HIDDEN; Tue, 01 Aug 2017 00:17:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <drew.adams@HIDDEN>) id 1dcOcT-0001di-UC
 for bug-gnu-emacs@HIDDEN; Tue, 01 Aug 2017 00:17:25 -0400
Received: from userp1040.oracle.com ([156.151.31.81]:44452)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <drew.adams@HIDDEN>)
 id 1dcOcT-0001cG-Jx
 for bug-gnu-emacs@HIDDEN; Tue, 01 Aug 2017 00:17:21 -0400
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233])
 by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id
 v714HHNo015012
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <bug-gnu-emacs@HIDDEN>; Tue, 1 Aug 2017 04:17:18 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v714HHdt015736
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK)
 for <bug-gnu-emacs@HIDDEN>; Tue, 1 Aug 2017 04:17:17 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
 by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v714HGfJ022705
 for <bug-gnu-emacs@HIDDEN>; Tue, 1 Aug 2017 04:17:17 GMT
MIME-Version: 1.0
Message-ID: <8b30a5cc-24db-4bca-94bd-50c79e65b43a@default>
Date: Mon, 31 Jul 2017 21:17:15 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 25.2; `C-M-%' with `rectangle-mark-mode'
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 12.0.6770.5000 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
 [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

emacs -Q

In *scratch*:

1. Duplicate the two lines of text, to get this:

;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.
;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.

2. Activate the region from before the `T' in the first `This' to after
   the `f' in the second `file', with point before the `T'.  Then `M-x
   rectangle-mark-mode'.

3. `C-M-%' and type `e.*t' for the regexp and `AA' for the replacement
   text.

I was expecting both occurrences of "eat" (inside "create") to be
candidates for replacement, since they are both within the rectangle and
they both match the regexp - but only the second occurrence is a
candidate for replacement.

(If you use regexp `e.t' instead, there is no such error.)

It seems that what is happening is that the regexp is being checked
against the full region, i.e., before the region is limited to the
rectangular portion.

Is that the design?  I think a user would expect the rectangle to define
the region of possible query-replacing, not just define a clipping area
from the full region of searching.  IOW, I think a user would expect the
rectangular limits to be established first, and then searching to be
limited to that rectangular space.

If nothing else, if this is the intended design then I think the doc
should be clear about it.  It should say, in that case, that matches are
sought throughout the full, non-rectangular region, and only those
matches that are wholly (?) within the rectangle are then retained as
possible matches.

My guess of what's happening is supported by this: If you do the same
thing (same region) but without using `rectangle-mark-mode' then you see
that rectangle mark mode just retains the matches for the normal,
non-rectangular region, that are wholly within the rectangle.

Here are the matches for the normal, non-rectangular region:

;; This buffer is for text that is not saved, and for Lisp evaluation.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
;; To create a file, visit it with C-x C-f and enter text in its buffer.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
;; This buffer is for text that is not saved, and for Lisp evaluation.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
;; To create a file, visit it with C-x C-f and enter text in its buffer.
        ^^^

This should be documented, as it is not, I think, what someone expects
by searching a rectangular region (a region delimited by a rectangle).
I think someone would expect that the search domain is limited by the
rectangle, and then query-replace applies to matches within that domain.

That's very different from the current behavior, which is to leave the
search domain as the full region (undelimited by the rectangle) and then
filter out (remove) any matches from that that are not wholly within the
rectangle.



In GNU Emacs 25.2.1 (x86_64-w64-mingw32)
 of 2017-04-24 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=3D-O2
 -static -g3''




Acknowledgement sent to Drew Adams <drew.adams@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#27896; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Wed, 2 Aug 2017 22:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.