From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Jun 2023 22:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 63829@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168565876423290 (code B ref -1); Thu, 01 Jun 2023 22:33:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Jun 2023 22:32:44 +0000 Received: from localhost ([127.0.0.1]:38648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4qqa-00063a-5c for submit@debbugs.gnu.org; Thu, 01 Jun 2023 18:32:44 -0400 Received: from lists.gnu.org ([209.51.188.17]:58496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q4qqU-00063M-Sq for submit@debbugs.gnu.org; Thu, 01 Jun 2023 18:32:42 -0400 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 1q4qqP-0006yY-Hs for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2023 18:32:33 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4qqN-00067S-La for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2023 18:32:33 -0400 From: Spencer Baugh Date: Thu, 01 Jun 2023 18:32:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 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. (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) In GNU Emacs 29.0.90 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-05-17 built on igm-qws-u22796a Repository revision: 4d08492296c2a6d2910f2b740c2d2508275458fc Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: CentOS Linux 7 (Core) Configured using: 'configure --with-x-toolkit=lucid --with-gif=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory 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 X-GNU-PR-Keywords: To: Spencer Baugh Cc: 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168568839328987 (code B ref 63829); Fri, 02 Jun 2023 06:47:01 +0000 Received: (at 63829) by debbugs.gnu.org; 2 Jun 2023 06:46:33 +0000 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 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 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==; 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 Date: Fri, 02 Jun 2023 09:47:03 +0300 Message-Id: <83r0qubbtk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 01 Jun 2023 18:32:29 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 02:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168575942330746 (code B ref 63829); Sat, 03 Jun 2023 02:31:02 +0000 Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 02:30:23 +0000 Received: from localhost ([127.0.0.1]:41126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5H26-0007zp-P4 for submit@debbugs.gnu.org; Fri, 02 Jun 2023 22:30:23 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:56201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5H25-0007zW-14 for 63829@debbugs.gnu.org; Fri, 02 Jun 2023 22:30:22 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 43954320092C; Fri, 2 Jun 2023 22:30:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 02 Jun 2023 22:30:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1685759412; x=1685845812; bh=1UI8QODFq6yx8JZww0XPvRNRm2P7XNIoz8y C9sE7NCs=; b=c3Dm61L4jDWtnYIVS6vbIPC3Zl3+5UzkpAJNHSJmh5I/rJ4R+q+ kKaYlp/kpAbLRfnyN6dqsv2b06N2zjfygjyFHi5M8UKQ3Rs6umcNShhWDfoKcKln PkLldsYi7lhgt0cj+lkY73Nf8nNDt7mfTjJw2ryO01sDUzUYa+OWQKHZd/4TTAhy C+2AxyXjihdT4nEjzCyAxtvj0KI6gk+qZcbdaypd3Uo9Cl+JKQrWDJc3e4trNwNb oTUgq7whX0lqMlc4IluN/Y6MbLGlL+kKj3+k13CScrkslBhyH/119+UayexiDvhc kImEqOuFabhFNiA6PduJhFKWRHgRQiv4B7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1685759412; x= 1685845812; bh=1UI8QODFq6yx8JZww0XPvRNRm2P7XNIoz8yC9sE7NCs=; b=Q d/RJX2q5N4aw5SWmqtJtvcmEoRbJVmDrdRZzI5Um2JQR40GVsLHCbt9PUAiS0im+ gvjuITiMqJz2f3wPUlhLFNm6Rk6lVXseOFJIJrPfk4ykzzwoivYDoM6FITLuJpI7 Epb+RMnywsEnGVYwAYvvJb4lZKIRP1uALIutAj7qiLh1K2FR/nlpG9vSIwXnoDpC Wr8PXRDGZ9ZekIGRkh15F9YlRSsLfHcUF7CU0cja17a9ISIJc/6yBZhlI+38Hic8 UgCOhv5y4Pa3PfYAn97zlu6ll9Ccxf5dl6CoLPkS5X4AGn8iR2g44TL+s8jOhcQM NbOHOr8A68KYqg6yfzUvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelgedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 2 Jun 2023 22:30:11 -0400 (EDT) Message-ID: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> Date: Sat, 3 Jun 2023 05:30:10 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) Hi! On 02/06/2023 01:32, Spencer Baugh wrote: > > 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. Note that if you continue pressing 'M-n', you will see the corresponding proper relative file names. The first one comes from the value constructed in project-find-file. Which indeed looks problematic, since we remove context in there by creating a relative name. > Instead, the common parent directory should be stripped from the "future > history" element. Try the patch at the end, please. It seems to fix the scenario you presented. Does it help with the feature you mention below, too? It doesn't handle the case when (thing-at-point 'filename) returns a relative file name that includes a directory name, relative to the project root (where common-parent-directory differs), but that one seems even more ambiguous. > (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) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 7c51778d5d4..184f2316074 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1008,7 +1008,7 @@ project-find-file (dirs (list root))) (project-find-file-in (or (thing-at-point 'filename) - (and buffer-file-name (file-relative-name buffer-file-name root))) + buffer-file-name) dirs pr include-all))) ;;;###autoload @@ -1062,6 +1062,10 @@ project--read-file-cpd-relative (delete common-parent-directory all-files)) t)) (substrings (mapcar (lambda (s) (substring s cpd-length)) all-files)) + (mb-default (if (and common-parent-directory + (file-name-absolute-p mb-default)) + (file-relative-name mb-default common-parent-directory) + mb-default)) (_ (when included-cpd (setq substrings (cons "./" substrings)))) (new-collection (project--file-completion-table substrings)) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 11:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16857900676283 (code B ref 63829); Sat, 03 Jun 2023 11:02:01 +0000 Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 11:01:07 +0000 Received: from localhost ([127.0.0.1]:41612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5P0M-0001dH-Lk for submit@debbugs.gnu.org; Sat, 03 Jun 2023 07:01:06 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43835) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5P0J-0001cc-5F for 63829@debbugs.gnu.org; Sat, 03 Jun 2023 07:01:05 -0400 From: Spencer Baugh In-Reply-To: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> (Dmitry Gutov's message of "Sat, 3 Jun 2023 05:30:10 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> Date: Sat, 03 Jun 2023 07:00:56 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Try the patch at the end, please. It seems to fix the scenario you > presented. Does it help with the feature you mention below, too? Yes, your patch works great and solves the cases I care about! On top of your patch, I can implement the feature I mentioned with the patch at the end. This causes the following nice behavior: 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el 2. C-x p p ~/src/emacs/trunk 3. f 4. M-n and the minibuffer contains "lisp/progmodes/project.el" 5. RET and we have now easily switched to the same file in another project Does the implementation seem OK? diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index ac7be8dcbb2..b1e01df5314 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1008,7 +1008,12 @@ project-find-file (dirs (list root))) (project-find-file-in (or (thing-at-point 'filename) - buffer-file-name) + (and buffer-file-name + (if-let (buffer-proj (and project-current-directory-override + (project-current nil default-directory))) + (let ((buffer-root (project-root buffer-proj))) + (file-name-concat root (file-relative-name buffer-file-name buffer-root))) + buffer-file-name))) dirs pr include-all))) ;;;###autoload From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 12:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Spencer Baugh Cc: 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16857948071706 (code B ref 63829); Sat, 03 Jun 2023 12:21:02 +0000 Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 12:20:07 +0000 Received: from localhost ([127.0.0.1]:41764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5QEp-0000RR-8O for submit@debbugs.gnu.org; Sat, 03 Jun 2023 08:20:07 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5QEl-0000Qe-JY for 63829@debbugs.gnu.org; Sat, 03 Jun 2023 08:20:05 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 811975C00A1; Sat, 3 Jun 2023 08:19:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 03 Jun 2023 08:19:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1685794798; x=1685881198; bh=Or7iHHOhYe1m8bLhGW9NfB1J3Vk8VNL+RzV UR9/d154=; b=YD864CT7Eor8mSkYBEzIiOHv2rxzqJGOwxSGdoAYC923q+rdkeg GqPeNSkrAjSH462JE03WFoU1u2tXgGjsAszhZHrGSGtW6/2c3PRU/yfsvZH4hC5j 92vrVI9Sv0IUGI32AmNfGaolExKFhlJga/xJhbFUx/lA4QNbnm0d9h57q88pBv4C teNjvIiOcurnPkFbM5ex0D+y14MzoiEqvesPcwpf0bZPfw1F5ScEJAj2Hjs2LvlY AQHohhlIfws8mGeDVw7itq+WOGBmzY5hZwmO+aTHF9D3t0fhmX+STTozqfJ0d9ch 11GU5AOb5/2KaQx4ty2tUqJWuekPhnNoFcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1685794798; x=1685881198; bh=Or7iHHOhYe1m8bLhGW9NfB1J3Vk8VNL+RzV UR9/d154=; b=FxIQrs1TLoM3vVwZejOpvscz8U2bN2e+30pEqXpiVbpqEGboi36 tll6nsvAENLuxyeFHB2liNsa5at82npoS+Qrz+xakXs+5h24WJT8/F8KbTJt53lM IvIfyLEo0PzA7NvJOrk/qDRiUaNjC4KSKcKDdiaUwXNnDjh4+1sW4Oj3A0n9VUVd rCvktN6jPy2h9g8/j8+HvlWmnGB7RMtPYvmOV4PCP5N2mhVz5V4+VSFvFl5UFKsy jq9CfxxZ3Dc2PkOYi1uoOZCqwW5ExLYzLTyl2DsP93pvb+xZpeGf3zpyhWrkXIYM XosoFzlJSXYUDO+70N3et5Z63PZcYUHTeEw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 08:19:56 -0400 (EDT) Message-ID: <2790cb95-cfc8-40ee-2a89-d9effe2c2060@gutov.dev> Date: Sat, 3 Jun 2023 15:19:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US References: <83r0qubbtk.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83r0qubbtk.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Hi Eli, On 02/06/2023 09:47, Eli Zaretskii wrote: >> 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. TBH, I'm not sure which particular change you were proposing. Do you like the patch I posted? It could be considered somewhere in that direction. Should it go to emacs-29 or master? >> (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. The problem here is that is a different/new scenario where Spencer wants to have a file name from one project be applied to another project. It seems like using absolute names would rather go in the opposite direction. > 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. The latter is mostly what happens. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 12:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@janestreet.com, 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16857964804643 (code B ref 63829); Sat, 03 Jun 2023 12:48:01 +0000 Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 12:48:00 +0000 Received: from localhost ([127.0.0.1]:41774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Qfn-0001Cn-Et for submit@debbugs.gnu.org; Sat, 03 Jun 2023 08:48:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Qfj-0001Bt-DV for 63829@debbugs.gnu.org; Sat, 03 Jun 2023 08:47:57 -0400 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 1q5Qfd-0004wf-Pd; Sat, 03 Jun 2023 08:47:49 -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=eGUg3CmI0Piy8MPLylfklrVuuI6l/6Rc1xGr/K1wGyI=; b=EWiIQNLNWS3o BP16rYqtWPRBa4rUCfPrK7S5LRyjbpz13uX6Qa+5AM3w9HgNNrVxbbqfDM4xWML4frik+SR3ALfJM y2QLuGp9A8/0v/3FD/vs/p2hHJJh8PlrVQw1GYnvf4B8h8oqoNPw0wQo5nJAee41M6M1+k0d7afrE wKBOvwoXoENkr0Yj7Az2bQqV6ZjeD6TySDKcDIQJtjbb2MnhnOReyQknVGwShPI5ScoNa0VLNJIVF u7UWTDXFiLnM78Cqt9jsFbJ9n+oUy+jGksiXauqTgaW89fkOlxtJJHJbkVZXEzb47IPgCfoZ0GoOq drrJmhnCqG24Zqm7E92o+g==; 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 1q5Qfd-00043j-9N; Sat, 03 Jun 2023 08:47:49 -0400 Date: Sat, 03 Jun 2023 15:48:40 +0300 Message-Id: <83o7lw90ev.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <2790cb95-cfc8-40ee-2a89-d9effe2c2060@gutov.dev> (message from Dmitry Gutov on Sat, 3 Jun 2023 15:19:55 +0300) References: <83r0qubbtk.fsf@gnu.org> <2790cb95-cfc8-40ee-2a89-d9effe2c2060@gutov.dev> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 3 Jun 2023 15:19:55 +0300 > Cc: 63829@debbugs.gnu.org > From: Dmitry Gutov > > On 02/06/2023 09:47, Eli Zaretskii wrote: > >> 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. > > TBH, I'm not sure which particular change you were proposing. I was talking about the description of the problem, and what conclusion it caused me to draw. > Do you like the patch I posted? It could be considered somewhere in that > direction. I don't know enough about the details to have opinion of any importance. But if the change goes in the direction I thought we should go, then that's good. > Should it go to emacs-29 or master? Unless this is a bad problem, I'd prefer that the change goes to master. > >> (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. > > The problem here is that is a different/new scenario where Spencer wants > to have a file name from one project be applied to another project. It > seems like using absolute names would rather go in the opposite direction. If some command wants to produce file names in a different directory, then that command should do something like (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY) The code which produces the original FILENAME should still produce an absolute file name (or record its directory in some other way); it should not know/assume anything about potential uses of that file name. > > 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. > The latter is mostly what happens. I very much hope so, because anything else is going in the wrong direction. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2023 13:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: sbaugh@janestreet.com, 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168580014711979 (code B ref 63829); Sat, 03 Jun 2023 13:50:01 +0000 Received: (at 63829) by debbugs.gnu.org; 3 Jun 2023 13:49:07 +0000 Received: from localhost ([127.0.0.1]:41907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rcw-000378-KW for submit@debbugs.gnu.org; Sat, 03 Jun 2023 09:49:07 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rct-00036W-PE for 63829@debbugs.gnu.org; Sat, 03 Jun 2023 09:49:05 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 953FB5C018A; Sat, 3 Jun 2023 09:48:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sat, 03 Jun 2023 09:48:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1685800138; x=1685886538; bh=MqbgvtuvYosDSwPcO7t3g2cpiLjuHFCz2+H EhRBO+5g=; b=CzTehn//FKfOIDVmy8KwyjVHgNqpOzV3iOS/6Rru10mUSiE56DM LfBlmoN5h2tynyt4SeLKz3i0di6ASrGPsHfTcGkBmSrDoLC0C/kb7SCJDOWLi1ha DU62K5FFqo3zqjVxj50IR0N6zt7V5C3cxfLILnnofceMotQ+47Pd5b662wk8QBia agZx0O8jmXpHWBnUpDRORJ0cHgNgoenx8U7oj7uPARDqxOzpCBSdwX6wEnjUc85o HTpRvGOGIrnGW6hu5+e/PTeZhgHGiWQJ5eHsA2caOC3yQZ9JeMCjHGj9tfL0GhQ5 s5c013k7MqyPc/deh+UJJ+n/foD/1lRNKgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1685800138; x=1685886538; bh=MqbgvtuvYosDSwPcO7t3g2cpiLjuHFCz2+H EhRBO+5g=; b=LPIdiXj7CFvFVm5gdDoUBbnSjU7qm5VJ5P9tNTgcbxjGd9LFu8C GSzxu7pmCvEq+sIzQgrA5iwO1wCBWnMCWO3Bl5JYZj3KNdyk8ESjbLAdu7FpZd2L y8/BJDpaFAzH0uE9sdY4XGdB/8LI3cHEropYk9Mq9CIYGwueTVZ85TbQCAmPkvdD aK4Rrdu6BJNssSK2llK7CPTCfFH2HdF9KuwsA/VF0H6pOvw+enDNrZQX3jxuCs56 0W4gXXrwBsEpp7OK6hoR76rBRmKb/KUOQLZu3iam4Ki3B5BZaO6ZIBCTz4cLvAJU P/hGYIG1S46HB1tuQ1OCKaWb0f33iqBSliQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelhedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jun 2023 09:48:57 -0400 (EDT) Message-ID: <9406d283-967a-85c6-d8db-5b9c9912a46f@gutov.dev> Date: Sat, 3 Jun 2023 16:48:55 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US References: <83r0qubbtk.fsf@gnu.org> <2790cb95-cfc8-40ee-2a89-d9effe2c2060@gutov.dev> <83o7lw90ev.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83o7lw90ev.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) On 03/06/2023 15:48, Eli Zaretskii wrote: >> Do you like the patch I posted? It could be considered somewhere in that >> direction. > > I don't know enough about the details to have opinion of any > importance. But if the change goes in the direction I thought we > should go, then that's good. > >> Should it go to emacs-29 or master? > > Unless this is a bad problem, I'd prefer that the change goes to > master. Maybe it's not too serious, given that it requires the user to invoke "future history" (not everybody knows of it), and for the project to have all files in one subdirectory. >>>> (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. >> >> The problem here is that is a different/new scenario where Spencer wants >> to have a file name from one project be applied to another project. It >> seems like using absolute names would rather go in the opposite direction. > > If some command wants to produce file names in a different directory, > then that command should do something like > > (expand-file-name (file-name-nondirectory FILENAME) NEW-DIRECTORY) > > The code which produces the original FILENAME should still produce an > absolute file name (or record its directory in some other way); it > should not know/assume anything about potential uses of that file > name. Sounds like Spencer's last patch. It's not too great that we'll make project-find-file aware of project-current-directory-override, though. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jun 2023 17:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168589810330464 (code B ref 63829); Sun, 04 Jun 2023 17:02:02 +0000 Received: (at 63829) by debbugs.gnu.org; 4 Jun 2023 17:01:43 +0000 Received: from localhost ([127.0.0.1]:47047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5r6t-0007vH-DP for submit@debbugs.gnu.org; Sun, 04 Jun 2023 13:01:43 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:42815) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5r6s-0007us-4j for 63829@debbugs.gnu.org; Sun, 04 Jun 2023 13:01:42 -0400 X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net X-GND-Sasl: juri@linkov.net Received: by mail.gandi.net (Postfix) with ESMTPSA id F3E3F1C0003; Sun, 4 Jun 2023 17:01:34 +0000 (UTC) From: Juri Linkov In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 07:00:56 -0400") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> Date: Sun, 04 Jun 2023 19:36:25 +0300 Message-ID: <86h6rnw7gm.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > On top of your patch, I can implement the feature I mentioned with the > patch at the end. This causes the following nice behavior: > > 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el > 2. C-x p p ~/src/emacs/trunk > 3. f > 4. M-n and the minibuffer contains "lisp/progmodes/project.el" > 5. RET and we have now easily switched to the same file in another > project > > Does the implementation seem OK? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac7be8dcbb2..b1e01df5314 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1008,7 +1008,12 @@ project-find-file > (dirs (list root))) > (project-find-file-in > (or (thing-at-point 'filename) > - buffer-file-name) > + (and buffer-file-name > + (if-let (buffer-proj (and project-current-directory-override > + (project-current nil default-directory))) But we are going to remove project-current-directory-override in bug#63648 where default-directory will be changed to next-default-directory. BTW, I asked about this before in https://debbugs.gnu.org/58447#127 and then it was deemed to be not too general to handle, so I backed it out in https://debbugs.gnu.org/58447#160 with such conclusion: OTOH, `C-x p f M-p' in another project is not my primary workflow. But if someone wants to keep a plain history, this could be added later in master, e.g. by a new value of project-read-file-name-function and a function that is mostly a copy of project--read-file-cpd-relative. So maybe this could be implemented in master now? From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jun 2023 01:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov , Spencer Baugh Cc: 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16860156158854 (code B ref 63829); Tue, 06 Jun 2023 01:41:01 +0000 Received: (at 63829) by debbugs.gnu.org; 6 Jun 2023 01:40:15 +0000 Received: from localhost ([127.0.0.1]:50603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6LgF-0002Ii-5F for submit@debbugs.gnu.org; Mon, 05 Jun 2023 21:40:15 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6LgC-0002IU-8T for 63829@debbugs.gnu.org; Mon, 05 Jun 2023 21:40:13 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1B1D75C008C; Mon, 5 Jun 2023 21:40:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 05 Jun 2023 21:40:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1686015607; x=1686102007; bh=EKRgbP0hBbn93X3PQa0zNAYztJKSUiKeXDL 5usnkt8I=; b=KsSriYJf7dsuUaG3fcewENybjDH4wHChceSOXG9yZyWlYHgHzvv W0gNaUnExLw10ZhznPPbg+DV3uv03je4WlmLkgkekuq/5sa0NxNjDlmqe12uauV3 bfvSGsvTl7MG29iR/Fz6XCO6xD93F/n/e25UOgakgR4Y8lyA7zxkkYP8IGxtY958 O4sVGjL+wR2RZ1PxGllHampVcZ/wTNlxmPtA4elnhfgK9qoJcAJvjHT0734uBREE ZSZ7O4chzTPn0TMir2iojris/WQJCyJUtYcaRI6bCPnapQXE2XfGrhqyc4l1MwkE NHIO3jb1edzcDG25/vzSAdLCEiEHUUEXKQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1686015607; x=1686102007; bh=EKRgbP0hBbn93X3PQa0zNAYztJKSUiKeXDL 5usnkt8I=; b=KtY6QG+r2yjV5WJkH2HMwlnGIVpdSXh5epwHFdY0k3ovHdgZrQd j7bJqn3aKS16a+gOG+DruBvgWKUtDRUmuW5bF7wJGd58R+FDwWAky2Mq6jrE+Ar+ InF9MpXVanBQAUP9xV5IXiCUMXEqQ9f3Y0pF35XMYm648D7ZUNKii+Y5n6PGlFma ngSh+l4oaAh4WQONGaohg+5VhL/YgCYLgmkQNTD/AT7W0n7MuI9w4VhhOrgpFSoc KF1v7hmnx/qxAuLQamKpf4FWwl/RzxCD/a7PGamDaHyhg8M+FC9X8Lyku99gcuIs t4wFhlu/csT2/gvITDDAscGBuiNL7DLFrnw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedttddggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jun 2023 21:40:05 -0400 (EDT) Message-ID: <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> Date: Tue, 6 Jun 2023 04:40:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86h6rnw7gm.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) On 04/06/2023 19:36, Juri Linkov wrote: >> On top of your patch, I can implement the feature I mentioned with the >> patch at the end. This causes the following nice behavior: >> >> 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el >> 2. C-x p p ~/src/emacs/trunk >> 3. f >> 4. M-n and the minibuffer contains "lisp/progmodes/project.el" >> 5. RET and we have now easily switched to the same file in another >> project >> >> Does the implementation seem OK? >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index ac7be8dcbb2..b1e01df5314 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1008,7 +1008,12 @@ project-find-file >> (dirs (list root))) >> (project-find-file-in >> (or (thing-at-point 'filename) >> - buffer-file-name) >> + (and buffer-file-name >> + (if-let (buffer-proj (and project-current-directory-override >> + (project-current nil default-directory))) > But we are going to remove project-current-directory-override in bug#63648 > where default-directory will be changed to next-default-directory. I guess the proposed logic could be reimplemented without using project-current-directory-override -- just based on the changed value of default-directory. And using the parent directory of buffer-file-name. But so far the patch over there is not complete yet, is it? I wouldn't say it's a settled matter so far. > BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 > and then it was deemed to be not too general to handle, so I backed it out > inhttps://debbugs.gnu.org/58447#160 with such conclusion: > > OTOH, `C-x p f M-p' in another project is not my primary workflow. > But if someone wants to keep a plain history, this could be added > later in master, e.g. by a new value of project-read-file-name-function > and a function that is mostly a copy of project--read-file-cpd-relative. > > So maybe this could be implemented in master now? I think the design there was to use relative file names in history? Or a different variable for project file name history (which would use relative names only). I'm not ruling that out, but the patch proposed here is a little more focused. OTOH, it only allows finding the "current" file in the other project, but not other files that were previously visited too. Spencer, what do you think about that capability? Do you also feel it is missing and would like to look into it next? Then the current patch might be the wrong direction. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jun 2023 15:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.168606697020176 (code B ref 63829); Tue, 06 Jun 2023 15:57:01 +0000 Received: (at 63829) by debbugs.gnu.org; 6 Jun 2023 15:56:10 +0000 Received: from localhost ([127.0.0.1]:52855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Z2X-0005FL-Q8 for submit@debbugs.gnu.org; Tue, 06 Jun 2023 11:56:10 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Z2T-0005Em-5f for 63829@debbugs.gnu.org; Tue, 06 Jun 2023 11:56:08 -0400 From: Spencer Baugh In-Reply-To: <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> (Dmitry Gutov's message of "Tue, 6 Jun 2023 04:40:04 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> Date: Tue, 06 Jun 2023 11:55:59 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 04/06/2023 19:36, Juri Linkov wrote: >>> On top of your patch, I can implement the feature I mentioned with the >>> patch at the end. This causes the following nice behavior: >>> >>> 1. Open ~/src/emacs/emacs-29/lisp/progmodes/project.el >>> 2. C-x p p ~/src/emacs/trunk >>> 3. f >>> 4. M-n and the minibuffer contains "lisp/progmodes/project.el" >>> 5. RET and we have now easily switched to the same file in another >>> project >>> >>> Does the implementation seem OK? >>> >>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >>> index ac7be8dcbb2..b1e01df5314 100644 >>> --- a/lisp/progmodes/project.el >>> +++ b/lisp/progmodes/project.el >>> @@ -1008,7 +1008,12 @@ project-find-file >>> (dirs (list root))) >>> (project-find-file-in >>> (or (thing-at-point 'filename) >>> - buffer-file-name) >>> + (and buffer-file-name >>> + (if-let (buffer-proj (and project-current-directory-override >>> + (project-current nil default-directory))) >> But we are going to remove project-current-directory-override in bug#63648 >> where default-directory will be changed to next-default-directory. > > I guess the proposed logic could be reimplemented without using > project-current-directory-override -- just based on the changed value > of default-directory. And using the parent directory of > buffer-file-name. > > But so far the patch over there is not complete yet, is it? I wouldn't > say it's a settled matter so far. Yes, I expect there are any number of alternative implementation strategies, I'm not at all tied to using project-current-directory-override. Happy to port to whatever approach we end up with. >> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >> and then it was deemed to be not too general to handle, so I backed it out >> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >> OTOH, `C-x p f M-p' in another project is not my primary >> workflow. >> But if someone wants to keep a plain history, this could be added >> later in master, e.g. by a new value of project-read-file-name-function >> and a function that is mostly a copy of project--read-file-cpd-relative. >> So maybe this could be implemented in master now? > > I think the design there was to use relative file names in history? Or > a different variable for project file name history (which would use > relative names only). I'm not ruling that out, but the patch proposed > here is a little more focused. > > OTOH, it only allows finding the "current" file in the other project, > but not other files that were previously visited too. Spencer, what do > you think about that capability? Do you also feel it is missing and > would like to look into it next? Then the current patch might be the > wrong direction. Hm, the main thing I want is to make it very easy to visit the current file in another project - I am frequently getting user requests for that feature. (Mainly because our workflow heavily uses a "git worktree" equivalent, where users have one project for each bug/branch they're working on, all with basically the same layout, so "visit the same file in a different project" is also "visit the same file in a different branch", which is often useful. (I actually might work on some code to help implement the same kind of workflow for Emacs development, one worktree per bug/branch)) I'm not sure I understand the alternative - the idea would be to share project file name history between all projects? I guess that could be nice, although I don't personally use file name history that much, and AFAIK it wouldn't solve any concrete user problems, so I'm not really motivated to implement it. However, if we did share project file name history in that way, I'd want to still automatically prepend the "current file" as history. Even if we didn't navigate to the current file via project-find-file, I still want to make it very easy to visit the current file in another project. Just sharing project file name history doesn't provide that. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Aug 2023 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169166896529193 (code B ref 63829); Thu, 10 Aug 2023 12:03:02 +0000 Received: (at 63829) by debbugs.gnu.org; 10 Aug 2023 12:02:45 +0000 Received: from localhost ([127.0.0.1]:41594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU4NJ-0007am-4B for submit@debbugs.gnu.org; Thu, 10 Aug 2023 08:02:45 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:49522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU4NF-0007aV-Sz for 63829@debbugs.gnu.org; Thu, 10 Aug 2023 08:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=biuNuXK98EppuooOTjC4QAiktPJ6Rj04bdu7Q/u6nJY=; b=0oNPEpuCFABlArfJd1wpRJBPUrcUYJylpnmWTRWgDKF0q0CmkqLPm60Ro7/bUjWlVWzO oBCrbkaD1c3ZsxofBzhSnjrHVi77tHh10lkZDJQ3GSklNw9W9gcbSRuycItJEVgLgrOsbv XwU1neGJenEfOB9qDQ7QVsWnc7eqvJ5tjKO71kwrlAWIlqZCVgsHAnqaXZZ1ErDAr0Ct6M Jny1ttNCQ595+aLDKLueykJNcegjqPTKpg5izGS0kvtCpAlsYG1jpXBulUv4GecPuIGvNa UJ6dcUQSFl4Qj6R5fZD5IWIsViNpZgODWHoxZ8fAuvB6jMWq8Ass195cT3LsQPeA== Received: by filterdrecv-d7bbbc8bf-n6gsj with SMTP id filterdrecv-d7bbbc8bf-n6gsj-1-64D4D1DC-1B 2023-08-10 12:02:36.138462616 +0000 UTC m=+7906969.641822867 Received: from earth.catern.com (unknown) by geopod-ismtpd-33 (SG) with ESMTP id jxMDA152R2uj_OCvQKY2lw Thu, 10 Aug 2023 12:02:36.050 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=janestreet.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id BEF3860094; Thu, 10 Aug 2023 08:02:35 -0400 (EDT) From: sbaugh@catern.com In-Reply-To: (Spencer Baugh's message of "Tue, 06 Jun 2023 11:55:59 -0400") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> Date: Thu, 10 Aug 2023 12:02:36 +0000 (UTC) Message-ID: <87jzu3hzqc.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbKfaTKFrn6EdLgwHYvpabjPrQRvxFkaHuyoqJr5pRG2C/MLA4tac2xWnmFwFT+Bd8Qz+gu8peWcOsY5S4p2MGhrLuoMiGGyTKwNadHRNd21R+KUnYCWCzqBHfT7VmLSSNiJht16PPz5PgnU8K1odqLSq+nch1VmjQQdeiyWtqecLw== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Spencer Baugh writes: > Dmitry Gutov writes: >> I think the design there was to use relative file names in history? Or >> a different variable for project fi [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.154.232 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.0 T_SCC_BODY_TEXT_LINE No description available. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Spencer Baugh writes: > Dmitry Gutov writes: >> I think the design there was to use relative file names in history? Or >> a different variable for project file name history (which would use >> relative names only). I'm not ruling that out, but the patch proposed >> here is a little more focused. >> >> OTOH, it only allows finding the "current" file in the other project, >> but not other files that were previously visited too. Spencer, what do >> you think about that capability? Do you also feel it is missing and >> would like to look into it next? Then the current patch might be the >> wrong direction. > > Hm, the main thing I want is to make it very easy to visit the current > file in another project - I am frequently getting user requests for that > feature. (Mainly because our workflow heavily uses a "git worktree" > equivalent, where users have one project for each bug/branch they're > working on, all with basically the same layout, so "visit the same file > in a different project" is also "visit the same file in a different > branch", which is often useful. (I actually might work on some code to > help implement the same kind of workflow for Emacs development, one > worktree per bug/branch)) > > I'm not sure I understand the alternative - the idea would be to share > project file name history between all projects? I guess that could be > nice, although I don't personally use file name history that much, and > AFAIK it wouldn't solve any concrete user problems, so I'm not really > motivated to implement it. > > However, if we did share project file name history in that way, I'd want > to still automatically prepend the "current file" as history. Even if > we didn't navigate to the current file via project-find-file, I still > want to make it very easy to visit the current file in another project. > Just sharing project file name history doesn't provide that. Any thoughts about this and my earlier patch? I still am interested in providing this feature. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Aug 2023 01:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169180341029988 (code B ref 63829); Sat, 12 Aug 2023 01:24:02 +0000 Received: (at 63829) by debbugs.gnu.org; 12 Aug 2023 01:23:30 +0000 Received: from localhost ([127.0.0.1]:48304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUdLl-0007nb-A5 for submit@debbugs.gnu.org; Fri, 11 Aug 2023 21:23:29 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:56089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qUdLh-0007nJ-Hq for 63829@debbugs.gnu.org; Fri, 11 Aug 2023 21:23:28 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9D2A932003F4; Fri, 11 Aug 2023 21:23:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 11 Aug 2023 21:23:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1691803398; x=1691889798; bh=ctXOz0Crg7LjzdSVfxe/CIrN9BMW0Bj0Jgu MQ9Z4Pts=; b=JlIzDObkn+wZrGSz6ZnxRWHsVJ483dSoRhEDoxFRhO/m3WRSOjg x7gWmL9M+uG8S2cFGSq6P9tMjcdMkU6qdgtmyBW7gJ+EH7H8ryRuvSuyNYEmmk9R Mi1nhQLE8UTVBf5O9Yq48NwEhAgN+u9E87ARKeLlAivO5nzYu55iFNjNl6RSQSFm ED9pp/rqL6STTDi3x8XZaH5aKvH9rpklcp9irRIpAQiLNXdEfmZLvHribJakmGSp dUwVyNlDoeUQmenFYSkepPU9paQ1ftHfRds9EtCLSjcZpod8qPCqeA8giQomiOkz 3cj7hoDutiSOOTHzvb4Hn0iAQwdyMbvCa0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691803398; x=1691889798; bh=ctXOz0Crg7LjzdSVfxe/CIrN9BMW0Bj0Jgu MQ9Z4Pts=; b=Z3iU2XLjvpW4YCr2cNkv2pdWtBc3g7ADPfDmLy8Tz9VS9Zaf0Ak xT9NJeFbBm67awRwU1VwAsxp8HjXlbBX2285AQYh65WtTaZQA6FXFk26pNgnX0k4 fvpLTXyNIdP3xDWdMv4nB9u476uzor+dkz/cnmS4rg4YHSO3Jv1bo39NHNe/1HvO HcuOvOcEkxqBGZkNjfd1R4mY72QS9dosGV0uSJWQLR+orx53SkH/+rrI+4vMwsXl y1DTXCrxz8xF+k8GzV5PaKM011mFPQ971mrdVoAKNs7SS8p4LNwTHDB7ORy2TCaR yl2K7sfl5sD3ttsYDgd55TzzP50PSrr6ZHw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleelgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedvvdej leenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Aug 2023 21:23:16 -0400 (EDT) Message-ID: Date: Sat, 12 Aug 2023 04:23:14 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) Hi Spencer, Thanks for the ping. On 06/06/2023 18:55, Spencer Baugh wrote: >> But so far the patch over there is not complete yet, is it? I wouldn't >> say it's a settled matter so far. > > Yes, I expect there are any number of alternative implementation > strategies, I'm not at all tied to using > project-current-directory-override. Happy to port to whatever approach > we end up with. Notes: - We're still using project-current-directory-override, not migrated to anything else yet. - I've pushed my earlier patch which should fix the immediate bug as reported. Let's talk about yours a little bit more. I'm a little wary of adding a specialized feature this way (being able to visit the file corresponding to the current one only), but that patch might be the most optimal still. >>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >>> and then it was deemed to be not too general to handle, so I backed it out >>> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >>> OTOH, `C-x p f M-p' in another project is not my primary >>> workflow. >>> But if someone wants to keep a plain history, this could be added >>> later in master, e.g. by a new value of project-read-file-name-function >>> and a function that is mostly a copy of project--read-file-cpd-relative. >>> So maybe this could be implemented in master now? >> >> I think the design there was to use relative file names in history? Or >> a different variable for project file name history (which would use >> relative names only). I'm not ruling that out, but the patch proposed >> here is a little more focused. >> >> OTOH, it only allows finding the "current" file in the other project, >> but not other files that were previously visited too. Spencer, what do >> you think about that capability? Do you also feel it is missing and >> would like to look into it next? Then the current patch might be the >> wrong direction. > > Hm, the main thing I want is to make it very easy to visit the current > file in another project - I am frequently getting user requests for that > feature. (Mainly because our workflow heavily uses a "git worktree" > equivalent, where users have one project for each bug/branch they're > working on, all with basically the same layout, so "visit the same file > in a different project" is also "visit the same file in a different > branch", which is often useful. (I actually might work on some code to > help implement the same kind of workflow for Emacs development, one > worktree per bug/branch)) I suppose one other way to do that would be to create a dedicated command just for that. But that's a little clunkier -- would require a separate binding. > I'm not sure I understand the alternative - the idea would be to share > project file name history between all projects? I guess that could be > nice, although I don't personally use file name history that much, and > AFAIK it wouldn't solve any concrete user problems, so I'm not really > motivated to implement it. The alternative is a little more general, e.g. propertize every such history entry with the value of the root, so that they can be post-processed to adapt to any other root directory. This shouldn't take too much work, actually. But I don't know if that is indeed a necessary feature. From the discussion (https://debbugs.gnu.org/58447), I had been under impression that it would be wanted, but it might be just "nice to have". Juri, are *you* okay with the functionality in Spencer's patch? No need for further generality? > However, if we did share project file name history in that way, I'd want > to still automatically prepend the "current file" as history. Even if > we didn't navigate to the current file via project-find-file, I still > want to make it very easy to visit the current file in another project. > Just sharing project file name history doesn't provide that. Fair point. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 20:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16920439575990 (code B ref 63829); Mon, 14 Aug 2023 20:13:01 +0000 Received: (at 63829) by debbugs.gnu.org; 14 Aug 2023 20:12:37 +0000 Received: from localhost ([127.0.0.1]:34471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVdvZ-0001YY-8t for submit@debbugs.gnu.org; Mon, 14 Aug 2023 16:12:37 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:33625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVdvX-0001YI-4W for 63829@debbugs.gnu.org; Mon, 14 Aug 2023 16:12:36 -0400 From: Spencer Baugh In-Reply-To: (Dmitry Gutov's message of "Sat, 12 Aug 2023 04:23:14 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> Date: Mon, 14 Aug 2023 16:12:28 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Hi Spencer, > > Thanks for the ping. > > On 06/06/2023 18:55, Spencer Baugh wrote: > >>> But so far the patch over there is not complete yet, is it? I wouldn't >>> say it's a settled matter so far. >> Yes, I expect there are any number of alternative implementation >> strategies, I'm not at all tied to using >> project-current-directory-override. Happy to port to whatever approach >> we end up with. > > Notes: > > - We're still using project-current-directory-override, not migrated > to anything else yet. > - I've pushed my earlier patch which should fix the immediate bug as > reported. > > Let's talk about yours a little bit more. I'm a little wary of adding > a specialized feature this way (being able to visit the file > corresponding to the current one only), but that patch might be the > most optimal still. > >>>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >>>> and then it was deemed to be not too general to handle, so I backed it out >>>> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >>>> OTOH, `C-x p f M-p' in another project is not my primary >>>> workflow. >>>> But if someone wants to keep a plain history, this could be added >>>> later in master, e.g. by a new value of project-read-file-name-function >>>> and a function that is mostly a copy of project--read-file-cpd-relative. >>>> So maybe this could be implemented in master now? >>> >>> I think the design there was to use relative file names in history? Or >>> a different variable for project file name history (which would use >>> relative names only). I'm not ruling that out, but the patch proposed >>> here is a little more focused. >>> >>> OTOH, it only allows finding the "current" file in the other project, >>> but not other files that were previously visited too. Spencer, what do >>> you think about that capability? Do you also feel it is missing and >>> would like to look into it next? Then the current patch might be the >>> wrong direction. >> Hm, the main thing I want is to make it very easy to visit the >> current >> file in another project - I am frequently getting user requests for that >> feature. (Mainly because our workflow heavily uses a "git worktree" >> equivalent, where users have one project for each bug/branch they're >> working on, all with basically the same layout, so "visit the same file >> in a different project" is also "visit the same file in a different >> branch", which is often useful. (I actually might work on some code to >> help implement the same kind of workflow for Emacs development, one >> worktree per bug/branch)) > > I suppose one other way to do that would be to create a dedicated > command just for that. But that's a little clunkier -- would require a > separate binding. > >> I'm not sure I understand the alternative - the idea would be to share >> project file name history between all projects? I guess that could be >> nice, although I don't personally use file name history that much, and >> AFAIK it wouldn't solve any concrete user problems, so I'm not really >> motivated to implement it. > > The alternative is a little more general, e.g. propertize every such > history entry with the value of the root, so that they can be > post-processed to adapt to any other root directory. > > This shouldn't take too much work, actually. But I don't know if that > is indeed a necessary feature. From the discussion > (https://debbugs.gnu.org/58447), I had been under impression that it > would be wanted, but it might be just "nice to have". I would be happy to do that. That sounds very cool actually. Can you elaborate on how exactly you imagine this happening? I guess, every time someone enters a filename with project-find-file or project-find-dir, we would include a propertized version of that filename in file-name-history? And then we would re-relativize them and adapt them to the current project when including them as history? And also, we'd always prepend the current file as "future history", propertized in this way? > Juri, are *you* okay with the functionality in Spencer's patch? No > need for further generality? > >> However, if we did share project file name history in that way, I'd want >> to still automatically prepend the "current file" as history. Even if >> we didn't navigate to the current file via project-find-file, I still >> want to make it very easy to visit the current file in another project. >> Just sharing project file name history doesn't provide that. > > Fair point. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Aug 2023 22:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169205324221000 (code B ref 63829); Mon, 14 Aug 2023 22:48:01 +0000 Received: (at 63829) by debbugs.gnu.org; 14 Aug 2023 22:47:22 +0000 Received: from localhost ([127.0.0.1]:34576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVgLJ-0005Sd-GK for submit@debbugs.gnu.org; Mon, 14 Aug 2023 18:47:22 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:16352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qVgLG-0005SO-QQ for 63829@debbugs.gnu.org; Mon, 14 Aug 2023 18:47:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=MOrtePnEZtD4TfJ++8R09Hkjf/k36FEzJ9EeRgL8dWc=; b=K3Bsrp6Ul7v3+2LJzgg8hI6DuIhJ91T/GnnAtXEdLUtEK0eUH1EB0GTMMn8pWTzQlQg1 IysMudgAZrMrKSRUkUu8iUvmBGsqKBvMNPM++ysG/o9YvrdkXp81XYOKnRKjf+lnXqRp74 gLQZQUdIHmqmgKXpFZM/iSlGxSTm6fZ1N8mcKWKlnt4XOE80QcqcJxQeA/7sKaQSYcdaDv TYShWcGQGTQpc9gUAu2TXa84cKNTCZJG75huHLe8L0L2QCYu9KJeeYjzz5mz6JGQkU0a8V nBprYxt3+9/KS1leM9Q3vfEnHP1v4I3o6JGnU3SMId3zuJR9dfR35TQJWjotIeKw== Received: by filterdrecv-77869f68cc-gch4b with SMTP id filterdrecv-77869f68cc-gch4b-1-64DAAEF0-15 2023-08-14 22:47:12.861442738 +0000 UTC m=+8291472.021926090 Received: from earth.catern.com (unknown) by geopod-ismtpd-13 (SG) with ESMTP id ubcR7YYMRlG3meaG0IfCCQ Mon, 14 Aug 2023 22:47:12.779 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=janestreet.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id EDB5060080; Mon, 14 Aug 2023 18:47:11 -0400 (EDT) From: sbaugh@catern.com In-Reply-To: (Spencer Baugh's message of "Mon, 14 Aug 2023 16:12:28 -0400") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> Date: Mon, 14 Aug 2023 22:47:12 +0000 (UTC) Message-ID: <87a5uti6mo.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbJYVy14zYI25XyfifNLZozEb4TdW2tr+r64ip47F+ZM5OSbNy8pzvINtE0+0hOSA20EyAYWcLHlfEQ9VgTS3jy8BFCR7pE7yfB+Iv212HCTzPYyq+JGnikL+P9i5/5XhKEKwyQneocrUWj4eXsljlV4Jy3qJj/aqJBoC7KhApWv9g== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > Dmitry Gutov writes: > >> Hi Spencer, >> >> Thanks for the ping. >> >> On 06/06/2023 18:55, Spencer Baugh wrote: >> >>>> But so far the patch over there is not complete yet, is it? I wouldn't >>>> say it's a settled matter so far. >>> Yes, I expect there are any number of alternative implementation >>> strategies, I'm not at all tied to using >>> project-current-directory-override. Happy to port to whatever approach >>> we end up with. >> >> Notes: >> >> - We're still using project-current-directory-override, not migrated >> to anything else yet. >> - I've pushed my earlier patch which should fix the immediate bug as >> reported. >> >> Let's talk about yours a little bit more. I'm a little wary of adding >> a specialized feature this way (being able to visit the file >> corresponding to the current one only), but that patch might be the >> most optimal still. >> >>>>> BTW, I asked about this before inhttps://debbugs.gnu.org/58447#127 >>>>> and then it was deemed to be not too general to handle, so I backed it out >>>>> inhttps://debbugs.gnu.org/58447#160 with such conclusion: >>>>> OTOH, `C-x p f M-p' in another project is not my primary >>>>> workflow. >>>>> But if someone wants to keep a plain history, this could be added >>>>> later in master, e.g. by a new value of project-read-file-name-function >>>>> and a function that is mostly a copy of project--read-file-cpd-relative. >>>>> So maybe this could be implemented in master now? >>>> >>>> I think the design there was to use relative file names in history? Or >>>> a different variable for project file name history (which would use >>>> relative names only). I'm not ruling that out, but the patch proposed >>>> here is a little more focused. >>>> >>>> OTOH, it only allows finding the "current" file in the other project, >>>> but not other files that were previously visited too. Spencer, what do >>>> you think about that capability? Do you also feel it is missing and >>>> would like to look into it next? Then the current patch might be the >>>> wrong direction. >>> Hm, the main thing I want is to make it very easy to visit the >>> current >>> file in another project - I am frequently getting user requests for that >>> feature. (Mainly because our workflow heavily uses a "git worktree" >>> equivalent, where users have one project for each bug/branch they're >>> working on, all with basically the same layout, so "visit the same file >>> in a different project" is also "visit the same file in a different >>> branch", which is often useful. (I actually might work on some code to >>> help implement the same kind of workflow for Emacs development, one >>> worktree per bug/branch)) >> >> I suppose one other way to do that would be to create a dedicated >> command just for that. But that's a little clunkier -- would require a >> separate binding. >> >>> I'm not sure I understand the alternative - the idea would be to share >>> project file name history between all projects? I guess that could be >>> nice, although I don't personally use file name history that much, and >>> AFAIK it wouldn't solve any concrete user problems, so I'm not really >>> motivated to implement it. >> >> The alternative is a little more general, e.g. propertize every such >> history entry with the value of the root, so that they can be >> post-processed to adapt to any other root directory. >> >> This shouldn't take too much work, actually. But I don't know if that >> is indeed a necessary feature. From the discussion >> (https://debbugs.gnu.org/58447), I had been under impression that it >> would be wanted, but it might be just "nice to have". > > I would be happy to do that. That sounds very cool actually. > > Can you elaborate on how exactly you imagine this happening? I guess, > every time someone enters a filename with project-find-file or > project-find-dir, we would include a propertized version of that > filename in file-name-history? And then we would re-relativize them and > adapt them to the current project when including them as history? Okay, I did that. Extremely rough patch follows. Btw, the reason I'm interested in this shared project history is because our workflow involves creating many new projects (one per branch); so mostly each project has no history at all, and sharing history between projects is the only way to get any. But, it seems to me that this doesn't really help with having the current file be "future history". That's still useful when switching between similar projects. And all the logic of my other patch which does that, is still required with this patch. diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 78f9fb410c1..5752f26d229 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1028,6 +1028,12 @@ project-read-file-name-function :group 'project :version "27.1") +(defun project--expand-file-name (filename project) + (when-let ((old-pr (get-text-property 0 'project filename))) + (expand-file-name + (file-relative-name filename (project-root old-pr)) + (project-root project)))) + (defun project--read-file-cpd-relative (prompt all-files &optional predicate hist mb-default) @@ -1038,7 +1044,8 @@ project--read-file-cpd-relative MB-DEFAULT is used as part of \"future history\", to be inserted by the user at will." - (let* ((common-parent-directory + (let* ((project (project-current t)) + (common-parent-directory (let ((common-prefix (try-completion "" all-files))) (if (> (length common-prefix) 0) (file-name-directory common-prefix)))) @@ -1060,6 +1067,7 @@ project--read-file-cpd-relative ((symbol-value hist) (mapcan (lambda (s) + (setq s (or (abbreviate-file-name (project--expand-file-name s project)) s)) (and (string-prefix-p abbr-cpd s) (not (eq abbr-cpd-length (length s))) (list (substring s abbr-cpd-length)))) @@ -1070,7 +1078,9 @@ project--read-file-cpd-relative hist mb-default))) (absname (expand-file-name relname common-parent-directory))) (when (and hist history-add-new-input) - (add-to-history hist (abbreviate-file-name absname))) + (add-to-history hist (propertize + (abbreviate-file-name absname) + 'project project))) absname)) (defun project--read-file-absolute (prompt From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 01:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@catern.com, Spencer Baugh Cc: 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16921506098717 (code B ref 63829); Wed, 16 Aug 2023 01:51:01 +0000 Received: (at 63829) by debbugs.gnu.org; 16 Aug 2023 01:50:09 +0000 Received: from localhost ([127.0.0.1]:38446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW5fk-0002GX-RQ for submit@debbugs.gnu.org; Tue, 15 Aug 2023 21:50:09 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:52965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW5fi-0002Fm-Fz for 63829@debbugs.gnu.org; Tue, 15 Aug 2023 21:50:07 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C62B65C0338; Tue, 15 Aug 2023 21:50:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 15 Aug 2023 21:50:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692150600; x=1692237000; bh=5xTRvPalSi+SBJ15QIoYxSf+MXESh9NqPxn mddYKbL0=; b=CTBjcV8B7ccQ/kBfUZi6kxHQrjwxlWQGmtKczYRTxhKjTonqPZp N9HmVeB2MOhwCq4LxXD0XJFGAn3WxkA51XtoXTmXQR62Dx+tQoCGeZl0XY6Re78K vY89QZqI8nLBC6kGYFATWaP21M00xUA6mqMwtHoiE8vdgbtEpZhnqnjbdorvD+3J ddWQjtUrmzch8c4r4MHivg1BfeOEXyX+AdIoapcmar+F037ovEnyajjLUg580Uf0 CoYkjF8FPtphj9boelAqheDv5HwaWBcd0TltkfAJrYXxZIk/WDk2m9EhQpyVs0Xc M2380xaz6uInLUFj7iuQhraOiggpDKAMAfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692150600; x=1692237000; bh=5xTRvPalSi+SBJ15QIoYxSf+MXESh9NqPxn mddYKbL0=; b=iK+t20tkzsFpTVJyzcd4aZ9nsk65zsOc0m2XOVE0wOm8dhOQXiL jA0V24nqRUHvmY9Yva+Cb/y7xHIFMhoFe39zhA7bzhE3L9AocIQORIME/Fe3wmPG JwZMGOFR7yD6w57QN9nlSR679Md+RJEdq2+MzXzOFWQ0mplAui7jiyjvZu9HJ+TD oflB8mQvZsmr3Ef2J1H32TfJNUbaY+YUIRSP7UQSUw0tX6a1VktZGXV1rbQjJFss vYxslbPG6N7T46uLY7xNkM+i9OnoeTDpP8M/jXPfhZWH25AJlJ+fcjD8/usHaMtV a0H7sMZ8C0Z1I/BS+DZmNwCCH2fz4NhPHSA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtkedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Aug 2023 21:49:59 -0400 (EDT) Message-ID: <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> Date: Wed, 16 Aug 2023 04:49:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> From: Dmitry Gutov In-Reply-To: <87a5uti6mo.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 15/08/2023 01:47, sbaugh@catern.com wrote: >>>> I'm not sure I understand the alternative - the idea would be to share >>>> project file name history between all projects? I guess that could be >>>> nice, although I don't personally use file name history that much, and >>>> AFAIK it wouldn't solve any concrete user problems, so I'm not really >>>> motivated to implement it. >>> >>> The alternative is a little more general, e.g. propertize every such >>> history entry with the value of the root, so that they can be >>> post-processed to adapt to any other root directory. >>> >>> This shouldn't take too much work, actually. But I don't know if that >>> is indeed a necessary feature. From the discussion >>> (https://debbugs.gnu.org/58447), I had been under impression that it >>> would be wanted, but it might be just "nice to have". >> >> I would be happy to do that. That sounds very cool actually. >> >> Can you elaborate on how exactly you imagine this happening? I guess, >> every time someone enters a filename with project-find-file or >> project-find-dir, we would include a propertized version of that >> filename in file-name-history? And then we would re-relativize them and >> adapt them to the current project when including them as history? > > Okay, I did that. Extremely rough patch follows. Thanks! It's very close to what I was thinking of (modulo some cosmetics and perf optimizations). > Btw, the reason I'm interested in this shared project history is because > our workflow involves creating many new projects (one per branch); so > mostly each project has no history at all, and sharing history between > projects is the only way to get any. Now that you can have this additional capability as an option, do you think you will be using it as well? > But, it seems to me that this doesn't really help with having the > current file be "future history". That's still useful when switching > between similar projects. And all the logic of my other patch which > does that, is still required with this patch. Indeed, that's a good point. So I think we'll install your first patch either way. Before we do that, small (or not so small) question: do you think we should test that the current buffer exists in the other project too? We could do that with file-exists-p (but that's an extra round-trip over Tramp), or by checking against the full list like in below. Relatedly, with the cross-project history, we should ask the same question: will we check that the "transplanted" history entries correspond to existing files in the other project (and filter out those that don't). WDYT? diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index d8b12c9c880..a32bc2dd8d3 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1116,7 +1116,10 @@ project-find-file-in (completion-ignore-case read-file-name-completion-ignore-case) (file (funcall project-read-file-name-function "Find file" all-files nil 'file-name-history - suggested-filename))) + (if (file-name-absolute-p suggested-filename) + (and (member suggested-filename all-files) + suggested-filename) + suggested-filename)))) (if (string= file "") (user-error "You didn't specify the file") (find-file file)))) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Aug 2023 02:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Spencer Baugh , Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169215464915112 (code B ref 63829); Wed, 16 Aug 2023 02:58:02 +0000 Received: (at 63829) by debbugs.gnu.org; 16 Aug 2023 02:57:29 +0000 Received: from localhost ([127.0.0.1]:38513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW6iu-0003vf-P3 for submit@debbugs.gnu.org; Tue, 15 Aug 2023 22:57:29 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:32854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qW6iq-0003vP-89 for 63829@debbugs.gnu.org; Tue, 15 Aug 2023 22:57:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=gvSweho3ui0qBBft6GoIP8WG893ZTVBvCqBL8WdFow8=; b=etAS/yQ/X+KXU4HZvHu/yYqjBC3IXRo3LVZTtxRv6UwwHPXvRhry17j4Cabvgpm/IifC ltg5aZCjqx9qrBa1P8RBdgSokwdqsXUCJ2Xly2j25uHEoY3beG6OFgYdqW/ZrDc8Gw7Frr OFdbFE1fTA+tlLK2zgIUhqkm9ng6IwBbSUXBcef1QkA9tmaOWjIsyspxgIyWozL4Pbrv3+ UZN+cgxJZGtbKQZx1J8buaqfdtSUGAFEuqFA4OCehZBZTywF4MTagVGjiI8ZuvJWGgAepG neZBjDyInNX3AI+2cuN+vOBNMbwuLh2oMvxy+Z8TmtWrC4Kyw7uhlhjvY6Jcs3FA== Received: by filterdrecv-77869f68cc-kmpqh with SMTP id filterdrecv-77869f68cc-kmpqh-1-64DC3B0E-15 2023-08-16 02:57:18.771875764 +0000 UTC m=+8392879.067187345 Received: from earth.catern.com (unknown) by geopod-ismtpd-13 (SG) with ESMTP id Negeix6wRhaKr7yQ7UckhA Wed, 16 Aug 2023 02:57:18.672 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gutov.dev Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 05C8F60155; Tue, 15 Aug 2023 22:57:17 -0400 (EDT) From: sbaugh@catern.com In-Reply-To: <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> (Dmitry Gutov's message of "Wed, 16 Aug 2023 04:49:58 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> Date: Wed, 16 Aug 2023 02:57:18 +0000 (UTC) Message-ID: <875y5fitiq.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbKwY9OkpHA7ZJoTPPRPN7WFzyWwRgn8o5EcFoOV9dJtVvArnnou26AXIooRGLSszh820s1wxxqDgnNSG/hLgbUeSnehhQrQJsWuMva2PrMKIJnPtLhXt8AyYcuXc/oIOBOkXpph5Ni3ab0BhG3xmAU3TP4VTPtKUS1XJY8OWKppjw== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > On 15/08/2023 01:47, sbaugh@catern.com wrote: > >>>>> I'm not sure I understand the alternative - the idea would be to share >>>>> project file name history b [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.123.24 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Dmitry Gutov writes: > On 15/08/2023 01:47, sbaugh@catern.com wrote: > >>>>> I'm not sure I understand the alternative - the idea would be to share >>>>> project file name history between all projects? I guess that could be >>>>> nice, although I don't personally use file name history that much, and >>>>> AFAIK it wouldn't solve any concrete user problems, so I'm not really >>>>> motivated to implement it. >>>> >>>> The alternative is a little more general, e.g. propertize every such >>>> history entry with the value of the root, so that they can be >>>> post-processed to adapt to any other root directory. >>>> >>>> This shouldn't take too much work, actually. But I don't know if that >>>> is indeed a necessary feature. From the discussion >>>> (https://debbugs.gnu.org/58447), I had been under impression that it >>>> would be wanted, but it might be just "nice to have". >>> >>> I would be happy to do that. That sounds very cool actually. >>> >>> Can you elaborate on how exactly you imagine this happening? I guess, >>> every time someone enters a filename with project-find-file or >>> project-find-dir, we would include a propertized version of that >>> filename in file-name-history? And then we would re-relativize them and >>> adapt them to the current project when including them as history? >> Okay, I did that. Extremely rough patch follows. > > Thanks! It's very close to what I was thinking of (modulo some > cosmetics and perf optimizations). > >> Btw, the reason I'm interested in this shared project history is because >> our workflow involves creating many new projects (one per branch); so >> mostly each project has no history at all, and sharing history between >> projects is the only way to get any. > > Now that you can have this additional capability as an option, do you > think you will be using it as well? Yes, probably I will enable this shared project history mode for my users. >> But, it seems to me that this doesn't really help with having the >> current file be "future history". That's still useful when switching >> between similar projects. And all the logic of my other patch which >> does that, is still required with this patch. > > Indeed, that's a good point. So I think we'll install your first patch > either way. > > Before we do that, small (or not so small) question: do you think we > should test that the current buffer exists in the other project too? > We could do that with file-exists-p (but that's an extra round-trip > over Tramp), or by checking against the full list like in below. No, I don't think that's necessary. It produces more consistent behavior to not check whether the file exists. And anyway, it could maybe be helpful to be able to create the same file in another project. > Relatedly, with the cross-project history, we should ask the same > question: will we check that the "transplanted" history entries > correspond to existing files in the other project (and filter out > those that don't). Likewise I don't think that's necessary. Although it might be nice to support a user-supplied predicate which, given the current project and a path in the history (which contains as a property the originating project), determines whether to show that path. Then the user could filter the history to only paths in "sibling projects" with similar content. Not required though. > WDYT? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index d8b12c9c880..a32bc2dd8d3 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1116,7 +1116,10 @@ project-find-file-in > (completion-ignore-case read-file-name-completion-ignore-case) > (file (funcall project-read-file-name-function > "Find file" all-files nil 'file-name-history > - suggested-filename))) > + (if (file-name-absolute-p suggested-filename) > + (and (member suggested-filename all-files) > + suggested-filename) > + suggested-filename)))) > (if (string= file "") > (user-error "You didn't specify the file") > (find-file file)))) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Aug 2023 02:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@catern.com Cc: Spencer Baugh , Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16922384569140 (code B ref 63829); Thu, 17 Aug 2023 02:15:02 +0000 Received: (at 63829) by debbugs.gnu.org; 17 Aug 2023 02:14:16 +0000 Received: from localhost ([127.0.0.1]:42401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWSWd-0002NL-EV for submit@debbugs.gnu.org; Wed, 16 Aug 2023 22:14:15 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWSWb-0002N4-0V for 63829@debbugs.gnu.org; Wed, 16 Aug 2023 22:14:14 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AB5395C00BA; Wed, 16 Aug 2023 22:14:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 16 Aug 2023 22:14:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692238447; x=1692324847; bh=EnMBQH6omlO9XT7McfPgrqBaUygSM2GlmEN fpCTV0KA=; b=Ew4uvdKIFTeaWjrsjln5c0mGxXTJ6Btrg5f54GG15MvyUCYU2eU YLlWX4kc8Ve0eTI93x6EZhnj1KiTUDFcdQvwpdERa5OR0fz1Wam2OEuwvmWZ+PoX 5RlPl/eKVvFihEbgzZCBWu6jUSIJyq3CtbQTQF13rCOHuu/oqsTIlSlyNPgHTARR iqq2DGm6CB5eVOZUCFoJiAdYUQct9lYBfUsbizwY/TpcUsQ5S8Y284OzNiLybwTx Iw2kgqDYRv9cxs+EKSrjbttF6zM5rCi9LCv/te6ovH0A3h2phnDJe/P9Mhx2OwUk IF9lXhWrTUojRB63IoOj973zGMKiYzVH3QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692238447; x=1692324847; bh=EnMBQH6omlO9XT7McfPgrqBaUygSM2GlmEN fpCTV0KA=; b=X5B1Xr0zAXmlDBHWay94uxc8xrn2mR7UdT1x7Ph34a0PnYGaB1K LGTDty9AGowPQxJr/4FdwrQrSsdWCFnbBrNGeikplvfNscSBJnQMBVIJGCy3doTM pc9HbsjFiPtguux3U2AmSOPxhiATnjpCbDgDiPRqsAx/nRsFn7HGbdokjMQEJ168 og0dmSi/we0MpxuTmb4ZRmD+h6NzaU74/MZW69KcFQXbHps5vTLBIHZ3UWXHJn/p di6zKRwmpkto8rGDZ22c8aLYZu7lABdf5OdtnCXmVtNB0ja5lDQYZq1OAGO5eLZI ipnCpWdJsvpM8ZJWqRfvhuq8gyVdY9vpq7Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddutddgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Aug 2023 22:14:06 -0400 (EDT) Message-ID: Date: Thu, 17 Aug 2023 05:14:03 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> From: Dmitry Gutov In-Reply-To: <875y5fitiq.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 16/08/2023 05:57, sbaugh@catern.com wrote: >> Now that you can have this additional capability as an option, do you >> think you will be using it as well? > > Yes, probably I will enable this shared project history mode for my > users. Nice. >> Before we do that, small (or not so small) question: do you think we >> should test that the current buffer exists in the other project too? >> We could do that with file-exists-p (but that's an extra round-trip >> over Tramp), or by checking against the full list like in below. > > No, I don't think that's necessary. It produces more consistent > behavior to not check whether the file exists. And anyway, it could > maybe be helpful to be able to create the same file in another project. Fair point. Creating new files it is, then. >> Relatedly, with the cross-project history, we should ask the same >> question: will we check that the "transplanted" history entries >> correspond to existing files in the other project (and filter out >> those that don't). > > Likewise I don't think that's necessary. > > Although it might be nice to support a user-supplied predicate which, > given the current project and a path in the history (which contains as a > property the originating project), determines whether to show that path. > Then the user could filter the history to only paths in "sibling > projects" with similar content. Not required though. OK, we can easily add such a predicate later, if somebody asks. I'm pushed the first of your patches, but the second needed some adjustments. Chiefly because we need to make sure it works with any value of project-read-file-name-function, so the impl can't be concentrated in just one of them. Check out the amended patch below. Any suggestions on how to do it more elegantly (without duplicating the add-to-history call) are welcome too. diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index e1d14474323..d810d8d9605 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1046,6 +1046,13 @@ project-read-file-name-function :group 'project :version "27.1") +(defun project--expand-file-name (filename project) + (when-let ((old-root (get-text-property 0 'project filename))) + (abbreviate-file-name + (expand-file-name + (file-relative-name filename old-root) + (project-root project))))) + (defun project--read-file-cpd-relative (prompt all-files &optional predicate hist mb-default) @@ -1124,9 +1131,18 @@ project-find-file-in dirs) (project-files project dirs))) (completion-ignore-case read-file-name-completion-ignore-case) - (file (funcall project-read-file-name-function - "Find file" all-files nil 'file-name-history - suggested-filename))) + (file + (let ((file-name-history (mapcar + (lambda (f) + (or (project--expand-file-name f project) f)) + file-name-history))) + (funcall project-read-file-name-function + "Find file" all-files nil 'file-name-history + suggested-filename)))) + (when history-add-new-input + ;; Have to re-add it here because of the let-binding above. + (add-to-history 'file-name-history + (propertize file 'project (project-root project)))) (if (string= file "") (user-error "You didn't specify the file") (find-file file)))) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Aug 2023 19:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169230131620672 (code B ref 63829); Thu, 17 Aug 2023 19:42:01 +0000 Received: (at 63829) by debbugs.gnu.org; 17 Aug 2023 19:41:56 +0000 Received: from localhost ([127.0.0.1]:45661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWisW-0005NL-0C for submit@debbugs.gnu.org; Thu, 17 Aug 2023 15:41:56 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:39931) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWisU-0005N3-8M for 63829@debbugs.gnu.org; Thu, 17 Aug 2023 15:41:55 -0400 From: Spencer Baugh In-Reply-To: (Dmitry Gutov's message of "Thu, 17 Aug 2023 05:14:03 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Thu, 17 Aug 2023 15:41:47 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Dmitry Gutov writes: > I'm pushed the first of your patches, but the second needed some > adjustments. Chiefly because we need to make sure it works with any > value of project-read-file-name-function, so the impl can't be > concentrated in just one of them. > > Check out the amended patch below. Any suggestions on how to do it > more elegantly (without duplicating the add-to-history call) are > welcome too. > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index e1d14474323..d810d8d9605 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1046,6 +1046,13 @@ project-read-file-name-function > :group 'project > :version "27.1") > > +(defun project--expand-file-name (filename project) > + (when-let ((old-root (get-text-property 0 'project filename))) > + (abbreviate-file-name > + (expand-file-name > + (file-relative-name filename old-root) > + (project-root project))))) > + > (defun project--read-file-cpd-relative (prompt > all-files &optional predicate > hist mb-default) > @@ -1124,9 +1131,18 @@ project-find-file-in > dirs) > (project-files project dirs))) > (completion-ignore-case read-file-name-completion-ignore-case) > - (file (funcall project-read-file-name-function > - "Find file" all-files nil 'file-name-history > - suggested-filename))) > + (file > + (let ((file-name-history (mapcar > + (lambda (f) > + (or (project--expand-file-name > f project) f)) > + file-name-history))) > + (funcall project-read-file-name-function > + "Find file" all-files nil 'file-name-history > + suggested-filename)))) > + (when history-add-new-input > + ;; Have to re-add it here because of the let-binding above. > + (add-to-history 'file-name-history > + (propertize file 'project (project-root project)))) > (if (string= file "") > (user-error "You didn't specify the file") > (find-file file)))) This seems good, sure. But doesn't this make the history entries appear twice? Maybe we should just pull the history-adding functionality out of project-read-file-name-function entirely. I've tried doing that below. Also, I realized just now that this should probably affect project-find-dir as well, as should my previous patch adding project-relative future history. (I actually coincidentally just now got a user request for "switch between projects and stay in the same dir") So here's a revised version of this history change which also affects project-find-dir. In a subsequent mail I'll send a patch for the "future history" behavior of project-find-dir too. (yet to be written) --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-adjusting-file-name-history-to-the-current-p.patch >From 9cb47b7476dfbaf0e9e45001d174da848ebf904d Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Thu, 17 Aug 2023 15:41:04 -0400 Subject: [PATCH] Support adjusting file-name-history to the current project This add project-file-name-history-relativize which has the effect described in its docstring. This implements a sort of sharing of file-name-history between projects. * lisp/progmodes/project.el (project-file-name-history-relativize): Add. (bug#63829) (project--expand-file-name): Add. (project--read-file-cpd-relative): Move history manipulations to project--read-file-name. (project--read-file-name): Add and use project-file-name-history-relativize. (project-find-file-in): Use project--read-file-name. (project-find-dir): Use project--read-file-name. --- lisp/progmodes/project.el | 62 +++++++++++++++++++++++++++++++-------- 1 file changed, 50 insertions(+), 12 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index c1ce5ce7b1f..e0f1f995ff2 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1046,6 +1046,26 @@ project-read-file-name-function :group 'project :version "27.1") +(defcustom project-file-name-history-relativize nil + "If non-nil, paths in `file-name-history' are adjusted for the current project. + +When non-nil and in `project-find-file' or `project-find-dir', +paths in `file-name-history' are adjusted to be relative to +whatever the current project is, instead of the project which +added those paths. This only affects history entries added by +earlier calls to `project-find-file' or `project-find-dir'. + +When `project-read-file-name-function' is +`project--read-file-cpd-relative' (the default), this has the +effect of sharing more history between projects.") + +(defun project--expand-file-name (filename project) + (when-let ((old-root (get-text-property 0 'project filename))) + (abbreviate-file-name + (expand-file-name + (file-relative-name filename old-root) + (project-root project))))) + (defun project--read-file-cpd-relative (prompt all-files &optional predicate hist mb-default) @@ -1079,8 +1099,7 @@ project--read-file-cpd-relative (new-collection (project--file-completion-table substrings)) (abbr-cpd (abbreviate-file-name common-parent-directory)) (abbr-cpd-length (length abbr-cpd)) - (relname (cl-letf ((history-add-new-input nil) - ((symbol-value hist) + (relname (cl-letf (((symbol-value hist) (mapcan (lambda (s) (and (string-prefix-p abbr-cpd s) @@ -1092,8 +1111,6 @@ project--read-file-cpd-relative predicate hist mb-default))) (absname (expand-file-name relname common-parent-directory))) - (when (and hist history-add-new-input) - (add-to-history hist (abbreviate-file-name absname))) absname)) (defun project--read-file-absolute (prompt @@ -1104,6 +1121,26 @@ project--read-file-absolute predicate hist mb-default)) +(defun project--read-file-name (project prompt + all-files &optional predicate + hist mb-default) + "Call `project-read-file-name-function' with project-relative history." + (let ((file + (cl-letf ((history-add-new-input nil) + ((symbol-value hist) + (if project-file-name-history-relativize + (mapcar + (lambda (f) + (or (project--expand-file-name f project) f)) + (symbol-value hist)) + (symbol-value hist)))) + (funcall project-read-file-name-function + prompt all-files predicate hist mb-default)))) + (when (and hist history-add-new-input) + (add-to-history hist + (propertize file 'project (project-root project)))) + file)) + (defun project-find-file-in (suggested-filename dirs project &optional include-all) "Complete a file name in DIRS in PROJECT and visit the result. @@ -1124,9 +1161,10 @@ project-find-file-in dirs) (project-files project dirs))) (completion-ignore-case read-file-name-completion-ignore-case) - (file (funcall project-read-file-name-function - "Find file" all-files nil 'file-name-history - suggested-filename))) + (file (project--read-file-name + project "Find file" + all-files nil 'file-name-history + suggested-filename))) (if (string= file "") (user-error "You didn't specify the file") (find-file file)))) @@ -1158,11 +1196,11 @@ project-find-dir ;; https://stackoverflow.com/a/50685235/615245 for possible ;; implementation. (all-dirs (mapcar #'file-name-directory all-files)) - (dir (funcall project-read-file-name-function - "Dired" - ;; Some completion UIs show duplicates. - (delete-dups all-dirs) - nil 'file-name-history))) + (dir (project--read-file-name + project "Dired" + ;; Some completion UIs show duplicates. + (delete-dups all-dirs) + nil 'file-name-history))) (dired dir))) ;;;###autoload -- 2.39.3 --=-=-=-- From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Aug 2023 20:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@catern.com, Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169230316423836 (code B ref 63829); Thu, 17 Aug 2023 20:13:01 +0000 Received: (at 63829) by debbugs.gnu.org; 17 Aug 2023 20:12:44 +0000 Received: from localhost ([127.0.0.1]:45671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWjMJ-0006CN-OO for submit@debbugs.gnu.org; Thu, 17 Aug 2023 16:12:44 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qWjMF-0006C6-AX for 63829@debbugs.gnu.org; Thu, 17 Aug 2023 16:12:43 -0400 From: Spencer Baugh In-Reply-To: (Spencer Baugh's message of "Thu, 17 Aug 2023 15:41:47 -0400") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Thu, 17 Aug 2023 16:12:33 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Spencer Baugh writes: > In a subsequent mail I'll send a patch for the "future history" > behavior of project-find-dir too. (yet to be written) Here is that. Seems like a straightforward generalization, and something that a user would expect to work. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Use-current-file-name-for-more-other-project-future-.patch >From 48880a795f75d1126a0f235bf57f00f478ee90a0 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Thu, 17 Aug 2023 16:11:01 -0400 Subject: [PATCH] Use current file name for more "other project" future history In commit f38bcf37dc47ce172c985d1c621df3583eaad46c we supported using the current buffer's file name as future history for project-find-file even when switching to another project with project-switch-project. Make this work for project-find-dir and project-or-external-find-file too. * lisp/progmodes/project.el (project--find-default-from): Add. (project-find-file): Use project--find-default-from with buffer-file-name. (project-or-external-find-file): Use project--find-default-from with buffer-file-name. (project-find-dir): Use project--find-default-from with default-directory. --- lisp/progmodes/project.el | 45 +++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index e0f1f995ff2..e0d05d45a55 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -989,6 +989,23 @@ project--read-regexp (read-regexp "Find regexp" (and sym (regexp-quote sym)) project-regexp-history-variable))) +(defun project--find-default-from (filename project) + "Ensure FILENAME is in PROJECT. + +Usually, just return FILENAME. But if +`project-current-directory-override' is set, FILENAME is probably +relative to that project; adjust it to be relative to PROJECT instead. + +This supports using a relative file name from the current buffer +when switching projects with `project-switch-project' and then +using a command like `project-find-file'." + (if-let (filename-proj (and project-current-directory-override + (project-current nil default-directory))) + ;; file-name-concat requires Emacs 28+ + (concat (file-name-as-directory (project-root project)) + (file-relative-name filename (project-root filename-proj))) + filename)) + ;;;###autoload (defun project-find-file (&optional include-all) "Visit a file (with completion) in the current project. @@ -1006,16 +1023,7 @@ project-find-file (dirs (list root))) (project-find-file-in (or (thing-at-point 'filename) - (and buffer-file-name - (if-let (buffer-proj (and project-current-directory-override - (project-current nil default-directory))) - ;; Allow using the relative file name of the current - ;; buffer in "other project" as well. - (let ((buffer-root (project-root buffer-proj))) - ;; file-name-concat requires Emacs 28+ - (concat (file-name-as-directory root) - (file-relative-name buffer-file-name buffer-root))) - buffer-file-name))) + (and buffer-file-name (project--find-default-from buffer-file-name pr))) dirs pr include-all))) ;;;###autoload @@ -1023,7 +1031,8 @@ project-or-external-find-file "Visit a file (with completion) in the current project or external roots. The filename at point (determined by `thing-at-point'), if any, -is available as part of \"future history\". +is available as part of \"future history\". If none, the current +buffer's file name is used. If INCLUDE-ALL is non-nil, or with prefix argument when called interactively, include all files under the project root, except @@ -1033,7 +1042,10 @@ project-or-external-find-file (dirs (cons (project-root pr) (project-external-roots pr)))) - (project-find-file-in (thing-at-point 'filename) dirs pr include-all))) + (project-find-file-in + (or (thing-at-point 'filename) + (and buffer-file-name (project--find-default-from buffer-file-name pr))) + dirs pr include-all))) (defcustom project-read-file-name-function #'project--read-file-cpd-relative "Function to call to read a file name from a list. @@ -1185,7 +1197,10 @@ project--completing-read-strict ;;;###autoload (defun project-find-dir () - "Start Dired in a directory inside the current project." + "Start Dired in a directory inside the current project. + +The current buffer's `default-directory' is available as part of +\"future history\"." (interactive) (let* ((project (project-current t)) (all-files (project-files project)) @@ -1200,7 +1215,9 @@ project-find-dir project "Dired" ;; Some completion UIs show duplicates. (delete-dups all-dirs) - nil 'file-name-history))) + nil 'file-name-history + (and default-directory + (project--find-default-from default-directory project))))) (dired dir))) ;;;###autoload -- 2.39.3 --=-=-=-- From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Aug 2023 20:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, monnier@iro.umontreal.ca, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169239224729033 (code B ref 63829); Fri, 18 Aug 2023 20:58:02 +0000 Received: (at 63829) by debbugs.gnu.org; 18 Aug 2023 20:57:27 +0000 Received: from localhost ([127.0.0.1]:48910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qX6X8-0007YC-Ot for submit@debbugs.gnu.org; Fri, 18 Aug 2023 16:57:27 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:50897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qX6X7-0007Xz-1L for 63829@debbugs.gnu.org; Fri, 18 Aug 2023 16:57:25 -0400 From: Spencer Baugh In-Reply-To: (Spencer Baugh's message of "Thu, 17 Aug 2023 16:12:33 -0400") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Fri, 18 Aug 2023 16:57:18 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) BTW, one more feature in this vein (stealing this idea from Stefan) would be if we automatically moved point to the same location in the other file. That might be a little too magical. But it would be very cool... I guess the ideal thing we'd want is to move point to the same function, which is a bit trickier... could be done with imenu perhaps. Not sure... Maybe the right call would be to have a keybinding in C-x p p like j or something, which would just instantly jump you to the same file in the other project. So you'd just run C-x p p j and that would open the same file in the other project, with point inside the same function (using imenu), at the same offset in that function. That could be helpful for other reasons too: I've often wanted "just put me anywhere in this other project, I don't care where", and this could be that command. Although I suppose mostly I want that because C-x p p isn't currently a generic prefix for any command, and if we convert it to be that (with next-default-directory or something), I won't need that. Alternatively, maybe C-x p j could be an alternative to C-x p p, and when it prompts for a project, it could prompt only for "sibling projects" which have the same file structure. And we could have a built-in way to detect sibling projects: Any other worktree of the current git repository is a sibling project. (And we would make this extensible too of course; maybe have both project-siblings and vc-list-worktrees as extension points) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Aug 2023 02:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16924109338235 (code B ref 63829); Sat, 19 Aug 2023 02:09:01 +0000 Received: (at 63829) by debbugs.gnu.org; 19 Aug 2023 02:08:53 +0000 Received: from localhost ([127.0.0.1]:49106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXBOW-00028k-Ji for submit@debbugs.gnu.org; Fri, 18 Aug 2023 22:08:52 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:47521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXBOU-00028Q-48 for 63829@debbugs.gnu.org; Fri, 18 Aug 2023 22:08:51 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id E6FF23200916; Fri, 18 Aug 2023 22:08:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 18 Aug 2023 22:08:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692410922; x=1692497322; bh=4jdVoRqY9788gBM82ykNVNG60FRxXdGu5QY wBnjbTMU=; b=DRzDIM5/hHE06Ip1fIQApTMuxnzD2sOjTQ0F5DS2GW6k7i12Dz5 QbCvReeB2HqU2j9FL2r2c2/eEUk18PPWFN9MEncCYdGxRXozTXLTkS1Q87HkxYoO zzZy8/9qrNoXIWHXvon/INM/N7+EawV2Ol64XBSST7wDGTX7nJJHnHPo/zEL2+v9 haWxGNmma6iDf9YNhVXdmVmae8DuBnnwiaEXjG5W7AdWlOWuk9emJ6VpFO7aBnY0 qJ2KyOZNhhZ82+x57259m3yRxDtfnVUJna7dL+JoInaQKvWyPHZhMDVQJ1LKN2Pu cg7Ehuq+0EL0Iq7TmnnIuMkAys7YN6dnZ6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692410922; x=1692497322; bh=4jdVoRqY9788gBM82ykNVNG60FRxXdGu5QY wBnjbTMU=; b=d7ngn2BOzQtGRueJgwdb/02mPGo8vbrMxxetiJzL/ILhXfSnivV 4DFeMSwHdnWqnGlA0k612n6m2lfXfiRPQsBTedU6JQ3HusqUMTFqE8MxjQfNdCxd bm2T8dUGqw+pGeufwHd3OtxaLq6xZf2Gi/pMt2UYoadjcR4O32wGtUo+cxfHTbdp JVqwYZMkpBfUuA8YuNWBYSPuuxG2c8x69OGWLNe+pB/EerdD/XeYJ5gr8WOsAIaB nhwRYGESAz4uCtpuM6+q02gxYnHWihUXLB6wnHV9rc/w5X1kqwVP4/iYGnxbmsmK g3WMdW9OELKPX0oZQMUccm6PcHixJE35b0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddugedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Aug 2023 22:08:40 -0400 (EDT) Message-ID: <208300a3-25e1-d057-11ac-179e52b8f547@gutov.dev> Date: Sat, 19 Aug 2023 05:08:38 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 17/08/2023 22:41, Spencer Baugh wrote: > Dmitry Gutov writes: >> - (file (funcall project-read-file-name-function >> - "Find file" all-files nil 'file-name-history >> - suggested-filename))) >> + (file >> + (let ((file-name-history (mapcar >> + (lambda (f) >> + (or (project--expand-file-name >> f project) f)) >> + file-name-history))) >> + (funcall project-read-file-name-function >> + "Find file" all-files nil 'file-name-history >> + suggested-filename)))) >> + (when history-add-new-input >> + ;; Have to re-add it here because of the let-binding above. >> + (add-to-history 'file-name-history >> + (propertize file 'project (project-root project)))) >> (if (string= file "") >> (user-error "You didn't specify the file") >> (find-file file)))) > > This seems good, sure. But doesn't this make the history entries appear > twice? It doesn't, since whatever modification to file-name-history is done inside project-read-file-name-function is erased when the surrounding 'let' form (pre-altering its value) returns. > Maybe we should just pull the history-adding functionality out of > project-read-file-name-function entirely. I've tried doing that below. Just for project-find-dir, right? That makes sense. > Also, I realized just now that this should probably affect > project-find-dir as well, as should my previous patch adding > project-relative future history. (I actually coincidentally just now > got a user request for "switch between projects and stay in the same > dir") ^^ > So here's a revised version of this history change which also affects > project-find-dir. In a subsequent mail I'll send a patch for the > "future history" behavior of project-find-dir too. (yet to be written) That ones looks good too (I'll go over the cosmetics a little later). Regarding project-file-name-history-relativize, I wanted to ask about a shorter name, but... it seems like there aren't many to be had. Also originally I wanted to just enable the feature and then see what actual modifications people will want. Perhaps some will ask for find-file and project-find-file histories to be totally separate instead? Or maybe not. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Aug 2023 02:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, monnier@iro.umontreal.ca, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16924112598940 (code B ref 63829); Sat, 19 Aug 2023 02:15:02 +0000 Received: (at 63829) by debbugs.gnu.org; 19 Aug 2023 02:14:19 +0000 Received: from localhost ([127.0.0.1]:49111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXBTm-0002K8-Gs for submit@debbugs.gnu.org; Fri, 18 Aug 2023 22:14:18 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:48481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXBTk-0002Jl-KN for 63829@debbugs.gnu.org; Fri, 18 Aug 2023 22:14:17 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DDB153200925; Fri, 18 Aug 2023 22:14:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 18 Aug 2023 22:14:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692411249; x=1692497649; bh=sHI8XIDceSh/+qBGXP0n+hQNyjVP78vPTR7 SflYkHCo=; b=Ywz1cgZbOfMn0WlXMbosV32SM/QXCoG5/1zDGiBB4vYI+5odYgq 8B8MqmvsJit/J4d605G4zoU2I0iVQaAjX/yhab7ixltfhWu5tdxfmHIQ4bxeC89H 7sRm++53cp9TMTALYQssGISk7w0gA4B9XbX1IX7hu6wSCOCapUwHf4phXPMljxaM xV0jf3bYLohXEPmU5nZnQb1v/nQXaEyrlqj5CUGDz55BWH0XBI0WSTkPwhgZXqkn V8rhqYYu1JikI0cIYqqx1QNR2HqC+bkzONhzB2PEc+wYQ9kYQN9Wryvk3mFXfC5I UY44Kg5z/qYkTSp9d2nlhq3uUHhyfcr4euw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692411249; x=1692497649; bh=sHI8XIDceSh/+qBGXP0n+hQNyjVP78vPTR7 SflYkHCo=; b=Ett9dugs8WLIp1i7l+EUgUh7TGBm1qkdlc4r7eoDaURgCzjC/rw PfLccsrk8/DN7d3bUxfHsCzRDXfreYNpCtHDxsR1Icly4RCWAFlBIBBsqzKqpLO/ C03kq6hOMQh9OSj3W/N4zNBouV5tYE1LqPtUZ0Sh8TtTf7dwfsYvgbZpbzH8c0dr So2iW0c4y3rkmEfZYhqYzvUS54cBbZskuixuLk5rbsCA6nc94ZjLCwuHInzz/f65 XHEtAIttTXeyGaVgt1usLCNk/dP8onHkay0yVg6vHBefjX34je8vL7P4l7yz+PqO +jmTI7qh/OVjfjwOmYRkFM7FS2hVnKnj7ew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddugedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Aug 2023 22:14:07 -0400 (EDT) Message-ID: <74c1bb5c-be77-feb6-0c54-9a2d600707a0@gutov.dev> Date: Sat, 19 Aug 2023 05:14:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 18/08/2023 23:57, Spencer Baugh wrote: > > BTW, one more feature in this vein (stealing this idea from Stefan) > would be if we automatically moved point to the same location in the > other file. That might be a little too magical. But it would be very > cool... > > I guess the ideal thing we'd want is to move point to the same function, > which is a bit trickier... could be done with imenu perhaps. Not > sure... We don't know how much these files could be different. One could be empty (a newly-created one), or having totally different contents. There is a way to detect a useful offset if the files are similar enough (using 'diff -u''s output), I think we have that in diff-hl. But calling 'diff' when any file is visited seems like it will be minority preference... I think. > Maybe the right call would be to have a keybinding in C-x p p like j or > something, which would just instantly jump you to the same file in the > other project. So you'd just run C-x p p j and that would open the same > file in the other project, with point inside the same function (using > imenu), at the same offset in that function. Sure, why not. As a part of your personal (or company-wise) settings? > That could be helpful for other reasons too: I've often wanted "just put > me anywhere in this other project, I don't care where", and this could > be that command. Although I suppose mostly I want that because C-x p p > isn't currently a generic prefix for any command, and if we convert it > to be that (with next-default-directory or something), I won't need > that. Just in case you were not aware: project-switch-commands can also be set to a single symbol, then just that command will be invoked. > Alternatively, maybe C-x p j could be an alternative to C-x p p, and > when it prompts for a project, it could prompt only for "sibling > projects" which have the same file structure. And we could have a > built-in way to detect sibling projects: Any other worktree of the > current git repository is a sibling project. (And we would make this > extensible too of course; maybe have both project-siblings and > vc-list-worktrees as extension points) I'm not convinced yet by the idea of 'project-siblings' generic (need more uses/users), but the rest sounds good and very doable anyway. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Aug 2023 12:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Spencer Baugh , Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169244644818695 (code B ref 63829); Sat, 19 Aug 2023 12:01:01 +0000 Received: (at 63829) by debbugs.gnu.org; 19 Aug 2023 12:00:48 +0000 Received: from localhost ([127.0.0.1]:49642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXKdM-0004rS-Cz for submit@debbugs.gnu.org; Sat, 19 Aug 2023 08:00:48 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:14934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXKdI-0004rB-Qf for 63829@debbugs.gnu.org; Sat, 19 Aug 2023 08:00:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=ve9TsvxuTbbboLn9KsE3u9R5zUaDm/g3aIF3Un7pUSg=; b=SjxVmE9501UzmnDyrjT/ls7DZcSEM1226xeu9piHxiPaTlWyKmwgzw8j1XPAbaBF2Bnr wSzGT6X2n1SC5Q7zvpMFXRa8+l73U1nTVIiAdN8DNJpbc5A/hxSaQnHwo0mly7tBWuTt2b UKRpikvPpB3g0tRmen5dPPxEL+xH8cuhT9wruepvM4xHV+PNOGEeLT/fBeEpKSGpFRDeeX grOb/IlbBP1ybT2crlNhP9SFadZwQjUg0FPS0+/fe4vR7FhwhOGuTfNEEtgjL89uVWqz0b nVGaoHBiZwK0EsScJIQfJ9bqWzK4kgNG5bSf+vvr6EjGBLNqM+SC/vn/ZgCA7IuA== Received: by filterdrecv-8684c58db7-rkmgq with SMTP id filterdrecv-8684c58db7-rkmgq-1-64E0AEE5-47 2023-08-19 12:00:37.446974132 +0000 UTC m=+8684544.839540135 Received: from earth.catern.com (unknown) by geopod-ismtpd-1 (SG) with ESMTP id JOQ3-7NkQXmAcYi7xaeb9w Sat, 19 Aug 2023 12:00:37.211 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gutov.dev Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id A625D62562; Sat, 19 Aug 2023 08:00:36 -0400 (EDT) From: sbaugh@catern.com In-Reply-To: <208300a3-25e1-d057-11ac-179e52b8f547@gutov.dev> (Dmitry Gutov's message of "Sat, 19 Aug 2023 05:08:38 +0300") References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <208300a3-25e1-d057-11ac-179e52b8f547@gutov.dev> Date: Sat, 19 Aug 2023 12:00:37 +0000 (UTC) Message-ID: <871qfzi6mz.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbJ44j8pmP2gn12MHR+YNk85FilZsC4dxz9mRLa6v263rPqh5T3Qk5tmkY+dWo6IyxbJtIEpIZ5pEIpHoA0vcGrUeMeLa808eB3spEQIxVN1/Eo31No6pHSu8uv3MKNbKbI//tefwYVGRiXRnehwVDIosHaP/GVAhzCS5rPLwu1NZQ== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Dmitry Gutov writes: > On 17/08/2023 22:41, Spencer Baugh wrote: >> Dmitry Gutov writes: >>> - (file (funcall project-read-file-name-function >>> - "Find file" all-files nil 'file-name-history >>> - sug [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [149.72.154.232 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Dmitry Gutov writes: > On 17/08/2023 22:41, Spencer Baugh wrote: >> Dmitry Gutov writes: >>> - (file (funcall project-read-file-name-function >>> - "Find file" all-files nil 'file-name-history >>> - suggested-filename))) >>> + (file >>> + (let ((file-name-history (mapcar >>> + (lambda (f) >>> + (or (project--expand-file-name >>> f project) f)) >>> + file-name-history))) >>> + (funcall project-read-file-name-function >>> + "Find file" all-files nil 'file-name-history >>> + suggested-filename)))) >>> + (when history-add-new-input >>> + ;; Have to re-add it here because of the let-binding above. >>> + (add-to-history 'file-name-history >>> + (propertize file 'project (project-root project)))) >>> (if (string= file "") >>> (user-error "You didn't specify the file") >>> (find-file file)))) >> This seems good, sure. But doesn't this make the history entries >> appear >> twice? > > It doesn't, since whatever modification to file-name-history is done > inside project-read-file-name-function is erased when the surrounding > 'let' form (pre-altering its value) returns. > >> Maybe we should just pull the history-adding functionality out of >> project-read-file-name-function entirely. I've tried doing that below. > > Just for project-find-dir, right? That makes sense. > >> Also, I realized just now that this should probably affect >> project-find-dir as well, as should my previous patch adding >> project-relative future history. (I actually coincidentally just now >> got a user request for "switch between projects and stay in the same >> dir") > > ^^ > >> So here's a revised version of this history change which also affects >> project-find-dir. In a subsequent mail I'll send a patch for the >> "future history" behavior of project-find-dir too. (yet to be written) > > That ones looks good too (I'll go over the cosmetics a little later). > > Regarding project-file-name-history-relativize, I wanted to ask about > a shorter name, but... it seems like there aren't many to be had. > > Also originally I wanted to just enable the feature and then see what > actual modifications people will want. Perhaps some will ask for > find-file and project-find-file histories to be totally separate > instead? Or maybe not. Sure, if it's something you think is reasonable to enable by default that's totally fine for me. A modification that makes some sense to me (although it's hard) is actually to merge find-file and project-find-file history *more*. Right now a path in the history can only be adjusted for the current project if it was originally added to the history by project-find-file. It might be nice if the adjustment worked for paths added by find-file too, although that is tricky to do efficiently since they don't (yet?) have the project embedded in them with a text property. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2023 17:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Spencer Baugh Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169255248819015 (code B ref 63829); Sun, 20 Aug 2023 17:29:01 +0000 Received: (at 63829) by debbugs.gnu.org; 20 Aug 2023 17:28:08 +0000 Received: from localhost ([127.0.0.1]:54779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDf-0004wX-U8 for submit@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:08 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]:33883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDZ-0004uy-Sb for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:02 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 2FA97C0002; Sun, 20 Aug 2023 17:27:52 +0000 (UTC) From: Juri Linkov In-Reply-To: (Dmitry Gutov's message of "Thu, 17 Aug 2023 05:14:03 +0300") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Sun, 20 Aug 2023 20:13:51 +0300 Message-ID: <865y59n73s.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > +(defun project--expand-file-name (filename project) > + (when-let ((old-root (get-text-property 0 'project filename))) > + (abbreviate-file-name > + (expand-file-name > + (file-relative-name filename old-root) > + (project-root project))))) and > + (add-to-history 'file-name-history > + (propertize file 'project (project-root project)))) Then maybe better to simply add only the relative file name for optimization? Like this (add-to-history 'file-name-history (propertize file 'project-relative-name (file-relative-name file (project-root project))))) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2023 17:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169255248819022 (code B ref 63829); Sun, 20 Aug 2023 17:29:02 +0000 Received: (at 63829) by debbugs.gnu.org; 20 Aug 2023 17:28:08 +0000 Received: from localhost ([127.0.0.1]:54781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDg-0004we-8L for submit@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:08 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:47025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDe-0004vF-03 for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:06 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id EEC47240003; Sun, 20 Aug 2023 17:27:56 +0000 (UTC) From: Juri Linkov In-Reply-To: (Spencer Baugh's message of "Thu, 17 Aug 2023 16:12:33 -0400") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Sun, 20 Aug 2023 20:16:23 +0300 Message-ID: <86ttstlsf4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > + (if-let (filename-proj (and project-current-directory-override > + (project-current nil default-directory))) > + ;; file-name-concat requires Emacs 28+ > + (concat (file-name-as-directory (project-root project)) > + (file-relative-name filename (project-root filename-proj))) > + filename)) I wonder why you prepend (file-name-as-directory (project-root project))? This is unnecessary because the project root is already displayed in the prompt, so only a relative file name is sufficient in the minibuffer: Find file in /project/root/: relative/file.name From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2023 17:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169255250419059 (code B ref 63829); Sun, 20 Aug 2023 17:29:02 +0000 Received: (at 63829) by debbugs.gnu.org; 20 Aug 2023 17:28:24 +0000 Received: from localhost ([127.0.0.1]:54785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDw-0004xK-GE for submit@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:24 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:40129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDi-0004wB-2N for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:10 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 298EFE0003; Sun, 20 Aug 2023 17:28:00 +0000 (UTC) From: Juri Linkov In-Reply-To: (Spencer Baugh's message of "Thu, 17 Aug 2023 15:41:47 -0400") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Sun, 20 Aug 2023 20:20:12 +0300 Message-ID: <86a5ulls6z.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > +(defcustom project-file-name-history-relativize nil > + "If non-nil, paths in `file-name-history' are adjusted for the current project. > + > +When non-nil and in `project-find-file' or `project-find-dir', > +paths in `file-name-history' are adjusted to be relative to > +whatever the current project is, instead of the project which > +added those paths. This only affects history entries added by > +earlier calls to `project-find-file' or `project-find-dir'. > + > +When `project-read-file-name-function' is > +`project--read-file-cpd-relative' (the default), this has the > +effect of sharing more history between projects.") Instead of, or in addition to 'project-file-name-history-relativize', another option may be needed to define whether to check the existence of the constructed file name. This could help to filter out irrelevant file names constructed from different projects. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Aug 2023 17:29:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: Dmitry Gutov , 63829@debbugs.gnu.org, monnier@iro.umontreal.ca, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169255250519066 (code B ref 63829); Sun, 20 Aug 2023 17:29:03 +0000 Received: (at 63829) by debbugs.gnu.org; 20 Aug 2023 17:28:25 +0000 Received: from localhost ([127.0.0.1]:54787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDw-0004xM-Pf for submit@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:25 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:60439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXmDm-0004wr-K4 for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 13:28:15 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 0FC0820003; Sun, 20 Aug 2023 17:28:04 +0000 (UTC) From: Juri Linkov In-Reply-To: (Spencer Baugh's message of "Fri, 18 Aug 2023 16:57:18 -0400") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Sun, 20 Aug 2023 20:23:14 +0300 Message-ID: <861qfxkbtl.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > BTW, one more feature in this vein (stealing this idea from Stefan) > would be if we automatically moved point to the same location in the > other file. That might be a little too magical. But it would be very > cool... One possible implementation would be with the help of saveplace.el. There are already some similarities between these two packages: for example, the same fix that you proposed in bug#64088 to use file-remote-p before abbreviating project file names, should be applied to save-place-abbreviation-file-names in bug#65055 as well. > Maybe the right call would be to have a keybinding in C-x p p like j or > something, which would just instantly jump you to the same file in the > other project. So you'd just run C-x p p j and that would open the same > file in the other project, with point inside the same function (using > imenu), at the same offset in that function. A dedicated command with 'C-x p p j' or just 'C-x p j' that will ask for another project would be the best thing to do. > Alternatively, maybe C-x p j could be an alternative to C-x p p, and > when it prompts for a project, it could prompt only for "sibling > projects" which have the same file structure. And we could have a > built-in way to detect sibling projects: Any other worktree of the > current git repository is a sibling project. (And we would make this > extensible too of course; maybe have both project-siblings and > vc-list-worktrees as extension points) For switching to a sibling file in another project, I'm using a new nice command 'find-sibling-file'. Extending it specifically for projects looks line a good direction for development. > That could be helpful for other reasons too: I've often wanted "just put > me anywhere in this other project, I don't care where", and this could > be that command. Although I suppose mostly I want that because C-x p p > isn't currently a generic prefix for any command, and if we convert it > to be that (with next-default-directory or something), I won't need > that. Probably next-default-directory will reuse the same keymaps, but let's see where it goes in bug#63648. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 01:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov , Spencer Baugh Cc: sbaugh@catern.com, 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169258057530591 (code B ref 63829); Mon, 21 Aug 2023 01:17:02 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 01:16:15 +0000 Received: from localhost ([127.0.0.1]:55088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtWh-0007xL-8p for submit@debbugs.gnu.org; Sun, 20 Aug 2023 21:16:15 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:42769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtWc-0007wv-DW for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 21:16:14 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 59E0B320083A; Sun, 20 Aug 2023 21:16:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 20 Aug 2023 21:16:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692580560; x=1692666960; bh=u8UIkzeG0MblDleKmF9wC55/HVSyXSuzrXh ZztIngtM=; b=X8ivzjypCFIQHenx1fabFq02B0eHW5pml1IR93sBkZZWxQYxYXI E1xt6QMdPXaSML4YnxPsCZ1eeCbYmzZPfFeF+AA0fO6pcNYk3whzo7GG+NkGkoRh x59zPWb9tgGBPAd39WJz6JklBo4pSsGcSZL42zvwdOIma2GmWqL0Rip4NufQcxVh J1sBlLbOYVgHur0gmtpDRPCT8+AnUXDqgz8gZI3q3Ii70JaXrNv7Cz4Yqb4RwD0P WFEsuandvw6Ii/oET5RFBsheFIBUI/ZRGLJbrO474Zas0d9YbSuyGNXp+ZEp3vDH ffw8qaRnnZicJDh07sd2XgODL8fzh2tvZ0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692580560; x=1692666960; bh=u8UIkzeG0MblDleKmF9wC55/HVSyXSuzrXh ZztIngtM=; b=CNRrT7hgnXKcJX/yRXPaxiSTW5cfl6Qgqx/gIY98IrhuoAv7YhT S0uyq/G4YCtumIiXtDnMOynWOrsApJbD8JPPteh4SbkvukBVj2ydiB3J6hxYm4ly Gu6c8wh3FerJajAg/+vS8pwXYEGiDaRebXeoF8QFYiCEHYP9HtpexGrkBJFaURK/ P2owwGtG+z5/9UBf2h7mFGKa8GKqiUmD5qqETWbEjJTuhVz8AjbSqJGLSwM+N6S+ 3eEuSWeg8JF7TQoVenzaIrl9MyQaZ2K0TIcK+p+TRrGE+EztP5cYh+DsgSYxZjQv 3Qg96P7J4zhBiNqrcZDqPT/TKQlkkxG6xcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddukedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Aug 2023 21:15:59 -0400 (EDT) Message-ID: <8991f72e-80ec-f653-38f6-dc90d316e9c0@gutov.dev> Date: Mon, 21 Aug 2023 04:15:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <86ttstlsf4.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86ttstlsf4.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 20/08/2023 20:16, Juri Linkov wrote: >> + (if-let (filename-proj (and project-current-directory-override >> + (project-current nil default-directory))) >> + ;; file-name-concat requires Emacs 28+ >> + (concat (file-name-as-directory (project-root project)) >> + (file-relative-name filename (project-root filename-proj))) >> + filename)) > > I wonder why you prepend (file-name-as-directory (project-root project))? > This is unnecessary because the project root is already displayed > in the prompt, so only a relative file name is sufficient in the minibuffer: > > Find file in /project/root/: relative/file.name The absolute name is required down in the callee because that distinguishes it from a file name fragment picked up by things-at-point. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 01:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Spencer Baugh Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169258063430701 (code B ref 63829); Mon, 21 Aug 2023 01:18:01 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 01:17:14 +0000 Received: from localhost ([127.0.0.1]:55093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtXd-0007z4-OF for submit@debbugs.gnu.org; Sun, 20 Aug 2023 21:17:14 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:49839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtXb-0007yn-3M for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 21:17:12 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 49F75320083A; Sun, 20 Aug 2023 21:17:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 20 Aug 2023 21:17:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692580622; x=1692667022; bh=kLFHG9n4bAy7MudEYMs3tdZorT1SOBo9lhG m08MBslo=; b=PoiCEIJx9oBhtLvDsBxz8hm1a6aBPNZcBwYSKZeE3WgHlcPeyXd Ao0RbTr/tXuDo5dejgJOV+scODH0fxOH0yki3id5R6qctGsFRWR1LyU5fB3WDeEQ 8zm6YPFnzupIht9B4yBBTwyz8Q8L/Iw36t8lSUYPaKDcI3HAnlQTLXumWYhrWP+x 86Pptwa9mIiX9fNpfaEkP/mEu5LvOnIYO9mwIpjMSuVMLzl+bNINyc6FZhq97Whu N7vhJ3ZP+Y0hEGO9MA7D3yq8zltMFYj355IOU2MIdbQFMtGNwc2Xh77NHcUSf4f3 BBgh3lTYRt7CY/tTgpUtn+4EI2LDne1cgqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692580622; x=1692667022; bh=kLFHG9n4bAy7MudEYMs3tdZorT1SOBo9lhG m08MBslo=; b=KS+WYZ6Q3TcTR/S+khOjbgcZeRTL8C2wlVTjLd2yveXQwuNliog JMmp8bTsv+HppkVewVPpkeD//vzp1Fta8XwsDXpxqP6vBDjh51zzmaN6Mgjflei3 uLVm89R8w+7gI7pj3ZZ7rFFvJr6JBS2OlEkd6iUY2pnQBxJVS2Ch7NY7PC3cB9X1 k3NQxvg72xlWcPZLZu7VUrsnavBWacMuPsxneAxXsQVWekmY60/qcMLxl5lj+cvR j3Kskm70yNvJPirxJ2SspVD+FBwdgqVnRA5qWqKb8xTxEXzsLxpwb7NCV1XZaiJO HsatPkXoQLzTvKQnGgLpCg95VE0/mkLqTRA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddukedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Aug 2023 21:17:01 -0400 (EDT) Message-ID: <9fc3dec9-0bea-b480-35fa-af33729cc8c8@gutov.dev> Date: Mon, 21 Aug 2023 04:17:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <865y59n73s.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <865y59n73s.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 20/08/2023 20:13, Juri Linkov wrote: > Then maybe better to simply add only the relative file name for optimization? > Like this > > (add-to-history 'file-name-history > (propertize file 'project-relative-name > (file-relative-name file (project-root project))))) Then it won't work in find-file (or might even break it). From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 01:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov , Spencer Baugh Cc: sbaugh@catern.com, 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16925822531108 (code B ref 63829); Mon, 21 Aug 2023 01:45:01 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 01:44:13 +0000 Received: from localhost ([127.0.0.1]:55108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtxl-0000Hl-1V for submit@debbugs.gnu.org; Sun, 20 Aug 2023 21:44:13 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:39367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXtxi-0000HQ-Bu for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 21:44:11 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F0B7B3200902; Sun, 20 Aug 2023 21:44:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 20 Aug 2023 21:44:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692582241; x=1692668641; bh=yAeoDWeRL89oxSCh8PyXsb0MU9S1bgk1Rty k4xM9hSM=; b=YXMFmjUT2eueKGyMAPQk4TI+rMiTm3EXRES8sFCJ73IGy11B7Z3 yfxUMoYWzn6AtKfI1ZmHWgjcJ46uYrpJmFT2E2sEDpsiJIq/SFX3DmnShv28557u yCsVTajseEuhqe3yJogpylMdNxF8oj1g0RKvPFbfhDuSwavIoxc43B4n8U5FStTR 0xNWlWVzQSlXyxnYTKZn3NMVTIA4fwDdKOneB+JEM0C9EG30WJCb+T0t1kJeaW3g E9y6gM1jpfuJELr+rQy1c19KL3GDylqrdxM8vO4cTKbT0lTqyoYx+8sIMueX3RQE BWgfGWRzi/Fzlk0hpFxZlBCqPNX2q5+THhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692582241; x=1692668641; bh=yAeoDWeRL89oxSCh8PyXsb0MU9S1bgk1Rty k4xM9hSM=; b=KpRrf0koZ+Vo4/jKvQsZTAJIhNNPSNRl6CFuso8j3KJOmQLTBNa mHj51h/p7JGTJy9u6NKtJlUz0O+91wf6QG1PzJg6P/Av0VpwO1LzMyeVopklzghH LiA4NVthcJgHeGFQtGEn3YfEMds1A5aedLLgaUWYHkDg2eTqT3yuKxzwLpofLoH8 oOYSV8TevKixAnldzb1gcRs8gc4Rv+AQb59jBl6RPiAIJB7iK4ua6P0uKVWHb04T CMsBjjVVjbKgme5O51Tp5qUOt1aeAHmyDJkP19OlUl/mzdOD7ZM7qWjrnN3KJwl4 IomyMDJMG29wOCI1X+6n4IZbAGEz0kN+Wpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddukedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Aug 2023 21:43:59 -0400 (EDT) Message-ID: <96d3e02d-324b-7cd3-b271-3b67153ada16@gutov.dev> Date: Mon, 21 Aug 2023 04:43:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <86a5ulls6z.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86a5ulls6z.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 20/08/2023 20:20, Juri Linkov wrote: >> +(defcustom project-file-name-history-relativize nil >> + "If non-nil, paths in `file-name-history' are adjusted for the current project. >> + >> +When non-nil and in `project-find-file' or `project-find-dir', >> +paths in `file-name-history' are adjusted to be relative to >> +whatever the current project is, instead of the project which >> +added those paths. This only affects history entries added by >> +earlier calls to `project-find-file' or `project-find-dir'. >> + >> +When `project-read-file-name-function' is >> +`project--read-file-cpd-relative' (the default), this has the >> +effect of sharing more history between projects.") > Instead of, or in addition to 'project-file-name-history-relativize', > another option may be needed to define whether to check the > existence of the constructed file name. This could help > to filter out irrelevant file names constructed from > different projects. It could indeed. But it could also prevent the user from easily creating a new file with the name from a "sister" project. We've discussed this before in this thread, including the idea of some predicate checking the projects for compatibility, etc. What behavior would you actually choose yourself? From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 01:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@catern.com Cc: Spencer Baugh , Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16925827072237 (code B ref 63829); Mon, 21 Aug 2023 01:52:01 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 01:51:47 +0000 Received: from localhost ([127.0.0.1]:55113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXu55-0000a0-1K for submit@debbugs.gnu.org; Sun, 20 Aug 2023 21:51:47 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:37919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXu53-0000Zn-Do for 63829@debbugs.gnu.org; Sun, 20 Aug 2023 21:51:46 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 4ADFA32000E5; Sun, 20 Aug 2023 21:51:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 20 Aug 2023 21:51:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1692582696; x=1692669096; bh=/zB84CY+7Y5kZgTVwmOKKfE7P/LwbK2QU/R bSbVyfiw=; b=JfMu1nDwTGa1KnzyCyRxAH0xPzM2zGW/X4VaLk2B/2YAuVPjcrW klgmYa7xxRyZvtnAFsMRF6FiqzJuBfbiCieWl3ovWyiOqFMsGcdPCaMUhcGGokNy r8qyBDWpMiyCRAeo79n/MZihDSVTCJ9wtno/mYKIxIGHHLYVbXLIqeoNQH6QNQLw a7qIdCOWQ9Q7ce7NxIMAfVlwt8RjfYO5qalnjJyjuCYY3qyxJ9MXPyFpzTNuZx5E 7N0NCw4W04zZKqNrcrT8zkg+2laYX3cyWMrZLPXbp4k5nUcm5a931DfDb2mbROgj d1aMauW+jKqkm4rP6qWwXV13Jn3afU0cd4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692582696; x=1692669096; bh=/zB84CY+7Y5kZgTVwmOKKfE7P/LwbK2QU/R bSbVyfiw=; b=o/ePNapuGgnU0r4dGIso0vpdUcFFzVRGSqF8zH4k2KKHkFhc9ec jdH4j8KgCTFn2UR5/o2IrZP8DFmOv5djUdMtvLakUbdd6K38pjAYYFMI48hxh1+z UhUoaWtQQXb/bBYPCssjQrNk24HxMDzeSxpVCwxW1ZiayeOHeTZD5eKZY+lQX8LA CVJ/406H1vkWav+rRjAH7ZlBv0qG6OX5vloaMuwu7fIDuIwI8BB4DyUwgQjcl+RS HEhpgmh+oRShXuBWn33aJoGTT2NoRzi55USiev8YN+nZMD4qw5M4VEjSo5IT+/hu yMQJ07zaK6koynGEEgIhc6tKna+wGqL2t7w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddukedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 20 Aug 2023 21:51:35 -0400 (EDT) Message-ID: <24706934-8acd-2047-7db9-11b7d34ddd0e@gutov.dev> Date: Mon, 21 Aug 2023 04:51:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <208300a3-25e1-d057-11ac-179e52b8f547@gutov.dev> <871qfzi6mz.fsf@catern.com> From: Dmitry Gutov In-Reply-To: <871qfzi6mz.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 19/08/2023 15:00, sbaugh@catern.com wrote: >> Regarding project-file-name-history-relativize, I wanted to ask about >> a shorter name, but... it seems like there aren't many to be had. >> >> Also originally I wanted to just enable the feature and then see what >> actual modifications people will want. Perhaps some will ask for >> find-file and project-find-file histories to be totally separate >> instead? Or maybe not. > > Sure, if it's something you think is reasonable to enable by default > that's totally fine for me. I'm being a tad skittish about it because once we add the var, it will likely have to stay around for a long time. And a long name is both unwieldy and less prone to extensibility. One of the ways to make it shorter, is to thing around different non-intersecting behaviors that could be enabled by it. If e.g. it could have values "default" (don't do anything) and "relativize" (and ... "relativize existing"? as Juri brought up), then the var could be called project-file-history-behavior with values t, 'relativize and 'relativize-existing. Or something like that. We could still drop the option for now and enable the new behavior by default, unless somebody objects. > A modification that makes some sense to me (although it's hard) is > actually to merge find-file and project-find-file history *more*. Right > now a path in the history can only be adjusted for the current project > if it was originally added to the history by project-find-file. It > might be nice if the adjustment worked for paths added by find-file too, > although that is tricky to do efficiently since they don't (yet?) have > the project embedded in them with a text property. I don't know, it seems like we'd do extra work up front, going through file-name-history, while most people won't take advantage of it. If we could do that lazily (with a generator function of some sort), that would of course be preferable. As it is, though, one could just run a small script once, and convert all the entries to use later. What's the scenario when this doesn't work? People using 'find-file' to quickly jump to a file in the same dir and then wanting to use it in history during project-find-file in another project? From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 07:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Spencer Baugh Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16926027295239 (code B ref 63829); Mon, 21 Aug 2023 07:26:01 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 07:25:29 +0000 Received: from localhost ([127.0.0.1]:55360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzI1-0001MR-Be for submit@debbugs.gnu.org; Mon, 21 Aug 2023 03:25:29 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:49867) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzHw-0001Lp-9k for 63829@debbugs.gnu.org; Mon, 21 Aug 2023 03:25:24 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 5925B60012; Mon, 21 Aug 2023 07:25:13 +0000 (UTC) From: Juri Linkov In-Reply-To: <9fc3dec9-0bea-b480-35fa-af33729cc8c8@gutov.dev> (Dmitry Gutov's message of "Mon, 21 Aug 2023 04:17:00 +0300") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <865y59n73s.fsf@mail.linkov.net> <9fc3dec9-0bea-b480-35fa-af33729cc8c8@gutov.dev> Date: Mon, 21 Aug 2023 09:58:29 +0300 Message-ID: <86h6osc2iz.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Then maybe better to simply add only the relative file name for optimization? >> Like this >> (add-to-history 'file-name-history >> (propertize file 'project-relative-name >> (file-relative-name file (project-root project))))) > > Then it won't work in find-file (or might even break it). But find-file doesn't use the property 'project-relative-name'. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 07:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Spencer Baugh , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16926027305247 (code B ref 63829); Mon, 21 Aug 2023 07:26:02 +0000 Received: (at 63829) by debbugs.gnu.org; 21 Aug 2023 07:25:30 +0000 Received: from localhost ([127.0.0.1]:55362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzI1-0001MX-LY for submit@debbugs.gnu.org; Mon, 21 Aug 2023 03:25:29 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:dc4:8::227]:57925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzHz-0001Ly-82 for 63829@debbugs.gnu.org; Mon, 21 Aug 2023 03:25:27 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3D44720003; Mon, 21 Aug 2023 07:25:17 +0000 (UTC) From: Juri Linkov In-Reply-To: <96d3e02d-324b-7cd3-b271-3b67153ada16@gutov.dev> (Dmitry Gutov's message of "Mon, 21 Aug 2023 04:43:56 +0300") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <86a5ulls6z.fsf@mail.linkov.net> <96d3e02d-324b-7cd3-b271-3b67153ada16@gutov.dev> Date: Mon, 21 Aug 2023 10:06:35 +0300 Message-ID: <86ttssan7o.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >>> +(defcustom project-file-name-history-relativize nil >>> + "If non-nil, paths in `file-name-history' are adjusted for the current project. >>> + >> Instead of, or in addition to 'project-file-name-history-relativize', >> another option may be needed to define whether to check the >> existence of the constructed file name. This could help >> to filter out irrelevant file names constructed from >> different projects. > > It could indeed. But it could also prevent the user from easily creating > a new file with the name from a "sister" project. It would be unfortunate to lose this useful feature. > We've discussed this before in this thread, including the idea of some > predicate checking the projects for compatibility, etc. What behavior would > you actually choose yourself? I guess introducing a notion of "sibling projects" is unavoiable to exclude such situations where relative file names from one project are proposed in an unrelated project: Find file in /project/root/: relative/filename/from/unrelated/project Then one possibility is to add an option to define sibling projects. Like 'find-sibling-rules', but maybe simply to contain alists of sibling projects. Or projects in 'project--list' could have a new property 'group' where a project belongs to. Then sibling projects could share the common file history. And a new command e.g. 'project-find-sibling-file' could jump to a sibling project file immediately in case of two sibling projects, or ask to select with completion for more projects. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 00:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Spencer Baugh Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169275043631425 (code B ref 63829); Wed, 23 Aug 2023 00:28:01 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 00:27:16 +0000 Received: from localhost ([127.0.0.1]:60649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYbiN-0008An-NE for submit@debbugs.gnu.org; Tue, 22 Aug 2023 20:27:15 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:42489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYbiK-0008AZ-KL for 63829@debbugs.gnu.org; Tue, 22 Aug 2023 20:27:13 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 62B535C00D1; Tue, 22 Aug 2023 20:27:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 22 Aug 2023 20:27:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692750424; x=1692836824; bh=r2iVKFd67Z8SGEAaqm+Vc6drvkpYnXEXTwC cbkvELhU=; b=V8FbPOU8xXH9UCidZYULQ/lE/UXx9B5p9OSkPIPkfBdHkJ8c5KZ TuhC4c+mC6a/00bHtxOZ1PNllbHkWCRmI3RSCe6KviFs21+4AP209qknIYuGw++U 2WICYPRBXC+Ub5ACBdT09EQQAsyhCGv0opvP94B0kf0kJx4NlmxxneqE5JJQKNGL MHc6WPvfEwR+y/6bnLhiMwkyGdmCQKdveiNBLIOcoUmTLRav17kd85dTlbPC8HSe nCfjBCSixBIIQRaQPy58aDfoddzrP4CxccTjmvEy65Ode+shp65NTQgSHlUlAy94 drQC4Lsr+HuxI3UYZr5OJH4DxAnoGrGj/Mw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692750424; x=1692836824; bh=r2iVKFd67Z8SGEAaqm+Vc6drvkpYnXEXTwC cbkvELhU=; b=EIGg5FX8vqp2rqsr9MGUm3IXeDQEu1uLMu37T6M1HoYfsw2XiSw UXOmwYuOBIlW7BRcy3f4RHQK8w9pBc9seN8QRvr+hF1/9KEqkAqoHNKznvxW6FPG sdkMcRbEt55qMfXZxBbVbbY1FIBvib7UREsxSn73hAYN+45CI1ARQ/s7joDwY+t8 sAwEdG++FNChnJwBfy1sClrWaJBYGvrBAgbK3d80ZQ858YhEwja1AsnDA91k7vGV WderKUphYibKYLwZiCtS7f/G+PPFL/J+Q7MTVhtW6dUF3v43A3lbCuhZWbQGERqc fJICjDUbnEGgfFiOmI1XZOq/ERnz/eOFlQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvvddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Aug 2023 20:27:02 -0400 (EDT) Message-ID: <0b4286a4-9929-3405-4c66-06c1af4827e8@gutov.dev> Date: Wed, 23 Aug 2023 03:27:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <865y59n73s.fsf@mail.linkov.net> <9fc3dec9-0bea-b480-35fa-af33729cc8c8@gutov.dev> <86h6osc2iz.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86h6osc2iz.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 21/08/2023 09:58, Juri Linkov wrote: >>> Then maybe better to simply add only the relative file name for optimization? >>> Like this >>> (add-to-history 'file-name-history >>> (propertize file 'project-relative-name >>> (file-relative-name file (project-root project))))) >> Then it won't work in find-file (or might even break it). > But find-file doesn't use the property 'project-relative-name'. Yes, it just uses the absolute name. It won't be able to use the relative one. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 00:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: Spencer Baugh , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169275105732552 (code B ref 63829); Wed, 23 Aug 2023 00:38:02 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 00:37:37 +0000 Received: from localhost ([127.0.0.1]:60667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYbsO-0008Sx-NO for submit@debbugs.gnu.org; Tue, 22 Aug 2023 20:37:37 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYbsM-0008Si-D4 for 63829@debbugs.gnu.org; Tue, 22 Aug 2023 20:37:35 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 299B15C01EB; Tue, 22 Aug 2023 20:37:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 22 Aug 2023 20:37:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692751046; x=1692837446; bh=9GILqBF1+5RlolnXuWOE7WWbSNeYNSojhwc OPzXCbIQ=; b=TORgpRXuqk8e3k6IiAoU9fsM1KqHbdnOaZbrsJKrt4SN6sf8SFp 50GsfHvNezZmtjo5qiAD3XZVl/yDrNanU4WxYBFuPIfKtg4odXg/oC57kG5E/ry+ sAI3spit4tJbYyWFTSJjiRi2Q05xHihUpxuZGw/6NNqPXNCd4XGIBBkAsXXSNlGq Uy1yrFW6Tkqmc+Uf9DoeoFkFT3Zp8NbYcLqaLwcdVffwg59I/fRtdam8hkfseSLr FKGXStM/Mn55h5V7Keh/8AJuBl2xwkw5VgHK5+zVeZ7KBoCWLmnartlpzTjN361g M8EmmZyzQUHmPk9fBt/eLCw+yEa/w0WJxxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692751046; x=1692837446; bh=9GILqBF1+5RlolnXuWOE7WWbSNeYNSojhwc OPzXCbIQ=; b=qpUwpFiHEZnSIDnB/gEp1yAonAt0wUQmzErPoo3GFvgc6SBw4w1 7MzEEmDHcUqaDR78asn/PlnS/JZ7WnA9qTeg2/apsVf7lsQfEa41Kim6sRdlZkLd 76/LxutRbi7omc7fvnChJ9UMKTUDnEKKrssxxE4IP0kJlRZTgK2fJ3xdVoAToir4 +3Wz/9tb+1/G2NUrRqHgF94Vs6ltccyukggvYmiqLIomCXqM+82kXbOjkGrrBJ7s FOOAzUxGbzrACYePZiDEIlRUJS9wG9LKQKfktNSKBlx1YbBWbhCaJvw6ryIEGLy3 xqYwjZ9vLelGrfPFpbkNnl1aq0Kg+wKd/Sg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvvddgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Aug 2023 20:37:24 -0400 (EDT) Message-ID: <0534118b-0ba1-1279-7bcf-4cdc7a3b5606@gutov.dev> Date: Wed, 23 Aug 2023 03:37:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <86a5ulls6z.fsf@mail.linkov.net> <96d3e02d-324b-7cd3-b271-3b67153ada16@gutov.dev> <86ttssan7o.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86ttssan7o.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 21/08/2023 10:06, Juri Linkov wrote: >>>> +(defcustom project-file-name-history-relativize nil >>>> + "If non-nil, paths in `file-name-history' are adjusted for the current project. >>>> + >>> Instead of, or in addition to 'project-file-name-history-relativize', >>> another option may be needed to define whether to check the >>> existence of the constructed file name. This could help >>> to filter out irrelevant file names constructed from >>> different projects. >> >> It could indeed. But it could also prevent the user from easily creating >> a new file with the name from a "sister" project. > > It would be unfortunate to lose this useful feature. > >> We've discussed this before in this thread, including the idea of some >> predicate checking the projects for compatibility, etc. What behavior would >> you actually choose yourself? > > I guess introducing a notion of "sibling projects" is unavoiable > to exclude such situations where relative file names from one project > are proposed in an unrelated project: > > Find file in /project/root/: relative/filename/from/unrelated/project > > Then one possibility is to add an option to define sibling projects. > Like 'find-sibling-rules', but maybe simply to contain alists of > sibling projects. Or projects in 'project--list' could have > a new property 'group' where a project belongs to. > > Then sibling projects could share the common file history. > > And a new command e.g. 'project-find-sibling-file' could > jump to a sibling project file immediately in case of > two sibling projects, or ask to select with completion > for more projects. That would require a new generic (project-sibling-projects) and a proper description of what a "sibling" project is supposed to be. And probably still not going to work for VC-aware backend OOTB (it'll require some backend specific hook for the users to define that logic). Sounds a little complicated, so given that one can still reach almost the same functionality through history completion ('C-x p p ... RET f C-n RET'), maybe it's a bit of an overkill? I'm open to further arguments, though. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 02:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: sbaugh@catern.com, Juri Linkov , 63829@debbugs.gnu.org Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.16927568299774 (code B ref 63829); Wed, 23 Aug 2023 02:14:02 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 02:13:49 +0000 Received: from localhost ([127.0.0.1]:60722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYdNV-0002Xa-A1 for submit@debbugs.gnu.org; Tue, 22 Aug 2023 22:13:49 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:49331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYdNS-0002XL-H5 for 63829@debbugs.gnu.org; Tue, 22 Aug 2023 22:13:48 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 27E095C01AA; Tue, 22 Aug 2023 22:13:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 22 Aug 2023 22:13:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692756817; x=1692843217; bh=cx9wj3CUvRWsGgYU22Z2ywhsuAITNjzSgC/ SYDVtA4Q=; b=iHdViz/RD4cWSx4w+XAC/URkjd0DNHzI0ment7b0hmBM4KBmABe 8bojl3vhkT7phA7kDe1UJiC/ekdcp7DliKMgeIeizvPTdfs5TDFAUeN3OiHAXzJb Hc8mj9dDuHDhxZKRn18WWTsNi44NOu6vafm0iuqOv3bYK6un0it3AE3X7zygYuoe jE+qqcMMsMU1W6zNCH8vo9cL+CeaJSEFE3IfKmlIv5kkEDUygaMRcvCYPZpalkPr 9IyPBlabgXffp/lrlX+/eSF9PdbJ4MW2KEETFba895nM++q5posU92RFINOB2MQo 7DSv5Aa/BHRES1/dTvfsgGNGvw3KzxniBwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692756817; x=1692843217; bh=cx9wj3CUvRWsGgYU22Z2ywhsuAITNjzSgC/ SYDVtA4Q=; b=r3pTNmd5dbLh7e8JzfY6XOD6YmXn4kTUY6KxFYWbDhWIYMA9v49 GtzMpa0HVgPSAbyvMxQAE992V4uyJRNNgvU1gvITTny/LCfTP0aMCkkp5mySW6bY ea+3vUz08mJjZDJ17GYS302QzSth1FOAcUSiSmCg9Xj/SOS+PQob0N2Kybo86hVl RflOUPR3+rdUrR3ZzUWXS95IygDmCcLNX6C5bVjIP6N271brrQsGpj6s6/qj69S0 axRfd5h3MvOZu4tUzW165hXw9KSYRem8Ew9TN0hZdiC+OzzyRL4+xAOCc91HaKd9 aXPWTDROZ3jJt6ex9BSsi9plQ0wN2ana3rg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvvddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Aug 2023 22:13:35 -0400 (EDT) Message-ID: Date: Wed, 23 Aug 2023 05:13:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 17/08/2023 23:12, Spencer Baugh wrote: > Spencer Baugh writes: >> In a subsequent mail I'll send a patch for the "future history" >> behavior of project-find-dir too. (yet to be written) > Here is that. Seems like a straightforward generalization, and > something that a user would expect to work. Thanks! Installed as-is, with a small rewrite of the commit message. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 02:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: sbaugh@catern.com, 63829@debbugs.gnu.org, Juri Linkov Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169275759810993 (code B ref 63829); Wed, 23 Aug 2023 02:27:02 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 02:26:38 +0000 Received: from localhost ([127.0.0.1]:60731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYdZu-0002rE-1u for submit@debbugs.gnu.org; Tue, 22 Aug 2023 22:26:38 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:60615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYdZq-0002qy-VK for 63829@debbugs.gnu.org; Tue, 22 Aug 2023 22:26:36 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 73D665C025D; Tue, 22 Aug 2023 22:26:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 22 Aug 2023 22:26:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692757586; x=1692843986; bh=C2O+k7YjkyDqyNo0PIB0vjmkR5lGsBkMbJP tOSzyht8=; b=BC992l7bVeFMUSsmTAlUbcCncrrSH0eZ1W9o/pzlX63tkXC6JSX y6rtqBGIT36+olMUZ0zPkaH0jj+JjwDveqWraaoRN0TKhEJv14lAAaQVlXa9PYwf QaUUf0eSKIT7vSaa5eYtzEjWKnUKOuGI/qIHHzVDxMXRo3hjFeumNj9TS1wrdp4u pZYuUG/kAeDZ+BxH0m79LGZc3p5vhFrgTbhXzN/3M8EC/5shBDOVOwYG8xRuVcUq JWr8K0jpg2ANndoBA7lLpoQXB3W4frN+vfLrD++RtJYnWK4ooU3GbpUMCvLEC0pq X9Ailq51XGff5SVFmjc+xxVk1L5apjTp7aA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692757586; x=1692843986; bh=C2O+k7YjkyDqyNo0PIB0vjmkR5lGsBkMbJP tOSzyht8=; b=b5UvjSKtObk6LA3RjKFD4QnvL48ztWVwe0MuMRwQYEbN91DTryX M2U7lMNh49U8bP/C0m1bTsSar7zYn3TGp1wDzMWqWgMfM9GCoNeqxtv9M7MP7Oyd SWOuMI47ggdPe4AV35jxKowoKyvhAMLUWc7nLk86wNBaHcelWhoJwmmVVQaP/eH3 vMcBTprom/ZGgSYrX9YQsRAYZTk4CT6SRkm2770joeb5CrjWjkdTCy8TgBwSR3vs +i7PHmSDRXs0pHBNEYp+fi2yK4BoklXVpGB6S3UVecaMmQc3O192cznoA1dPsYBj An1IpSR4IdJQKothXbOz8m270cy3XdfumZg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvvddgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Aug 2023 22:26:24 -0400 (EDT) Message-ID: Date: Wed, 23 Aug 2023 05:26:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 17/08/2023 22:41, Spencer Baugh wrote: > Also, I realized just now that this should probably affect > project-find-dir as well, as should my previous patch adding > project-relative future history. (I actually coincidentally just now > got a user request for "switch between projects and stay in the same > dir") > > So here's a revised version of this history change which also affects > project-find-dir. In a subsequent mail I'll send a patch for the > "future history" behavior of project-find-dir too. (yet to be written) Installed, with a few alterations: - project--expand-file-name -> project--transplant-file-name (seems more explicit for understanding) - The new option renamed to project-file-history-behavior with values t or 'relativize. I thought about removing it, but after all, the change is a bit exotic, so there's bound to be people who would want to disable it. And the new name is also more extensible (extra behaviors I could think of by now: 'relativize-when-exists or 'separate -- the latter could mean to use separate history var other than file-name-history). No hurry to implement any of those, though. - project-or-external-find-file needs some special handling of the relativization when external file names are chosen. Better solutions welcome. - Announcement in NEWS. :-) From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Spencer Baugh , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169281464524563 (code B ref 63829); Wed, 23 Aug 2023 18:18:02 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 18:17:25 +0000 Received: from localhost ([127.0.0.1]:35155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYsQ0-0006O6-Sh for submit@debbugs.gnu.org; Wed, 23 Aug 2023 14:17:25 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:45369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYsPs-0006NS-Du for 63829@debbugs.gnu.org; Wed, 23 Aug 2023 14:17:18 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id EA91A1C0004; Wed, 23 Aug 2023 18:17:04 +0000 (UTC) From: Juri Linkov In-Reply-To: (Dmitry Gutov's message of "Wed, 23 Aug 2023 05:26:23 +0300") Organization: LINKOV.NET References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> Date: Wed, 23 Aug 2023 20:52:58 +0300 Message-ID: <861qfty6ul.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > - The new option renamed to project-file-history-behavior with values t or > 'relativize. I thought about removing it, but after all, the change is > a bit exotic, so there's bound to be people who would want to disable > it. And the new name is also more extensible (extra behaviors I could > think of by now: 'relativize-when-exists or 'separate -- the latter could > mean to use separate history var other than file-name-history). No hurry > to implement any of those, though. > - project-or-external-find-file needs some special handling of the > relativization when external file names are chosen. Better solutions > welcome. > - Announcement in NEWS. :-) A typo in NEWS? 'relative' -> 'relativize' Also to reduce confusion for everyone who will look at it, better to rename the property to 'project-root' in: (propertize file 'project (project-root project)))) PS: The docstring mentions the limitation: "This only affects history entries added by earlier calls to `project-find-file'". There is no way to remove this limitation? Maybe some clever way to match every file name from the history against the list of all known project roots to find the root on the file name without property. This will also work when the file history is restored from the desktop file or by savehist.el. From unknown Tue Jun 17 01:48:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 18:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63829 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: Spencer Baugh , 63829@debbugs.gnu.org, sbaugh@catern.com Received: via spool by 63829-submit@debbugs.gnu.org id=B63829.169281517525455 (code B ref 63829); Wed, 23 Aug 2023 18:27:02 +0000 Received: (at 63829) by debbugs.gnu.org; 23 Aug 2023 18:26:15 +0000 Received: from localhost ([127.0.0.1]:35180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYsYZ-0006cU-3R for submit@debbugs.gnu.org; Wed, 23 Aug 2023 14:26:15 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:45567) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYsYU-0006cD-Np for 63829@debbugs.gnu.org; Wed, 23 Aug 2023 14:26:13 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B9F315C005F; Wed, 23 Aug 2023 14:26:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 23 Aug 2023 14:26:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1692815161; x=1692901561; bh=1+fnpw2qRDrD5Q/bt94ClmW+XWKjHqzvnHp 0c+zC0jc=; b=CTBByg7UQ7e7IrGp5iwa3fuuTgVdMB+yhua67uW3Q+DZpFbB5Oq /sZ0tvp8HZPoCLROY3taBV/sNiVs+8JAeGEORhJHDc1SMfRSutLfSUtVf8eH22tz yr+SUY5f3BBANSYS1H/GswXdzmaQt34+pwqjdc8a2o6ZjJHGX38aiw6LEI1LsvD8 f/yY/VYTa9PWOPKaFwEW8DMo6V1ZO6T1TXlKLyMme7X6BcKNhGSjQowsEW83ZsLK m4tnhoDJRTZHFVHFiybtJF7bRemglTPQD8vmG5VvdJ9nONPmimoRl4Emaruolu8C 3qPkWxPOc3TBHBuXtGnUJNm55JljNUStRZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692815161; x=1692901561; bh=1+fnpw2qRDrD5Q/bt94ClmW+XWKjHqzvnHp 0c+zC0jc=; b=J9LeMVE1YaKYSactA6zeu4xCX5hIjqbufs4JAckyGG6F3//VuZq o017P3vqrAFwni7zjmQ/POcW4Y3Ge/67t62xF7kS35uqrIMy1vyND6R2oVfYRwCj cdievAIhA4RXz8bLJYpVE32dka0NCq1ymboDrPcXil6xNVf5mcjQlsD9FJLWTxnQ cfRcAw8YWRqZ6EbJW71GIKuEa4z12lmz++3TV0qWOdoKw4LyNdzTLVEJ5boZ9n8S dvJbSIAj1w5Qdro+Kt+rVQ76c92HSr0cCIyVXTVKnEUNR83B5ororJX1Df9S39iU TcgwN2pux7wjyyobR5vffNLEHv+DxOwlyqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvgedguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeev ledvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Aug 2023 14:26:00 -0400 (EDT) Message-ID: <6f19838d-b7c8-4047-6532-37adc1701812@gutov.dev> Date: Wed, 23 Aug 2023 21:25:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US References: <16b64d95-35e9-ef94-2c54-17b670111f0f@gutov.dev> <86h6rnw7gm.fsf@mail.linkov.net> <3e404df1-b3a9-f9e3-4270-f42df8b704c7@gutov.dev> <87a5uti6mo.fsf@catern.com> <73a695f3-7c6a-0e50-41dd-61f8269f6ecf@gutov.dev> <875y5fitiq.fsf@catern.com> <861qfty6ul.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <861qfty6ul.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.7 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) On 23/08/2023 20:52, Juri Linkov wrote: >> - The new option renamed to project-file-history-behavior with values t or >> 'relativize. I thought about removing it, but after all, the change is >> a bit exotic, so there's bound to be people who would want to disable >> it. And the new name is also more extensible (extra behaviors I could >> think of by now: 'relativize-when-exists or 'separate -- the latter could >> mean to use separate history var other than file-name-history). No hurry >> to implement any of those, though. >> - project-or-external-find-file needs some special handling of the >> relativization when external file names are chosen. Better solutions >> welcome. >> - Announcement in NEWS. :-) > > A typo in NEWS? 'relative' -> 'relativize' Fixed, thanks. > Also to reduce confusion for everyone who will look at it, > better to rename the property to 'project-root' in: > > (propertize file 'project (project-root project)))) It seemed shorter and just as obvious when looking at the propertized value. But if everyone thinks the change should be made, I don't mind. > PS: The docstring mentions the limitation: "This only affects > history entries added by earlier calls to `project-find-file'". > There is no way to remove this limitation? Maybe some clever way > to match every file name from the history against the list > of all known project roots to find the root on the file name > without property. This will also work when the file history > is restored from the desktop file or by savehist.el. That is doable, at the cost of having imprecise results (and some odd-looking history entries from time to time). Is that cost low enough?