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.devel Subject: RE: [External] : Re: [WIP PATCH] Controlling Isearch from the minibuffer Date: Tue, 11 May 2021 15:34:39 +0000 Message-ID: References: <87zgx5cz33.fsf@gmail.com> <878s4n4wn8.fsf@gmail.com> <87y2clve4m.fsf@gmail.com> 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="10414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Augusto Stoffel , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 11 17:36:19 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lgUQk-0002Wp-BR for ged-emacs-devel@m.gmane-mx.org; Tue, 11 May 2021 17:36:18 +0200 Original-Received: from localhost ([::1]:36570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lgUQj-0004b6-Dm for ged-emacs-devel@m.gmane-mx.org; Tue, 11 May 2021 11:36:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgUPM-0001i0-Ca for emacs-devel@gnu.org; Tue, 11 May 2021 11:34:52 -0400 Original-Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:23600) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lgUPG-0008KH-CG for emacs-devel@gnu.org; Tue, 11 May 2021 11:34:52 -0400 Original-Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14BFI4pK025960; Tue, 11 May 2021 15:34:43 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=1B+UR2zhX+cx7sZZv2U3TwJdS7cY5liEGVIu6TJo1F4=; b=Rj5YyzQUn4/nVkBaa/Jxf2Y3G+0W20uZ5vm5ucmUZUCXyuNBhn6uHLhFrt7xGPXbH0Cg w4DO3AJoJNMc6b8aCnvp/otA5PFbP/huOt3eoH/1d3kemr1d3q39GWwjsPNLIgdRLb7o unOIF3m8KJ7CPbVHSJJzUOC2qNy6y7bW98jCvaoHHd6hHtYOceirrYYhi2fi+al9YdKu itGnpV87W56mruK5JCDWYVvx3pmOUTRbPApxIk3FdxZ0pndOrbR7TiynPisgAfivTWlF 7IOsNwbEC693b43CfsR/ZyukcaJ87DRWWVc3x2pb0mQr8+RSVXvsCtndaY22qsHHSzgb Aw== Original-Received: from oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 38f5a60at5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 May 2021 15:34:42 +0000 Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [127.0.0.1]) by pps.podrdrct (8.16.0.36/8.16.0.36) with SMTP id 14BFUH3T064338; Tue, 11 May 2021 15:34:41 GMT Original-Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2049.outbound.protection.outlook.com [104.47.74.49]) by aserp3030.oracle.com with ESMTP id 38e5pxfb7b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 May 2021 15:34:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uk9C5LN4sr4fDP/hBZdcsU5lNL9XP6BZ6BYyydvbcOP4JwJavBJDr2riHzze5LCGJsy+as57NpwaRm0yoaUKkTYrNKvPYrYGtQ9cN15hEtQQaoajhoG8GskCI3bAEeLy24ZThVdR9TmqbWXt7O4ycjstPmw49pbNskoxmaLkwuyz+peY+0WRI+h/Zma4W1LLsnh1PWAP7i2oyu/rHGT1ap1CsRH2dIDzvXyb0jhoGox/b2OHX/E2Tg90d4bAyXsjyMSMQObkvyAb+3j483Jf7PiSeEDaHFk7wJkp6Jlw6qEBrnvBT4aNd+8Z74AtUbnGez214nsNMR8+q9Q7Ojvsug== 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=1B+UR2zhX+cx7sZZv2U3TwJdS7cY5liEGVIu6TJo1F4=; b=aWrnv38Oid2kPRcQXgH1H2u48uQDDzI1zWzpTj2/nG7oav82BPfcujZ8ysvM0rHDXiPbbmKb+xDOX2rwI3aaiYZo6ddPzv+9y39Ltb1R/DpFsgXs1jodX90Fpzo8MfPSzWvqgLDYLsb6KfYFNxP3I27yey3YIPJ76XDaLfEf/CYRpsWhn3NjXAFLzT7AOVsZ1xTwUDVPtv60OjrRbIYhdVaDaEAA3gXKDETbckfzNyoIqhxlOUcXzQPgxuPS7BZAkUm0tmvTr6MFpxc8FqeteAQKJA8mV+an0MKHCpQyqLZLg3+Btt/xy8r+1R1AGTFX1AnX7w+FyveQXp4Nn4aQFQ== 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=1B+UR2zhX+cx7sZZv2U3TwJdS7cY5liEGVIu6TJo1F4=; b=z+4CCpq7jmz2MeZqpqXobnQW0hFCukeUU5FMKqd+GqlyQjMHVSR704MSYTq6cGWERVHUX1hCnruAnIV/2IbuR2npaIHGRgKjykEvwjl+3tZe/tUIqxqN2MA9M+Cp8erFPsgaCNvxEKzVKbl8RtNszWNXKY6zKoGd1/fvvvZsc/U= Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB3007.namprd10.prod.outlook.com (2603:10b6:805:d9::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24; Tue, 11 May 2021 15:34:39 +0000 Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::2109:9725:fd4a:6494]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::2109:9725:fd4a:6494%6]) with mapi id 15.20.4087.049; Tue, 11 May 2021 15:34:39 +0000 Thread-Topic: [External] : Re: [WIP PATCH] Controlling Isearch from the minibuffer Thread-Index: AQHXRkeX3cxpvtG6akSYxhj0yfemQareUwFw In-Reply-To: <87y2clve4m.fsf@gmail.com> Accept-Language: en-US Content-Language: en-US authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; 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: ce063cf1-aff2-4229-9bb5-08d914924a63 x-ms-traffictypediagnostic: SN6PR10MB3007: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8zxZziVrXYIn92UHnHZZWyEw0AItG4lDUaGyCvjnxXqLoXJM2MCJxF2MN5HWNotNF7AUebLQKgxnHoOJ4tZm9H7LCtbkit6G0YLTW/08tMqmwpzaAD2+X+cBKAgSmlLFZlTgZJhO070t7C9ve8h87kRHpI2G5Pps7A4gJo6gqy0d9jVep1+ZIusq8sh1ls95ROIiyZh7NQ1BehIVHAgvgN9Enl3dKfKNQoQXTSOwmxazMOGKDP8limjSuoak7GK8mp3P8ueuOt23tdATGMC/uL9Nr/WZDqI7XrJtDs26lQLej4xMcmwVtFeZ6dFYOmxoWgkFet3pbxyjITtOYrugbIvQuKEL6BsXcQxf5dlmG/gv1VcQhHo1Nvk2aveoUUI0PBbLagEtBc/pjELKYHqdscFmOJh44OUT+tgblBJkDraz9oIrENakfuUK/CWjI88HgZW/ChQswZoU8VJyA8n6Xp9FBqXzqvvc8Qw+LdKmQc5hoSlSCy8ua7/Ha55aG2h6VghB5iAgLEmHftXDNwmsAPIEvGSS9NMiDCnhZDzqBXvdBzzQRW5lVNpNrjeDIJqqVnutEhZQcNfimVRCQu7U7t5ZPjNRS8e3SRLAL6E+wV5Xa4Lv2DdwXU4O8d9y7FSzAt63AEA8KK7bKpsRott6/OBZTSEfmvxTIptkpAHCBpg5i/BHDrYzguIct3sd8oKs 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:(346002)(136003)(366004)(376002)(396003)(39860400002)(8676002)(2906002)(966005)(5660300002)(9686003)(33656002)(38100700002)(44832011)(71200400001)(4326008)(7696005)(66946007)(478600001)(55016002)(6506007)(122000001)(86362001)(66556008)(26005)(52536014)(316002)(66476007)(64756008)(66446008)(76116006)(83380400001)(110136005)(8936002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?P5J77Ipc5b6w+2zianb3mYbr/QMtT3N9gDs6AmvKYk86lONZY/dwWIKZtDBZ?= =?us-ascii?Q?N/8789TYpExm0uCsX4WPOTQd82UhWsJro/Hl+0ekKCedD3wIM9C64UxohxxX?= =?us-ascii?Q?bvQeDzDkFlvB1MWua4fj2Fd0ybzi7GapTYVuJJjSaMHwumD+HQyqabXMSsDK?= =?us-ascii?Q?NxPPKWFZ7gqqM2Hn/FXawWP4FPn6tkSop91TXKhooyaTmqgCUOzKXB7B0i5v?= =?us-ascii?Q?WN3h0V7SRYQPfqQzvgTVspuDkB2m786fvJ00lbI/7Nfo0RuP8S/CCGUs/Wfu?= =?us-ascii?Q?UvesGJ6Ruwe6P+f1/W3BAs5Fvbw9u1P7Xq8OuFtuvyx324hA1X3e8tEf+0VQ?= =?us-ascii?Q?jwV9wH4ZbMhJqLTRHMr+/h/p9c7WmM51KaK3y0Umut/Q0JnMQJDw/OgjpJBw?= =?us-ascii?Q?ca05ce9Ya9V3Y/zxMz2YRnW9XbqbFTQvLb/P1w2+4nqRxlCbYxmTOncecmdu?= =?us-ascii?Q?L4DRsZLQl6Y680BEMrPlGbc0gZtkVvjxbv66hgeeeF7OE2BxzyQohnsYn8Ps?= =?us-ascii?Q?uSykAbKDJxeabkHremkRuWx6vPq4ToebfWoGz2QXX7L6h23QnNRtaINPa4jS?= =?us-ascii?Q?j1DnqlwqDGtbZuLKddAXFH3kOTLGFvgIHF3/ZoIamzmx5KpIzO5+RlsjR/Su?= =?us-ascii?Q?6Uhg 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: ce063cf1-aff2-4229-9bb5-08d914924a63 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2021 15:34:39.4442 (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: cIqaz1R6cJ/IDpAbHR3uVt10EqVff2BaEZvhcCzRLaaDhJ1oBa5h3HL4Nh6tji0DfgOzurrtpXAwBRXVHuuhmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB3007 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9981 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 spamscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105110112 X-Proofpoint-ORIG-GUID: zuJowzazM1QxiQBS1pJiedLg2QGc3RYS X-Proofpoint-GUID: zuJowzazM1QxiQBS1pJiedLg2QGc3RYS Received-SPF: pass client-ip=205.220.165.32; envelope-from=drew.adams@oracle.com; helo=mx0a-00069f02.pphosted.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:269162 Archived-At: > The question is whether it makes sense to provide an > alternative UI for Isearch where editing the search > string is not a special maneuver. Really? Is that what this is all about? Just what is the giant inconvenience you find with Isearch's `M-e' for editing the search string? Not to mention that you can always edit it directly, by deleting chars from the end. But let's suppose you really feel that using `M-e' edit the search pattern using the minibuffer is too constraining/difficult/cumbersome (choose whatever adjective you like). Here's another alternative you might consider, which doesn't throw out the adorable baby with the claimed dirty bathwater. It's offered by `isearch+.el' via option `isearchp-initiate-edit-commands': ,---- | isearchp-initiate-edit-commands is a variable defined in `isearch+.el'. |=20 | Its value is=20 | (backward-char left-char backward-sexp backward-word left-word) |=20 | Documentation: | Commands whose key bindings initiate Isearch edit. | When invoked by a key sequence, Isearch edits the search string, | applying the command to it immediately. |=20 | Commands you might want to include here are typically commands that | move point to the left, possibly deleting text along the way. |=20 | Set this to `nil' if you always want all such commands to exit Isearch | and act on the buffer text. |=20 | You can customize this variable. `---- By default, for example, `backward-sexp' (e.g. `C-M-b') initiates editing the search pattern (yes, using the minibuffer), moving point backward a sexp from the end. That doesn't throw out the baby. It's on-demand only. It's like `M-e', but it also positions point within the search pattern to be edited. Remove all commands from the option list and you get vanilla Emacs Isearch behavior: only `M-e' initiates using the minibuffer to edit the search pattern. And we already have `M-e' automatically putting point at the position in the search pattern where matching fails. (Also something from Isearch+, BTW.) > This includes DEL doing what it does everywhere else,=20 "Everywhere else" means what? DEL in Emacs has no "everywhere else". It does one thing in Info, another in an editing mode. Just as important: Why is it important for DEL to do "what it does everywhere" - or ANYwhere - else? > The minibuffer starts a recursive edit. There may be > ways to simplify my patch, but functions which always > return locally won't cut it. Another feature of Isearch+: `C-x o' (`isearchp-open-recursive-edit') opens a recursive editing session, where you can do anything you like (including search for something different). Using `C-M-c' closes the recursive editing session and resumes the search (from the current position where you hit `C-M-c'). Doc string: Invoke the editor command loop recursively, during Isearch. Use `C-M-c' to end the recursive edit and resume searching from there. Or use `C-]' to exit the recursive edit and cancel the previous search. That one was suggested by Juri, BTW, who said, "Executing any code in the macro's body will also allow doing more amazing things like temporarily going into a recursive edit." https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00281.html And `C-y C-M-c' adds text to the search pattern, from point to wherever you go to in a recursive edit. (Command `isearchp-yank-through-rec-edit-move'.) `C-y C-M-k' acts similarly, but adds the text from point to wherever a key moves. (`isearchp-yank-through-key-move'.) `C-y C-M-m' adds text from point through a match for another search pattern, for which you're prompted. `C-y C-M-z' adds text from point to the next occurrence of a character, for which you're prompted. Those are all ways to "edit" the search pattern, and two of them make use of recursive editing. Still, the baby wasn't tossed - no need to. > The patch is about making it easier to edit the search string. Just what's the difficulty? That info seems to be missing. We've seen a solution proposed, but what problem does it want to solve? (Please don't answer by just saying that the search pattern is too hard to edit.) > > Why use the minibuffer at all? >=20 > So that it's natural to edit the search string during a search. What's unnatural about using `M-e' to use the minibuffer to edit the search pattern during a search? Saying something is "natural" or more so, and that it makes it easier to do something else, is vague. What's the actual difficulty that you think making Isearch always use the minibuffer eases? If the problem is editing the search pattern, and you want to be able to use the minibuffer for that, then we already have/do that. Why make Isearch use the minibuffer all the time, for everything, if the goal is to just to let it use the minibuffer to edit the search pattern? > > Probably. But, again, what has using the minibuffer > > got to do with the keybindings a user prefers? >=20 > As stated in the original message, this feature > is all about editing the search string. We already use the minibuffer to do that. > Having the same keybindings as everywhere is else See above, about DEL - define "everywhere else". I'm guessing you mean outside Emacs, perhaps? In Emacs there is no such "everywhere". Keys can do different things in different contexts. > might be seen as a beneficial side effect by some > people, but is incidental. It's hard to tell what you think is incidental and what you think is essential to change. But it seems like the actual changes you propose are far-reaching. For 40 years Isearch has won the world by NOT using the minibuffer (except for one-off, on-demand pattern editing). Zillions of search UIs have adopted the incremental searching that Isearch pioneered. (The "i" in "isearch" is for "incremental".) Why, in 2021, would we suddenly want cram all of Isearch into using the minibuffer? What's the real problem you're trying to solve? Is it really to be able to have keys like DEL do what you're used to them doing outside Emacs? To be clear, I'm generally in _favor_ of providing "alternatives" for Emacs users. But though this was pitched as just adding an "alternative" behavior, the code changes seem deep and wide-ranging, and IIUC, there was even talk of the "alternative" arrangement being just temporary, i.e., that Isearch would eventually always follow your "alternative" implementation and behavior. Why so?