From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#47678: 27.1; `completion-boundaries` assertion failure for file Date: Sat, 08 May 2021 19:41:29 -0400 Message-ID: References: <8d537117-d036-ad84-e013-d98efb3ae0c4@daniel-mendler.de> <87v97wxjtf.fsf@gnus.org> <214d78e9-cda2-e2f2-7284-0f4f6bda43b7@daniel-mendler.de> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30286"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 47678@debbugs.gnu.org, Lars Ingebrigtsen To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 09 01:42:11 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 1lfWaJ-0007lJ-No for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 09 May 2021 01:42:11 +0200 Original-Received: from localhost ([::1]:43416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lfWaI-0008Gj-B3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 May 2021 19:42:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lfWaA-0008Ga-Eg for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 19:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41416) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lfWaA-0004lp-6v for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 19:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lfWaA-0002rx-3K for bug-gnu-emacs@gnu.org; Sat, 08 May 2021 19:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 May 2021 23:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47678 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo fixed Original-Received: via spool by 47678-submit@debbugs.gnu.org id=B47678.162051729911020 (code B ref 47678); Sat, 08 May 2021 23:42:02 +0000 Original-Received: (at 47678) by debbugs.gnu.org; 8 May 2021 23:41:39 +0000 Original-Received: from localhost ([127.0.0.1]:52960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfWZm-0002rg-Qn for submit@debbugs.gnu.org; Sat, 08 May 2021 19:41:39 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lfWZl-0002ra-AV for 47678@debbugs.gnu.org; Sat, 08 May 2021 19:41:37 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F0340100201; Sat, 8 May 2021 19:41:31 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 874F21001F4; Sat, 8 May 2021 19:41:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1620517290; bh=X3Cw6LQTv8uFygnfbjT6Ftr5DRFzGwE1TnwTplIukTs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JugWycB2eNc0WqZFZBkW1uoIjIAGx75d8IA1qnDTJtye809CkOmC5PDT5AYgkBf8d FIqTnJSaOfii0GiA5XpNbhD3oP+lmEM5HX+se/rOs2qXXkMZpQK4BLlKxJHKgsOZtT O7M+wHZVpYXkWchymCU5YBwY1FT3PoWijMHbQDA6wTZCYzrIRt4ux1oFqV96Ln5jnJ VJ1/6KmQJAxmhbdr+f3j5WI+9x/91ZD8HqvGmdvqzb39lkZ238P3bNowY61K3Vr/J2 rdHb6vIm0i/Vb7lZ1gNMkvjvuT82AO/A9CiCaXEqK8lRuGhvyxZkZIZrLR6x7eIpKY eWqwkkh1AkBHA== Original-Received: from alfajor (76-10-140-76.dsl.teksavvy.com [76.10.140.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 22529120175; Sat, 8 May 2021 19:41:30 -0400 (EDT) In-Reply-To: <214d78e9-cda2-e2f2-7284-0f4f6bda43b7@daniel-mendler.de> (Daniel Mendler's message of "Thu, 6 May 2021 13:07:40 +0200") 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:206037 Archived-At: Daniel Mendler [2021-05-06 13:07:40] wrote: > On 5/6/21 12:01 PM, Lars Ingebrigtsen wrote: >> Stefan Monnier writes: >>> IOW I consider the existence of `vertico--tidy-shadowed-file` as a bug >>> in itself ;-) >> Skimming this thread, I'm not sure whether there's anything to be done >> in Emacs here? There is, but it's not a simple "bug fix". What I meant above is that the existence of `vertico--tidy-shadowed-file` reflects a shortcoming of the completion API, which does not offer any way for the completion-table to explain this kind of "shadowing", so the UI is stuck using ad-hoc tricks by trying to detect use of some specific completion tables (e.g. by testing `minibuffer-completing-file-name`) and then using "inside-knowledge" of the semantics behind it. Not only the way it's done is inevitably "hackish", but it's also very hard to make it correct. E.g. the shadowing is not a property of file names but of `substitute-in-file-name`, so `file-name-shadow-mode` and `vertico--tidy-shadowed-file` can misfire if you're reading a file name which will not be passed to `substitute-in-file-name`. > @Stefan The existence of this function is a bug for people who want to > keep their shadowed paths. This is a matter of preference. For me > shadowed paths are a cheap means of changing the directory during > completion and I usually don't want to go back to the old path in the > process. Icomplete has the same function, but guarded behind a > customization option. Why do you prefer to keep the shadowed paths? I don't. I think it makes a lot of sense as a UI feature. To do it right, we'd need completion tables to provide some kind of "tidy up" or "simplify" or "canonicalize" method, I think. Stefan