From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams 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: 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: 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 ) 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 ) 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 ) 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 ) 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 ) 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 ) 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 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Aug 2017 22:23:02 +0000 Resent-Message-ID: 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 ) 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 ) 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:135256 Archived-At: 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