From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.bugs Subject: bug#47678: 27.1; `completion-boundaries` assertion failure for file Date: Tue, 13 Apr 2021 16:44:42 +0200 Message-ID: References: <8d537117-d036-ad84-e013-d98efb3ae0c4@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33715"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47678@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 13 16:45:13 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 1lWKHx-0008d8-7o for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Apr 2021 16:45:13 +0200 Original-Received: from localhost ([::1]:51992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWKHv-0000tl-N3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Apr 2021 10:45:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWKHm-0000tJ-CW for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 10:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48937) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWKHm-0007o0-5G for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 10:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lWKHm-0006QY-2K for bug-gnu-emacs@gnu.org; Tue, 13 Apr 2021 10:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Apr 2021 14:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47678 X-GNU-PR-Package: emacs Original-Received: via spool by 47678-submit@debbugs.gnu.org id=B47678.161832509424676 (code B ref 47678); Tue, 13 Apr 2021 14:45:02 +0000 Original-Received: (at 47678) by debbugs.gnu.org; 13 Apr 2021 14:44:54 +0000 Original-Received: from localhost ([127.0.0.1]:60483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWKHe-0006Pw-5P for submit@debbugs.gnu.org; Tue, 13 Apr 2021 10:44:54 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:37451 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWKHb-0006Pg-Nx for 47678@debbugs.gnu.org; Tue, 13 Apr 2021 10:44:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=On3cP+8cGsnJO/9fXLm7PZzCyzB8QSNNWFgpoJmRJSo=; b=rz9zEf3E3wS8jTMH7ok0U0B1Ri PuKc7zOjVQwhYumDd/LV8wUiC+i+2QV7Gfw1/DZ2yVtgCkvgu/GJP7dFD9oumyrlo/Mz55Lpn0Sru 60iPQSZGLomopANK+/G126F+6qFRDJF4yFD5zrLtg63BkOXVchY6CI9VJTe4+yn2gDs4=; In-Reply-To: Content-Language: en-US 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:203966 Archived-At: On 4/13/21 2:46 PM, Stefan Monnier wrote: > The problem has to do with quoting/unquoting: in `C-x C-f` we do not > quite enter "raw file name" because the name typed by the user is passed > through `substitute-in-file-name` which expands envvar references (and > de-doubles dollars for those files whose name looks like an envvar > reference) and does some truncation (like foo//bar => /bar). I am aware of that feature and use it but for now I avoided looking into how this is exactly implemented :) > So the `completion-file-name-table` (which completes raw file names) is > wrapped via `completion-table-with-quoting` and this function has to be > able to relate the unquoted text back to the quoted text, for example in > order to convert the boundaries returned by `completion-file-name-table` > (on the unquoted file name) into the corresponding boundaries that apply > to the quoted file name. > > This is in general somewhere between hard and impossible. So if/when we > get those boundaries wrong (for example) it may lead to misbehavior down > the line. > I'd rather not try and guess what those might be. > I'm just hoping that they're minor enough and rare enough. Thank you for the detailed explanation. Ok, but in the case where this issue occurs we already have a somehow broken path, especially when moving with the point over the shadowed parts. So as a user I would not be worried to much if this does not work. I hope most assumptions down the line are checked by conditions. However given that in this particular case we already have an error we could only get more errors at worst down the line? (Btw, in Vertico I throw out the shadowed paths as soon as I get the opportunity (vertico--tidy-shadowed-file) in the same way as Icomplete does it if enabled.) Daniel