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#48356: 28.0.50; choose-completion discards the suffix after the completion boundary Date: Tue, 9 Apr 2024 00:59:32 +0300 Message-ID: <39326c56-094c-4074-95d7-8f92f7f927a5@gutov.dev> References: <18593691-8b7a-facf-68e1-e9d0c106897b@daniel-mendler.de> <868rtcjqk4.fsf@mail.linkov.net> <949a6c3a-9a59-89dd-bdee-c0ec6ee0baa7@daniel-mendler.de> <86r173odnm.fsf@mail.linkov.net> <868rt42wiz.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------bJEsTBOpw0RiDhC4vRhM2oUC" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34940"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 48356@debbugs.gnu.org, Stefan Monnier , JD Smith To: Juri Linkov , Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 09 00:00:39 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 1rtx2b-0008rM-Ly for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Apr 2024 00:00:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtx20-0003RG-Us; Mon, 08 Apr 2024 18:00:01 -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 1rtx1y-0003R2-EU for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 17:59:58 -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 1rtx1y-0002dg-6b for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 17:59:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtx25-0001F3-7K for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 18:00:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2024 22:00:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48356 X-GNU-PR-Package: emacs Original-Received: via spool by 48356-submit@debbugs.gnu.org id=B48356.17126135944676 (code B ref 48356); Mon, 08 Apr 2024 22:00:05 +0000 Original-Received: (at 48356) by debbugs.gnu.org; 8 Apr 2024 21:59:54 +0000 Original-Received: from localhost ([127.0.0.1]:47810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtx1u-0001DK-D1 for submit@debbugs.gnu.org; Mon, 08 Apr 2024 17:59:54 -0400 Original-Received: from fout8-smtp.messagingengine.com ([103.168.172.151]:39321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtx1q-0001Ci-CG for 48356@debbugs.gnu.org; Mon, 08 Apr 2024 17:59:52 -0400 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfout.nyi.internal (Postfix) with ESMTP id 5774D1380143; Mon, 8 Apr 2024 17:59:36 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 08 Apr 2024 17:59:36 -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=fm1; t=1712613576; x=1712699976; bh=bdczJkp9bJ Dqu5gH9ViWR6lXUTr5yQt9OnkvS+jAkQ4=; b=vFFOUHmFrAkfPU6ejc5xp/+Mk3 cW4OfSaKpNTH6TVXhjtQvkXn3Bk86kKTwOTXXhEY62kKlSmfwsrQ3yEswXcPby4N We9aij9W2guSpSbaZ7o6lDD5Zyv456/ncNG6gUmZrHwQCQqi8S8/bSyj13NCn0J5 SRra73smyL51daWympOUFb6TaQRY26C1WWv+5PLjnUexF05yjlDS9TqZcltTB0qy gJO6LkQ7194MLu1lXnsb2tVTt27X31VR0vdcpIFL5wDlpDkljph6Sykv6KZTKt7C PcOWFDPPTJUIxN6voF1gCMfE04/Z3kh2aP4sl5wgLwJjvpXQXDU6mgLAdbNg== 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=1712613576; x=1712699976; bh=bdczJkp9bJDqu5gH9ViWR6lXUTr5 yQt9OnkvS+jAkQ4=; b=hDzxLL9Mr4+pg9ci7nZYN+6R2ZztogSgHKkIHlVfaEaP X2rIX+hwPB8ZNmogNgn1WkiC5rp/WLMYB/riAETpOC3boRDb19ejjKH44ayP4wGA UT0QHPkFkxEdapgJSzI7RXoysfT9C6iRaKskeuDcz+GRLp/qlbfVdX9ri1tiGkYU QthIwJM6U2ndnsKHmvqLyGU04GGoatq0V8lgrMcid6zEgGO7ZHz1oj/pg9sv+FZL INhay17+jkvkQujf1F3XvxoJGqWNFfhFHNTcBQOEGhukHMrkTIwyNsDBbiYuHOQ4 tHuqf5ORcGb3TBAWN1lqMtNO7FaHq5tOshiarm8+BA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudegjedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfevfhfhjgesmhdtreertddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeelkeejiedvffdtgeejvdffffelueelkefhtdekjeehuefgteduheegfefhieek jeenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Apr 2024 17:59:34 -0400 (EDT) Content-Language: en-US In-Reply-To: <868rt42wiz.fsf@mail.linkov.net> 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:282956 Archived-At: This is a multi-part message in MIME format. --------------bJEsTBOpw0RiDhC4vRhM2oUC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 20/03/2022 22:34, Juri Linkov wrote: >>>>> IMHO, the root of the problem is in completion-all-completions >>>>> that returns in the last `cdr' only the start of completions, >>>>> but not the end of completions. >>>> Agreed. >>> If I recall correctly, someone wrote a patch which fixed the root cause. >> The only patch that removes these comments >> >> ;; FIXME: We need to additionally return the info needed for the >> ;; second part of completion-base-position. >> >> ;; FIXME: We should pay attention to completion >> ;; boundaries here, but currently >> ;; completion-all-completions does not give us the >> ;; necessary information. >> >> ishttps://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00412.html >> in bug#47711 and bug#48841. > I wonder what is the fate of this patch? There was a long discussion > without a clear outcome. Maybe it's possible to split the patch > to smaller parts where a separate patch would add the feature needed here > to return the end position of the completion boundaries? It seems there is a range of solutions we could take here. On the one side would be a replacement of the -all-completions API with something like completion-filter-completions as proposed by Daniel. It's still a reasonable choice, but a rather breaking one, and the patch would need to be majorly rewritten anyway, given the amount of changes in the area since it was submitted. On the other, we could preserve the current convention again, and add a new dynamic variable which would be assigned in every relevant completion style, to store the rightmost-position (the length of suffix). Then the callers would fetch it from that variable. Similar to what we do with completion-lazy-hilit-fn now. Or some variations of that. But what I don't quite see yet, is why wouldn't the caller be able to compute the bounds cheaply enough? We could offer an accessor function. See the new logic in the attached patch (but imagine it extracted to a named function). Note that it doesn't work too well now, because in the example like ~/v/e-|/src the completions include the trailing slash. And base-suffix includes a starting slash as well (according to boundaries returned by the completion table). So when I choose one of the completions using minibuffer-next-completion, the minibuffer contents look like ~/v/emacs-master//src ...which translates to "/" because of the double slash -- the filesystem root directory (*). But that's the same data which would be used by any other proposed solution, too. So maybe it should be either be fixed in the completion table (avoid adding trailing slash when the last boundary is already followed by slash?), or the insertion code should do some additional post-processing of the completion string. (*) And then, when I press tab while point is between slashes -- /|/ -- it jumps to the beginning of the input, but that's a secondary problem. --------------bJEsTBOpw0RiDhC4vRhM2oUC Content-Type: text/x-patch; charset=UTF-8; name="base-suffix.diff" Content-Disposition: attachment; filename="base-suffix.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvbWluaWJ1ZmZlci5lbCBiL2xpc3AvbWluaWJ1ZmZlci5lbApp bmRleCAwYTg0NGM1MzhiNC4uMzNjMTc1YWEzYzYgMTAwNjQ0Ci0tLSBhL2xpc3AvbWluaWJ1 ZmZlci5lbAorKysgYi9saXNwL21pbmlidWZmZXIuZWwKQEAgLTI1ODIsMTYgKzI1ODIsMTMg QEAgbWluaWJ1ZmZlci1jb21wbGV0aW9uLWhlbHAKICAgICAgICAgICAgICAobWluaWJ1ZmZl ci1jb21wbGV0aW9uLWJhc2UgKHN1YnN0cmluZyBzdHJpbmcgMCBiYXNlLXNpemUpKQogICAg ICAgICAgICAgIChiYXNlLXByZWZpeCAoYnVmZmVyLXN1YnN0cmluZyAobWluaWJ1ZmZlci0t Y29tcGxldGlvbi1wcm9tcHQtZW5kKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoKyBzdGFydCBiYXNlLXNpemUpKSkKLSAgICAgICAgICAgICAoYmFz ZS1zdWZmaXgKLSAgICAgICAgICAgICAgKGlmIChvciAoZXEgKGFsaXN0LWdldCAnY2F0ZWdv cnkgKGNkciBtZCkpICdmaWxlKQotICAgICAgICAgICAgICAgICAgICAgIGNvbXBsZXRpb24t aW4tcmVnaW9uLW1vZGUtcHJlZGljYXRlKQotICAgICAgICAgICAgICAgICAgKGJ1ZmZlci1z dWJzdHJpbmcKLSAgICAgICAgICAgICAgICAgICAoc2F2ZS1leGN1cnNpb24KLSAgICAgICAg ICAgICAgICAgICAgIChpZiBjb21wbGV0aW9uLWluLXJlZ2lvbi1tb2RlLXByZWRpY2F0ZQot ICAgICAgICAgICAgICAgICAgICAgICAgIChwb2ludCkKLSAgICAgICAgICAgICAgICAgICAg ICAgKG9yIChzZWFyY2gtZm9yd2FyZCAiLyIgbmlsIHQpIChwb2ludC1tYXgpKSkpCi0gICAg ICAgICAgICAgICAgICAgKHBvaW50LW1heCkpCi0gICAgICAgICAgICAgICAgIiIpKQorICAg ICAgICAgICAgIChiYXNlLXN1ZmZpeCAobGV0ICgoc3VmZml4IChidWZmZXItc3Vic3RyaW5n IChwb2ludCkgZW5kKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHN1YnN0cmlu ZworICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdWZmaXgKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKGNkciAoY29tcGxldGlvbi1ib3VuZGFyaWVzIHN0cmluZworICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWluaWJ1ZmZlci1jb21wbGV0aW9uLXRhYmxlCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtaW5pYnVmZmVyLWNvbXBsZXRpb24t cHJlZGljYXRlCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBzdWZmaXgpKSkpKQogICAgICAgICAgICAgIChhbGwtbWQgKGNvbXBs ZXRpb24tLW1ldGFkYXRhIChidWZmZXItc3Vic3RyaW5nLW5vLXByb3BlcnRpZXMKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnQgKHBvaW50KSkK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiYXNlLXNpemUg bWQK --------------bJEsTBOpw0RiDhC4vRhM2oUC--