From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Date: Fri, 02 Jun 2023 09:47:03 +0300 Message-ID: <83r0qubbtk.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12960"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63829@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 02 08:47:28 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 1q4yZL-00038F-GU for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Jun 2023 08:47:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4yYy-0004Ax-Vy; Fri, 02 Jun 2023 02:47:05 -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 1q4yYw-0004Ao-PI for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 02:47:03 -0400 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 1q4yYw-0006j3-CQ for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 02:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q4yYw-0007YB-1p for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2023 02:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jun 2023 06:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs Original-Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168568839328987 (code B ref 63829); Fri, 02 Jun 2023 06:47:01 +0000 Original-Received: (at 63829) by debbugs.gnu.org; 2 Jun 2023 06:46:33 +0000 Original-Received: from localhost ([127.0.0.1]:38991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4yYS-0007XS-Pt for submit@debbugs.gnu.org; Fri, 02 Jun 2023 02:46:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4yYN-0007X8-8W for 63829@debbugs.gnu.org; Fri, 02 Jun 2023 02:46:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4yYH-0006bU-BO; Fri, 02 Jun 2023 02:46:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=OMW9MV1r1EpROuLO5G1XkvnBRnCVVNj+4w5AYJJ+kt4=; b=S1upZbpDvXsl utR1AFFK/FEKLbdua/iy/DjSK2NcWV9TzQUMQZuk+Rxa/8HGD6E+PbiSoV/PSBpcaAHNYR234cl+x 0es/1kPggro809I1jtCvAldOXLbTBGgExwN9II1ay8rCa/2vX+6SBbJRKZgU2NqtXiCR0RJg4qW/7 Yl8oNqfcFI6ttQJuaCAzI7t3XXJVdggHKc3DZS5d4g2pHI5IXx9OK7VxpZJj69dkiuN25owkg4yDX YII8Z2ipfw0t+x9uxUinf2wNSvXb8L75qQZ6MkaPJ6zk1BDT1TCwY1Cqsy6WJNUMOgMfzQdeD5FsO exsNf97sEapv/1YNrNY/zA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4yYB-0007mp-9t; Fri, 02 Jun 2023 02:46:16 -0400 In-Reply-To: (message from Spencer Baugh on Thu, 01 Jun 2023 18:32:29 -0400) 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:262737 Archived-At: > From: Spencer Baugh > Date: Thu, 01 Jun 2023 18:32:29 -0400 > > 1. emacs -Q > 2. Open a project where project-files only returns files in a certain > subdirectory. For example, a git repo /repo where the only file is > "dir/file.txt". > 3. Open dir/file.txt > 4. C-x p f ;; project-find file > 5. Observe that the prompt is "Find file in /repo/dir: " which correctly > contains the common parent directory between all the paths returned by > project-files. > 6. M-n ;; next-history-element > 7. The minibuffer now contains "dir/file.txt". RET will fail to > open the file. > > Instead, the common parent directory should be stripped from the "future > history" element. >From my POV, this is a clear sign of too many kludges which override the usual Emacs conventions of what is default-directory. Stripping the parent directory is IMO not the right solution; instead, the default-directory of the command should be set so that what you want happens automatically. If you go the way of patching up the code instead of fixing this fundamental problem, there will be no end to patching up. > (As a separate point: I ran into this while adding a feature for > switching between projects with similar directory structures. I want to > include the relative path in the starting project in the "future > history", so that when you have a file in projectA open, you can switch > to the same file in projectB with C-x p p f M-n RET. For example, > switching between the same file in multiple clones of Emacs. But sadly > the future history doesn't work properly right now even in a single > project) Once again, this should work by using the right value of default-directory; having relative filenames in the history up front is not TRT. Relative file names in Emacs are always interpreted relatively to default-directory, so if you start using relative names disregarding default-directory, you will eventually run into trouble, as various file-related primitives will fail with ENOENT. If the default-directory can be different for some elements of history, perhaps each element should have the default-directory metadata with it, e.g., as a property. Or maybe the history should hold absolute file names, and M-n etc. should convert it to relative as appropriate. Or something. But just treating relative file names as strings unrelated to the (implied) default-directory is simply WRONG in Emacs.