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#60505: 29.0.60; Fido Mode and Tramp Completion Date: Thu, 02 Feb 2023 10:39:25 -0500 Message-ID: References: <87k024918k.fsf@jroy.ca> <8dea9f3e0e411c315b04@heytings.org> <87tu15m6g7.fsf@gmx.de> <8dea9f3e0eb47ac9e4ab@heytings.org> <371ba1d0be1f14c7c798@heytings.org> <8aadf0ddd54d67a3213d@heytings.org> <87a62jmwj6.fsf@gmx.de> <87o7qwm3dd.fsf@gmx.de> <43562d4dd9c31382eb40@heytings.org> <87k011dtw2.fsf@gmx.de> <43562d4dd93037f7d01f@heytings.org> <834js4zi69.fsf@gnu.org> <87cz6seanu.fsf@gmx.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="36297"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 60505@debbugs.gnu.org, Eli Zaretskii , Gregory Heytings , julien@jroy.ca To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 02 16:40:26 2023 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 1pNbhJ-0009Hq-Uh for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Feb 2023 16:40:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNbgz-0004VD-3v; Thu, 02 Feb 2023 10:40:05 -0500 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 1pNbgx-0004Uz-6S for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 10:40:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pNbgw-00016C-Ui for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 10:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pNbgw-0006IU-C7 for bug-gnu-emacs@gnu.org; Thu, 02 Feb 2023 10:40:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Feb 2023 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60505 X-GNU-PR-Package: emacs Original-Received: via spool by 60505-submit@debbugs.gnu.org id=B60505.167535237524166 (code B ref 60505); Thu, 02 Feb 2023 15:40:02 +0000 Original-Received: (at 60505) by debbugs.gnu.org; 2 Feb 2023 15:39:35 +0000 Original-Received: from localhost ([127.0.0.1]:35531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNbgV-0006Hi-HM for submit@debbugs.gnu.org; Thu, 02 Feb 2023 10:39:35 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49433) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pNbgU-0006HU-1Y for 60505@debbugs.gnu.org; Thu, 02 Feb 2023 10:39:34 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 34B274414A5; Thu, 2 Feb 2023 10:39:28 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9AA4B440934; Thu, 2 Feb 2023 10:39:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1675352366; bh=iX6J/sUyBmvGYMc66v030xff7qRNR5uMYsLeswBDHww=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DRxCgkhQ+cVauf+vz0cF0dfaayFPKp8bQ89FCDcoT1Ax1eo6YlRstE/SROpk4BA0X rfVLOyXqNckLen7P5M3SRPZWpVjwq7qd34XeHY8ect3+gZKmBzoI+Uud94lY85opaX nQSLXKkWrxhlfY1fGmsM8a+ArNMUCL5/vzzF55c2X0VmdWVcUK5IbgNT79DINPXGVe t87uSWbzJSFiobEWE9Zkq4680JG5/q37SdooDs047oPO+bTapO9ZTvNH7iyIOFQf8M xu/giy9QgDCj1tbUpGtMtvjGTpOxJ9/2Ib5P5zpFBeIjQD904wOrP0klFrlLxr0YlH yDYQVodouFItw== Original-Received: from pastel (76-10-137-88.dsl.teksavvy.com [76.10.137.88]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65BEB120E80; Thu, 2 Feb 2023 10:39:26 -0500 (EST) In-Reply-To: <87cz6seanu.fsf@gmx.de> (Michael Albinus's message of "Thu, 02 Feb 2023 09:25:41 +0100") 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:254664 Archived-At: > I could imagine that the completion machinery offers an API that a > package could register its own idea of a file name syntax. The completion code relies on `file-name-directory`, `directory-file-name`, etc... for that. The problem as I see it goes as follows: According to `file-name-directory`, in `/ssh:myhost` the part `ssh:myhost` is an element of the `/` directory. For this reason, the completion machinery would expect (file-name-all-completions "s" "/") to include "ssh:myhost" in its return list rather than only "ssh:". Now, it's impractical for Tramp to do that. So the end result is the kind of bug reports we're discussing. One way to fix the problem is for Tramp to "teach" the rest of the system that `/ssh:` is a kind of directory, in which case the completion machinery would know that (file-name-all-completions "s" "/") returns "ssh:" and that "myhost" would be included only in the return value of (file-name-all-completions "" "/ssh:"). Another is to change Tramp's syntax so that it uses the regular "/" separator rather than ":". This would get a similar result but without touching `file-name-directory` and friends. We could also consider introducing a new set of (file-name) functions completion-file-name-directory, completion-directory-file-name, ... so the completion code can use its own notion of how a file name gets separated into parts. But introducing such a subtle distinction would likely introduce a lot of bugs&confusion as well. Stefan