From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#27896: [External] : Re: bug#27896: 25.2; `C-M-%' with `rectangle-mark-mode' Date: Fri, 5 Feb 2021 16:19:06 +0000 Message-ID: References: <8b30a5cc-24db-4bca-94bd-50c79e65b43a@default> <87pn1eiv4m.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24905"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "27896@debbugs.gnu.org" <27896@debbugs.gnu.org>, Juri Linkov To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 05 17:20:15 2021 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 1l83qB-0006Pk-J1 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 17:20:15 +0100 Original-Received: from localhost ([::1]:39296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l83qA-0002du-Iy for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Feb 2021 11:20:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36494) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l83py-0002cp-PS for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 11:20:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33023) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l83py-0003V5-FP for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 11:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l83py-0006FC-Az for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2021 11:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2021 16:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27896 X-GNU-PR-Package: emacs Original-Received: via spool by 27896-submit@debbugs.gnu.org id=B27896.161254196023939 (code B ref 27896); Fri, 05 Feb 2021 16:20:02 +0000 Original-Received: (at 27896) by debbugs.gnu.org; 5 Feb 2021 16:19:20 +0000 Original-Received: from localhost ([127.0.0.1]:44569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l83pH-0006E3-OK for submit@debbugs.gnu.org; Fri, 05 Feb 2021 11:19:20 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:35978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l83pE-0006Do-Uz for 27896@debbugs.gnu.org; Fri, 05 Feb 2021 11:19:18 -0500 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 115GFj9G057328; Fri, 5 Feb 2021 16:19:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=MwazYiHXlz9rAsT6A5tWBF6X0K6IvUYa850cwCFNnxo=; b=tY2t0xsUbPo0mSfc3QWYqb6lWK9AtHpjQtRv2TAeN6fRMo08cne9US0HzhL3aYkgLEPU 8aV1vnmvFsqugecKnmO5kkiJxdS2CdKyE3IMjqqLAVMUbnKjrr5yZ1U+h89vVhA2F20N FwaYkr2Z+g20JdHiXZNfSi/zuziku5afBl7HblYYYnU82NGVslqRic0/mfvGSKeynryq wLWiYgpMGqKahyqK2ad+IPSGyIcJP+CwH1iuYtq+AQyMdWskH96VqnkOlu6q0zO9q910 kw+IUPNFdAcxOQg/rHD3fjOb4SreqSbOTK75mq6Wafr1twttWPlDJKLwvtLWsHOCLfju Rw== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 36gfw8tccq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Feb 2021 16:19:09 +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 115GFAFW041217; Fri, 5 Feb 2021 16:19:09 GMT Original-Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2108.outbound.protection.outlook.com [104.47.55.108]) by aserp3020.oracle.com with ESMTP id 36dhc4cd25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Feb 2021 16:19:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A0LeBcs5aKbePMvhSrgiRh9TKDSt+x5lseH8u83GF+AS2cuhrWl1RC8V3olUP/U/pbPJRUF+zY5Cm8mWVOagiY33NyBKcer4+PkF4780qyBcPi1Hq6wNo7xHGrAOPuGLgwBIYI8WLHhr4bB+cPr0MQBDpVLId6XFkcD3t0BH7wraH6Absr7eAPwv3ELHP2ngQ0oP52wWZZBnJr6kHcmDLrewCW4Apo5L1LCbstljyfr39nYB0ohI/b5gbfWJhvcLYfSQKE4CS7omOJlqVwar+Ss2m/iMYakcdU9wIEtc442gjsCV8FME/xAARp8bLTEw+oi45+ZLD4r1cdSc7mKCmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MwazYiHXlz9rAsT6A5tWBF6X0K6IvUYa850cwCFNnxo=; b=fKucd+Cx3wAOj/w0fkHlgVMHdmSQHMpiqbymmqncDE2nB0+KVti48ZoemL08RcYXuv31QpuGBvG1mNDMgmOVtWntS7PROCWStuDntZKIDThjJKEHgs5TAnszKGxL+eGAEdopPry5XWWc3W+QnHUnMdv64++xut2A3BdYgqpUMH7OE0Oi+5bhGsBGjbappaLVs8CIBIlzXMC+zK4jMzTtm2UwrIrAwY7JpeFS8CKpI6AfmP1GaGMCVANYVHvEC6emOXkRn53BwAFaX0SWWTsfsYYTb/bRt11+0q0q+WNTAu0aTAQIPMNH9rMcZpbSrmW1a2LdA9Qxl5203O8Ah/f3vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MwazYiHXlz9rAsT6A5tWBF6X0K6IvUYa850cwCFNnxo=; b=D7w3jwsgLkcBF8nIAwA81Y4H/3EE4qoYqHXZt8qZExwEKerlDMC/4cDdGx6D3xC0AOiSJ5iaPK6yIk++bCRfEEucAlNNSiHyUpfPSKwA5cSs7Hvv4Jf/euND7n9gQKbV5MAwz9KMnYaxsjf/fIDGAvgTFsLvNmb6Fr4xPAMag3c= Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB3005.namprd10.prod.outlook.com (2603:10b6:805:cc::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.17; Fri, 5 Feb 2021 16:19:06 +0000 Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::dc4d:9cd0:2010:daa2]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::dc4d:9cd0:2010:daa2%7]) with mapi id 15.20.3825.024; Fri, 5 Feb 2021 16:19:06 +0000 Thread-Topic: [External] : Re: bug#27896: 25.2; `C-M-%' with `rectangle-mark-mode' Thread-Index: AQHW+7ZDPOF1Jhpkz0WI2q7xPv6jNqpJsNLA In-Reply-To: <87pn1eiv4m.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US authentication-results: gnus.org; dkim=none (message not signed) header.d=none;gnus.org; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: af89d3d8-f296-4619-cdac-08d8c9f1c2b2 x-ms-traffictypediagnostic: SN6PR10MB3005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q0bsah6jFDMwSNdhmbXLDIqMWsq2m0ftaYZ4bvFsAom5PCpXiQVSIUrsu7UQj2D4ni49wN+ntVEP43SEgbFCc2d+WPMKof2qUSxDysBNWZEp/aUAB4wdd9MV1umW/Pw4WG/mbuQkAMxbdPEJTLUZ+Mjmb97xYVMKtP2+iIPqKg7gEhPFIR2tOeOla4D5tNCSI3ggYX83SOibTJ4qUp2HUhCFeja2jZPlYbAyYNhEat7wZo66vqc+9Nb2pG580rz/WvizMbaJAJj+LLxdClJ0r48KYbubLf7MoxRwokyaAfTeYGeA6wgn2SXZwU55BtLWc60K/Aet3JdIK4610KPkkZPZWWT/siwlCop2czVVbGuzNWD+f65IZVUc2pPe7WkpME83ETFN9BN4y+TM30id8u4nQ7Sn6iqsS5EdTvinCCYNRLkMt97YD3ol5hfzARY+88t8kuN6dle0dO45SQJhOj5Sd0bl08uhxa0NM7OZXAuIABXAwO4Sh1/IIlgIWBxYI8Qp9VSufFWJ7OGPRLELYI7//Tj4TmcWLjLoNBaaGARhEDA1UfU3CZ9FgLaG7l0W x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(136003)(366004)(39860400002)(76116006)(66556008)(6916009)(6506007)(26005)(64756008)(66946007)(8936002)(2906002)(4326008)(83380400001)(66446008)(55016002)(186003)(8676002)(316002)(9686003)(44832011)(52536014)(5660300002)(86362001)(54906003)(33656002)(478600001)(71200400001)(7696005)(66476007)(81973001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9ihJQ4l/aWO916k++lOBzG9laMLUGL0bmzNpFoYfK8vzvPBxzaFPrbQUwlYJf9XOMGF/xr2a3715oytqtIUW4fs1P8MjSJmucS2qPtJoSsqKYGqfB6lcAp/ZGlY7iMezvWYjCDFiu3BJqmp2z0T/u9TSifzPso/poNzoTqUYBgKwNkcjqp5GcFQGBSNPWcC+bueYaMCIPdAR5K6K5j+nnDK18L/cV2Q/2YfzpJnN4lsCNAnbGO72340TetN6ez8pFHod1HkHQqfFiPzG3Ynww9aAzl9d+ynOOomvcV52T67XyGzEhoo5JGKVDFCewZMbGdsrOdAIeJzWQ2Trwn4+rDgnoKjJQjLXGNHUoca6Ul/hpEW1JmKUm7oiNQ9wO3aTXtdYV8WvBINdetaljaTfB4F+Sey3Lk1f+U/c2HTPQYNTb1avBADxgC/e7fVp48sARKwtE9nEIJZmgQmP7VMo3kBSb8RKcTGVeKDDMWPVLGXqd6F7WH+AfwDjI8qQ17Y7Lpe+M2G3zDkEAZhSX+3DfWfEH3SVimJa6TVNwdiQNA5mxhntRS9Ps5ZthbTxBUoZ1Z3GYrysFyqfF5IZbK7KCGCjbGk3I9bBh9wkYdzdE/Y78lh2r2wBXd9drTvFFJGntjBnhM4+wrZ4xlTuB0uvh9KiG4c32muvCiPcfIwKTcZKfCfHw1IXL9XbMAf+jtLOjvuZNjpN/0XEU9Xm5rleAeg27FEQQUsFwPg6okZm120P+rp1sgkuq7D+zAuW Qe9bRB7Lc3p7yDmXK2rpI2RlsOhGjuEKqp9aDgNPwjgZd5ECJjung1dxXv2lGSzMiKTY1NdEroxdipNTEuwLjob7lhLT/jv/en x-ms-exchange-transport-forked: True X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: af89d3d8-f296-4619-cdac-08d8c9f1c2b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2021 16:19:06.3356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FB6UcoT2oznqvAxlfFiYnAX8hRbchLkBth41ZO55FZQS+YP+NMEwKsCF1yw8CSwXMC4mPtmjq/ROIW0k7e4u4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB3005 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050105 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 bulkscore=0 impostorscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050105 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:199394 Archived-At: Thanks for looking at this feature request. > > 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. >=20 > Yup. It's a pretty odd design decision, though -- > I wonder whether it this happened on purpose or > whether that was just the simplest way to implement this. I'm pretty sure it was done this way just because that's much simpler to do. Filtering is after the fact - after matching. And matching respects only the buffer restriction (`point-(min|max)'). In search+.el I make it possible (via an option) to actually limit search to the active region. That is, search matches cannot extend beyond the region limits. That feature required quite a few changes to the Isearch code, even if most of them were simple. (The general idea is to bind two vars for active region begin and end and respecting the option, and then replace calls to `point-(min|max)' by those vars. IOW, instead of limiting search to the buffer restriction, limit it to the region.) What this request is about amounts to doing something similar, but doing that with all of the begin and end bits of a noncontiguous region. I haven't yet had the time (or motivation) to do that in my code. I think it would greatly help Emacs to have such a feature, i.e., to truly treat the limits of each zone of a noncontiguous region as search limits. Now, a question arises as to whether, if we did have such a feature, it would _also_ be good to still have the behavior that we have now, i.e. still be able to have a filter work on matches for the full buffer, that is, to _not_ limit the search tries to the region. I'm guessing that it _would_ be good to conserve the current behavior, i.e., to have a variable that chooses which behavior to use. But I don't have a good idea of why I think both can be useful. One reason to keep (also) the current behavior might be backward compatibility, of course. But my gut whispers that there are other reasons. I haven't really thought about it much. > I've added Juri to the CCs; perhaps he can clarify. > (The problem is that if you ask to replace "foo.*bar", and you have > foo bar bar > then `query-replace' will match the entire line, and then filter out > that match (given that we have a rectangular region that covers just > "foo bar") and not replace anything.) It's more important than that. But yeah, that at least illustrates one difference. The point is this: the search boundaries are currently `point-min' and `point-max', which respect only narrowing. If you want to limit search to a region then you need to narrow to it. With isearch+.el you can have search respect the region limits without narrowing (so you can see the surrounding text while searching - you can even optionally dim that surrounding text). And in this case the region bounds act just like the buffer bounds: _matching_, itself, (not just filtering) is limited to the region text. Also with Isearch+ you can search a set of zones, i.e., a noncontiguous region (while showing or hiding the antizones). But in this case, the limits of those region pieces (zones) aren't used for matching; they're used only for filtering. IOW, with my code searching within zones has the same fault that vanilla Isearch has for searching within a region using a filter that restricts to the region: it _matches_ beyond what should be the search space, and _then it filters_ out any matches that extend beyond the search space. In a nutshell, the requested feature is to be able (but not be required) to not only _filter_ out matches that go beyond zone limits but also to not allow those matches in the first place. That is, _limit matching_ itself to be within such bounds. (Note: a noncontiguous region need not be rectangular. This feature would apply to any sequence of buffer zones.)