From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#70968: 29.2.50; choose-completion on an emacs22-style completion deletes text after point Date: Tue, 24 Sep 2024 03:03:41 +0300 Message-ID: <8479c25d-b4ae-4e89-9880-0857a996936a@gutov.dev> References: <86bk56jhsp.fsf@gnu.org> <377f815c-52d2-4770-ae85-55e096e104b0@gutov.dev> <8634qhipgj.fsf@gnu.org> <7e05fd14-3499-4811-b4bc-b53186b15408@gutov.dev> <86ed5vzzru.fsf@gnu.org> <86o74qh9wv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------7t27Q3YoMU4RBlQUWy7eA2kp" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37565"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 70968@debbugs.gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Spencer Baugh , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 24 02:05:06 2024 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 1sst3B-0009cT-Fo for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Sep 2024 02:05:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sst2o-0005B7-Ad; Mon, 23 Sep 2024 20:04:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sst2l-0005Ah-ER for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 20:04:39 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sst2k-0002xd-TL for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 20:04:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=UXpXRQTOqpxK185coOrj8SB0m55W/KirXSoVIsDpK1E=; b=URHQfdIYXbK3122lmHqbBXJG63vh+ZA4dx+rZIBi+E7duxhvrihEsQWZWBP/cazrYhCZdfj0vgVt47hVPcVr28IahcthwUWibX6J+ghCsZi+HxpZh7AEQ52wOZH2jYEn74yTksduQRoznxUrWY0MnsBe7OJgH5DjWxO0MBXuQ5c9vW/N8iGZaeUFTopccQBNRC7sGJFn+cJ4dWE97xRCe0qKiEkzqevflPxK70gVZ9PcHUcM+9io/Wcb+pclBVgoSB0+f3uWyuxufyyvHRyp/okcEtgqQ9wqW5LJ6mH11EiZ3fm4fgTazxK4NRDQ+AFo2/ogpqp99MFygaChL9FRKQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sst38-0007Sy-EU for bug-gnu-emacs@gnu.org; Mon, 23 Sep 2024 20:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Sep 2024 00:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70968 X-GNU-PR-Package: emacs Original-Received: via spool by 70968-submit@debbugs.gnu.org id=B70968.172713626028637 (code B ref 70968); Tue, 24 Sep 2024 00:05:02 +0000 Original-Received: (at 70968) by debbugs.gnu.org; 24 Sep 2024 00:04:20 +0000 Original-Received: from localhost ([127.0.0.1]:44942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sst2R-0007Rl-Dp for submit@debbugs.gnu.org; Mon, 23 Sep 2024 20:04:20 -0400 Original-Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]:43945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sst2O-0007RW-77 for 70968@debbugs.gnu.org; Mon, 23 Sep 2024 20:04:17 -0400 Original-Received: from phl-compute-12.internal (phl-compute-12.phl.internal [10.202.2.52]) by mailfhigh.phl.internal (Postfix) with ESMTP id B2466114028E; Mon, 23 Sep 2024 20:03:46 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Mon, 23 Sep 2024 20:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1727136226; x=1727222626; bh=UXpXRQTOqp xK185coOrj8SB0m55W/KirXSoVIsDpK1E=; b=AQr2guYcRlzbSSYn/UUkHxfkfl ZULtJFRfjSFI/UiZTOCGJv5Ip7qyQbOxe2KZW/FmCtpbUSuqem8emiuyTUZD2N4M RvoakWVKysvrcRM35BjQqu7UQsonLA4wkeb5SQaXoQ0+BheO1WDiaYvxvEThWXLs IHD4qJj6YaF+sFgnItBnvsB6HTl2pK53ZMcz8zEheirLm0l3kdG8+kAwcyZoqlAx iC3jTEmbQS8n1U+7xG/BinOKphU1/tBYUq43NEjpzcF3YaWC+6UAGWh+c9KP1yC/ kKGlrmKJzLbzIqHusDKa3jKz30NJyTLRAvZUPK3AOYv/a2wMF7hBrvI1QiTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1727136226; x=1727222626; bh=UXpXRQTOqpxK185coOrj8SB0m55W /KirXSoVIsDpK1E=; b=bGWW/0zdWCL1mDlyKUmelDIB9gxxqfMQEw89vB/wxaqP pRve1Kw2Z+2/igQQ1VQ6zfmJmc4+qQGa6XXhUPNlFMcXxFwwFY20bqmsWhAhkLpF imqq0jo4vHo3WQHtlTdLWZapqboVbBal6c/hs0IGLztxu1P1mGT0OPXVN8dzb20q 2KD9H1ad/WAuw98LVc/RCBxYb7xUTSvJBp4n/KMoPX0KRH9mMmm+h8/ocQjsVtUz 7yjD6M+tczfx3GEMsI6n2+7Mo0wwn9sL7O5J10mbrB4iexekw20IaotbIanyNo+Y fCoKWXKU8dFcgF8h7FqwZKvbz0t2OFVFqBEA3+mpeA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvddttddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeen ucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvg hvqeenucggtffrrghtthgvrhhnpeehleefudekudduveekieelgfeiffdvkefhkeeljeeu jeegueekveffkeejjeevheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohep hedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshgsrghughhhsehjrghnvghsth hrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthho peejtdelieekseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepmhhonhhnih gvrhesihhrohdruhhmohhnthhrvggrlhdrtggrpdhrtghpthhtohepjhhurhhisehlihhn khhovhdrnhgvth X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 23 Sep 2024 20:03:43 -0400 (EDT) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292299 Archived-At: This is a multi-part message in MIME format. --------------7t27Q3YoMU4RBlQUWy7eA2kp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Spencer, On 16/09/2024 22:54, Spencer Baugh wrote: > Eli Zaretskii writes: >> I'm okay with adding a new style, per B, but why do we need to >> deprecate emacs22 at the same time? Let users who want this new >> behavior customize their completion styles to use this new style >> instead of emacs22. That'd be fully backward compatible, and will >> solve the problem for those who don't like the current behavior. > > That's fair enough, we don't need to deprecate emacs22 at the same time, > we can wait until the new style has been battle-tested. > > I think a new style should replace emacs22 in the default > completion-styles eventually, but that can wait. > > And after working on this bug for a while, I now am convinced that the > new style approach is straightforward, and is the best way. (Although > it would also work to make these changes in the emacs22 style) I'm not quite convinced about the "new style only" approach myself, but anyway we can discuss a solution that could be applied to any style, opt-in or opt-out. > Attached is a patch which adds a new ignore-after-point style. The fix > for this bug is entirely contained in the differences between > completion-ignore-after-point-all-completions (c-iap-a-c) and > completion-emacs22-all-completions (c-e22-a-c). > > c-e22-a-c always omits the text after point, which means > choose-completion always deletes that text, causing this bug. > > c-iap-a-c includes the text after point in some cases. Whenever the > text after point is included, it's grayed out with a new > completions-ignored face to indicate it was ignored. > > The cases where c-iap-a-c includes the text after point are those where > the user will have further chances to edit or complete with that text: > > - When we're doing minibuffer completion and choose-completion will > immediately exit the minibuffer, the text after point is not included, > since the user won't get any further changes to use it, and it's > probably garbage. > > - When we're doing completion-at-point (or certain kinds of minibuffer > completion, e.g. completing a directory in filename completion), the > text after point is included. In such cases, the user can always > delete it themselves later, or might want to actually use it. > > To make this work consistently with completion-try-completion (which > keeps point before the ignored suffix in both the ignore-after-point and > emacs22 styles), choose-completion-string now checks a new > 'completion-position-after-insert text property, and moves point to that > position. > > (There are two other changes which are general improvements unrelated to > this bug: > > - The behavior of keeping point before the ignored suffix is more > consistent. > > - Instead of hardcoding try-completion and all-completion, > ignore-after-point uses the configured completion styles.) Thank you, I see a few problems with that approach (as discussed privately as well). To recap: From my POV integrating the result with company-mode is non-trivial. And the created visual doesn't seem optimal in a number of edge cases (long prefix = weird-looking popup; this probably applies to the *Completions* buffer as well, though maybe to a lesser extent). Another problem is both the "all-completions" method and the insertion function call out to UI: choose-completion-string--should-exit references minibuffer-completion-table and completion-no-auto-exit directly, for example. I'm on the fence about coupling to the completion category. Finally, the use of 'completion-position-after-insert' seems like it could be used separately from the "ignored text", meaning the spans don't have to match. So it could be a separate feature, one that's easy enough to implement on its own. None of the above would be insurmountable, but here's what I think avoids it using the 'completion--adjust-metadata' thingy that was originally added for 'flex' a few releases ago: adding a metadata key 'completion-ignore-after-point'. The attached patch does not make a distinction for file name completion - it just covers the core problem - but I think any UI could use the addition and likewise lookup the 'file' category, and print the "hidden" suffix in the Completions, and decide to drop the suffix in your first scenario (file name completion with exit imminent). Spencer, Stefan, WDYT? Again, the patch is against the emacs22 style for readability, but a new style can be added just as well. --------------7t27Q3YoMU4RBlQUWy7eA2kp Content-Type: text/x-patch; charset=UTF-8; name="completion-ignore-after-point-metadata.diff" Content-Disposition: attachment; filename="completion-ignore-after-point-metadata.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvbWluaWJ1ZmZlci5lbCBiL2xpc3AvbWluaWJ1ZmZlci5lbApp bmRleCA4MDRhZmU5Y2I0My4uNGFjMjMxMTcxYjYgMTAwNjQ0Ci0tLSBhL2xpc3AvbWluaWJ1 ZmZlci5lbAorKysgYi9saXNwL21pbmlidWZmZXIuZWwKQEAgLTI2MTMsNyArMjYxMyw2IEBA IG1pbmlidWZmZXItY29tcGxldGlvbi1oZWxwCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoYnVmZmVyLXN1YnN0cmluZyAocG9pbnQpIGVuZCkpKSkK ICAgICAgICAgICAgICAgICAocG9pbnQpKSkKICAgICAgICAgICAgICAoZmllbGQtY2hhciAo YW5kICg8IGZpZWxkLWVuZCBlbmQpIChjaGFyLWFmdGVyIGZpZWxkLWVuZCkpKQotICAgICAg ICAgICAgIChiYXNlLXBvc2l0aW9uIChsaXN0ICgrIHN0YXJ0IGJhc2Utc2l6ZSkgZmllbGQt ZW5kKSkKICAgICAgICAgICAgICAoYWxsLW1kIChjb21wbGV0aW9uLS1tZXRhZGF0YSAoYnVm ZmVyLXN1YnN0cmluZy1uby1wcm9wZXJ0aWVzCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHN0YXJ0IChwb2ludCkpCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYmFzZS1zaXplIG1kCkBAIC0yNjIzLDYgKzI2MjIs MTIgQEAgbWluaWJ1ZmZlci1jb21wbGV0aW9uLWhlbHAKICAgICAgICAgICAgICAoYWZmLWZ1 biAoY29tcGxldGlvbi1tZXRhZGF0YS1nZXQgYWxsLW1kICdhZmZpeGF0aW9uLWZ1bmN0aW9u KSkKICAgICAgICAgICAgICAoc29ydC1mdW4gKGNvbXBsZXRpb24tbWV0YWRhdGEtZ2V0IGFs bC1tZCAnZGlzcGxheS1zb3J0LWZ1bmN0aW9uKSkKICAgICAgICAgICAgICAoZ3JvdXAtZnVu IChjb21wbGV0aW9uLW1ldGFkYXRhLWdldCBhbGwtbWQgJ2dyb3VwLWZ1bmN0aW9uKSkKKyAg ICAgICAgICAgICAoaWdub3JlLWFmdGVyLXBvaW50IChjb21wbGV0aW9uLW1ldGFkYXRhLWdl dCBhbGwtbWQKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAnaWdub3JlLWFmdGVyLXBvaW50KSkKKyAgICAgICAgICAgICAoYmFz ZS1wb3NpdGlvbiAobGlzdCAoKyBzdGFydCBiYXNlLXNpemUpCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKGlmIGlnbm9yZS1hZnRlci1wb2ludAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAocG9pbnQpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBmaWVsZC1lbmQpKSkKICAgICAgICAgICAgICAobWFpbmJ1ZiAo Y3VycmVudC1idWZmZXIpKQogICAgICAgICAgICAgIDs7IElmIHRoZSAqQ29tcGxldGlvbnMq IGJ1ZmZlciBpcyBzaG93biBpbiBhIG5ldwogICAgICAgICAgICAgIDs7IHdpbmRvdywgbWFy ayBpdCBhcyBzb2Z0bHktZGVkaWNhdGVkLCBzbyBidXJ5LWJ1ZmZlciBpbgpAQCAtMzc3OCw2 ICszNzgzLDEzIEBAIGNvbXBsZXRpb24tZW1hY3MyMi1hbGwtY29tcGxldGlvbnMKICAgICAg cG9pbnQKICAgICAgKGNhciAoY29tcGxldGlvbi1ib3VuZGFyaWVzIGJlZm9yZXBvaW50IHRh YmxlIHByZWQgIiIpKSkpKQogCisocHV0ICdlbWFjczIyICdjb21wbGV0aW9uLS1hZGp1c3Qt bWV0YWRhdGEgJ2NvbXBsZXRpb24tLWVtYWNzMjItYWRqdXN0LW1ldGFkYXRhKQorCisoZGVm dW4gY29tcGxldGlvbi0tZW1hY3MyMi1hZGp1c3QtbWV0YWRhdGEgKG1ldGFkYXRhKQorICBg KG1ldGFkYXRhCisgICAgKGlnbm9yZS1hZnRlci1wb2ludCAuIHQpCisgICAgLEAoY2RyIG1l dGFkYXRhKSkpCisKIDs7OyBCYXNpYyBjb21wbGV0aW9uLgogCiAoZGVmdW4gY29tcGxldGlv bi0tbWVyZ2Utc3VmZml4IChjb21wbGV0aW9uIHBvaW50IHN1ZmZpeCkK --------------7t27Q3YoMU4RBlQUWy7eA2kp--