From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Drew Adams <drew.adams@oracle.com>
Newsgroups: gmane.emacs.bugs
Subject: bug#27896: 25.2; `C-M-%' with `rectangle-mark-mode'
Date: Wed, 2 Aug 2017 15:22:26 -0700 (PDT)
Message-ID: <cf0b64a5-dab3-4a71-b49b-fd9b20e77b41@default>
References: <8b30a5cc-24db-4bca-94bd-50c79e65b43a@default>
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Trace: blaine.gmane.org 1501712595 7645 195.159.176.226 (2 Aug 2017 22:23:15 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Wed, 2 Aug 2017 22:23:15 +0000 (UTC)
To: 27896@debbugs.gnu.org
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 03 00:23:10 2017
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1dd22n-0001ek-Ma
	for geb-bug-gnu-emacs@m.gmane.org; Thu, 03 Aug 2017 00:23:09 +0200
Original-Received: from localhost ([::1]:50777 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1dd22s-0002Hy-2v
	for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Aug 2017 18:23:14 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59021)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dd22k-0002Hi-Vt
	for bug-gnu-emacs@gnu.org; Wed, 02 Aug 2017 18:23:08 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dd22g-0001xr-TK
	for bug-gnu-emacs@gnu.org; Wed, 02 Aug 2017 18:23:06 -0400
Original-Received: from debbugs.gnu.org ([208.118.235.43]:36343)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
	id 1dd22g-0001xk-Op
	for bug-gnu-emacs@gnu.org; Wed, 02 Aug 2017 18:23:02 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1dd22g-000513-Fq
	for bug-gnu-emacs@gnu.org; Wed, 02 Aug 2017 18:23:02 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Drew Adams <drew.adams@oracle.com>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Wed, 02 Aug 2017 22:23:02 +0000
Resent-Message-ID: <handler.27896.B27896.150171255719232@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 27896
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
Original-Received: via spool by 27896-submit@debbugs.gnu.org id=B27896.150171255719232
	(code B ref 27896); Wed, 02 Aug 2017 22:23:02 +0000
Original-Received: (at 27896) by debbugs.gnu.org; 2 Aug 2017 22:22:37 +0000
Original-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@debbugs.gnu.org>)
	id 1dd22H-000508-0y
	for submit@debbugs.gnu.org; Wed, 02 Aug 2017 18:22:37 -0400
Original-Received: from userp1040.oracle.com ([156.151.31.81]:35355)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <drew.adams@oracle.com>) id 1dd22E-0004zu-WC
	for 27896@debbugs.gnu.org; Wed, 02 Aug 2017 18:22:35 -0400
Original-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@debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:29 GMT
Original-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@debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:28 GMT
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 v72MMR0W028416
	for <27896@debbugs.gnu.org>; Wed, 2 Aug 2017 22:22:28 GMT
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)]
X-Source-IP: userv0021.oracle.com [156.151.31.71]
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: 208.118.235.43
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
	the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-gnu-emacs/>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: "bug-gnu-emacs"
	<bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.bugs:135256
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/135256>

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