From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: dmitry@gutov.dev, bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 May 2024 06:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 70996@debbugs.gnu.org Cc: Dmitry Gutov X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Dmitry Gutov Received: via spool by submit@debbugs.gnu.org id=B.17159287369264 (code B ref -1); Fri, 17 May 2024 06:53:01 +0000 Received: (at submit) by debbugs.gnu.org; 17 May 2024 06:52:16 +0000 Received: from localhost ([127.0.0.1]:53481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7rRw-0002PM-2P for submit@debbugs.gnu.org; Fri, 17 May 2024 02:52:16 -0400 Received: from lists.gnu.org ([209.51.188.17]:52676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s7rRt-0002PG-Gg for submit@debbugs.gnu.org; Fri, 17 May 2024 02:52:14 -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 1s7rRq-0006i6-GI for bug-gnu-emacs@gnu.org; Fri, 17 May 2024 02:52:10 -0400 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s7rRo-0001ty-6g for bug-gnu-emacs@gnu.org; Fri, 17 May 2024 02:52:10 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id B4B3B1BF219 for ; Fri, 17 May 2024 06:52:01 +0000 (UTC) From: Juri Linkov Organization: LINKOV.NET Date: Fri, 17 May 2024 09:36:22 +0300 Message-ID: <867cft2ggx.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: multipart/mixed; boundary="=-=-=" X-GND-Sasl: juri@linkov.net Received-SPF: pass client-ip=2001:4b98:dc4:8::228; envelope-from=juri@linkov.net; helo=relay8-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) 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.6 (--) --=-=-= Content-Type: text/plain (thing-at-point 'filename) in project-find-file is a very useful feature that often helps to use a string under point as a partial file name to match a project file name as substring. So it's like 'M-.' that navigates by file names instead of identifiers. But the problem is that in this case it drops the current file name as the default value that is also useful in many cases. Fortunately, the minibuffer supports a list of default values, like in the following patch: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=project-find-file-at-point.patch diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index a95d1267dd2..5e6516b3b64 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1077,8 +1130,9 @@ project-find-file (dirs (list root)) (project-files-relative-names t)) (project-find-file-in - (or (thing-at-point 'filename) - (and buffer-file-name (project--find-default-from buffer-file-name pr))) + (delq nil (list (and buffer-file-name (project--find-default-from + buffer-file-name pr)) + (thing-at-point 'filename))) dirs pr include-all))) ;;;###autoload @@ -1100,8 +1154,9 @@ project-or-external-find-file (project-external-roots pr))) (project-file-history-behavior t)) (project-find-file-in - (or (thing-at-point 'filename) - (and buffer-file-name (project--find-default-from buffer-file-name pr))) + (delq nil (list (and buffer-file-name (project--find-default-from + buffer-file-name pr)) + (thing-at-point 'filename))) dirs pr include-all))) (defcustom project-read-file-name-function #'project--read-file-cpd-relative @@ -1163,11 +1218,14 @@ project--read-file-cpd-relative (setq all-files (delete common-parent-directory all-files)) t)) - (mb-default (if (and common-parent-directory - mb-default - (file-name-absolute-p mb-default)) - (file-relative-name mb-default common-parent-directory) - mb-default)) + (mb-default (mapcar (lambda (mb-default) + (if (and common-parent-directory + mb-default + (file-name-absolute-p mb-default)) + (file-relative-name + mb-default common-parent-directory) + mb-default)) + (ensure-list mb-default))) (substrings (mapcar (lambda (s) (substring s cpd-length)) all-files)) (_ (when included-cpd (setq substrings (cons "./" substrings)))) --=-=-=-- From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 May 2024 16:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 70996@debbugs.gnu.org Cc: Dmitry Gutov Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171691405624430 (code B ref 70996); Tue, 28 May 2024 16:35:01 +0000 Received: (at 70996) by debbugs.gnu.org; 28 May 2024 16:34:16 +0000 Received: from localhost ([127.0.0.1]:46859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBzmC-0006Lw-62 for submit@debbugs.gnu.org; Tue, 28 May 2024 12:34:16 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:49647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sBzmA-0006Lf-Su; Tue, 28 May 2024 12:34:15 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 46A8420007; Tue, 28 May 2024 16:33:35 +0000 (UTC) From: Juri Linkov In-Reply-To: <867cft2ggx.fsf@mail.linkov.net> (Juri Linkov's message of "Fri, 17 May 2024 09:36:22 +0300") Organization: LINKOV.NET References: <867cft2ggx.fsf@mail.linkov.net> Date: Tue, 28 May 2024 19:32:20 +0300 Message-ID: <8634q1c2y2.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 (-) close 70996 30.0.50 thanks > (thing-at-point 'filename) in project-find-file is a very useful feature > that often helps to use a string under point as a partial file name > to match a project file name as substring. So it's like 'M-.' > that navigates by file names instead of identifiers. > > But the problem is that in this case it drops the current file name > as the default value that is also useful in many cases. > > Fortunately, the minibuffer supports a list of default values, > like in the following patch: With no objections this is pushed to master. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Jun 2024 00:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov , 70996@debbugs.gnu.org Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171780655626024 (code B ref 70996); Sat, 08 Jun 2024 00:30:02 +0000 Received: (at 70996) by debbugs.gnu.org; 8 Jun 2024 00:29:16 +0000 Received: from localhost ([127.0.0.1]:48960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFjxL-0006lc-GD for submit@debbugs.gnu.org; Fri, 07 Jun 2024 20:29:16 -0400 Received: from fhigh3-smtp.messagingengine.com ([103.168.172.154]:53531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sFjxI-0006l7-63 for 70996@debbugs.gnu.org; Fri, 07 Jun 2024 20:29:14 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 8A5CF114014F; Fri, 7 Jun 2024 20:28:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 07 Jun 2024 20:28:51 -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:subject:subject:to:to; s=fm3; t=1717806531; x=1717892931; bh=N4LJFCkK7NsvFmhYLQCHaFYSGr5dkEItK3uZBkSrsWo=; b= PAncvGXIKE0GjsDTVEaAzMQtOlS8oDdXFIbBMjaJnK+gTD7aQsXCsKuUw1bYAGL+ Gv70LByR5RX/DSEnLiKUSYXfA81HIpt7GRtYVNXqGCEUA4rSiKvYPiYAgp1WhzyM c9BXWonXCChaWonviurAXwEPggufmTVhf3z3GTuVeAgBdlU4IqNoMAmgSyBQbYXi WKq/RxvGs1wy3dVWklfvyBrzrJlyb0tN3eGvvFwjVCeW61XjegxNUGHQrFN9OkBu 8bowy3mg+8ozNMTrw8jldTOEqOdy1kWxw7qIE3/9PsBq80fvXVLzoiXX/YJHj89w ++VYq9sNC7mzcQWYiAAdVg== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1717806531; x= 1717892931; bh=N4LJFCkK7NsvFmhYLQCHaFYSGr5dkEItK3uZBkSrsWo=; b=o 4kE/6sC9wvlv+hVLn5eLiGZnwszq2FU9X/glLWEQfLqNyfnLtEaop47LK6MZgpGv 2j+p5uQ9YYRmZK5DZvWkUlQgl1QSTARpT/19mHjSob3goE7fQ+UOwKU/dbRb5QOo VSC2Er7w6GyviKMKABDmiRNf3T0CE8j36WHkXlNLXo4aZt/TaOMu+oCHuGKuCceS 5RR+IEI5Q0mE1FtjPaYTC+y8wR61L1Lcvg6QgCt6skzrpWB0wLUBvw0jNbI44cdi Bw0PG5leGj20FpMUQbVD5wOqtR5p9fbJIZ3QoPsyahEuRwgOC0Twxs6DrCZtt6mG V26v3/E72OYk9RoOPzauw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedtvddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpedthfeuvddtveelgeeuleevvdejveehffevveehvdeuffdtfefhvdeugefgtefg tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 7 Jun 2024 20:28:50 -0400 (EDT) Message-ID: Date: Sat, 8 Jun 2024 03:28:48 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <867cft2ggx.fsf@mail.linkov.net> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <867cft2ggx.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 (-) Hi Juri, On 17/05/2024 09:36, Juri Linkov wrote: > But the problem is that in this case it drops the current file name > as the default value that is also useful in many cases. > > Fortunately, the minibuffer supports a list of default values, > like in the following patch: This seems like a good idea, except it reverses the priority: previously, if file-at-point was present, it would be the default, not the current file name. So how about this? diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 8a8b4fc33d6..b855dcd4546 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1080,9 +1080,9 @@ project-find-file (dirs (list root)) (project-files-relative-names t)) (project-find-file-in - (delq nil (list (and buffer-file-name (project--find-default-from - buffer-file-name pr)) - (thing-at-point 'filename))) + (delq nil (list (thing-at-point 'filename) + (and buffer-file-name (project--find-default-from + buffer-file-name pr)))) dirs pr include-all))) ;;;###autoload @@ -1104,9 +1104,9 @@ project-or-external-find-file (project-external-roots pr))) (project-file-history-behavior t)) (project-find-file-in - (delq nil (list (and buffer-file-name (project--find-default-from - buffer-file-name pr)) - (thing-at-point 'filename))) + (delq nil (list (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 From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Jun 2024 17:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 70996@debbugs.gnu.org Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171795245526436 (code B ref 70996); Sun, 09 Jun 2024 17:01:02 +0000 Received: (at 70996) by debbugs.gnu.org; 9 Jun 2024 17:00:55 +0000 Received: from localhost ([127.0.0.1]:49277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGLuY-0006sI-OZ for submit@debbugs.gnu.org; Sun, 09 Jun 2024 13:00:54 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:57831) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGLuW-0006rt-IU for 70996@debbugs.gnu.org; Sun, 09 Jun 2024 13:00:53 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 5FE181BF206; Sun, 9 Jun 2024 17:00:28 +0000 (UTC) From: Juri Linkov In-Reply-To: (Dmitry Gutov's message of "Sat, 8 Jun 2024 03:28:48 +0300") Organization: LINKOV.NET References: <867cft2ggx.fsf@mail.linkov.net> Date: Sun, 09 Jun 2024 19:51:17 +0300 Message-ID: <86cyoqjdcq.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 (-) >> But the problem is that in this case it drops the current file name >> as the default value that is also useful in many cases. >> Fortunately, the minibuffer supports a list of default values, >> like in the following patch: > > This seems like a good idea, except it reverses the priority: previously, > if file-at-point was present, it would be the default, not the current file > name. I mentioned in the log message that this change was intentional. > So how about this? The reason of this change to make the first item of the M-n list more deterministic: 1. when there is no thing-at-point, then the first item will be buffer-file-name; 2. and also when there is a thing-at-point, the first item will remain buffer-file-name. Otherwise, it was too unpredictable: after typing 'M-n RET' to use buffer-file-name, it often did a wrong thing when point happened to stay in a thing-at-point. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Jun 2024 15:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 70996@debbugs.gnu.org Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.17181210762602 (code B ref 70996); Tue, 11 Jun 2024 15:52:02 +0000 Received: (at 70996) by debbugs.gnu.org; 11 Jun 2024 15:51:16 +0000 Received: from localhost ([127.0.0.1]:35813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3mG-0000ft-7V for submit@debbugs.gnu.org; Tue, 11 Jun 2024 11:51:16 -0400 Received: from fhigh1-smtp.messagingengine.com ([103.168.172.152]:55981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH3mE-0000fI-Bw for 70996@debbugs.gnu.org; Tue, 11 Jun 2024 11:51:15 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id DEABF114017E; Mon, 10 Jun 2024 20:02:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 10 Jun 2024 20:02: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:subject:subject:to:to; s=fm3; t=1718064124; x=1718150524; bh=555vpUD6qX/kloE/DNQxhLdSPTZwT4ivVcv6ryCeCgo=; b= Is0DSGYLGPTgAg4/+Ky/TgJBN0KtDUTeGqiZDi6ODJTYjnVCV4RRe+DP9JQ4F0L9 +YiGEu8jujKH/szAVzYlsk6NuPPy7k5ga6xB2rZHMNxs2qxP/3inSDykqfqLyyqV rmw1tPOQ2QCzjhsUB9z2ZUsWp3nSRqsvoeNBI9IJjUjS+9VoNAZ6bZu20dR6J2jD aF+783+orUjbVo8CdNWOc6Zg7cpp6GoiKwUDkEzMzHU3oghfqNKabKLE7O0YZI8a E48LqLxL8bTkvXfHwcarwa6/sznYyY8a+2XfAXU08bDEebX43FCEWjffjJQNc3B8 g9ce3KqNvt0BPQNBmSuqFA== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718064124; x= 1718150524; bh=555vpUD6qX/kloE/DNQxhLdSPTZwT4ivVcv6ryCeCgo=; b=T nyv0XkPCRl8qCYnnc2hVty6SzuLtlwUcARo1Sya5MA0xyIqZ9dJFXH5stiBb8wkt ghgVJ85lerlWvBHfymG/ntws/wPiGlIpPPoP08+d75KcnPZKqgmIPyGGIlVft05u PiAfHXZ/hkoaZ1u9eVKj1DCEMTseNmQa5KCWsnar30rls2seZj5mRnkzJXgx5d2z 6gZctGHgnbhqLUXA/xK2B+JYhWNhAqpKzeZEtqYxnCf98evvFXWfM9lOUFuDagWH zl1/nwAhtmgf5sdwIwVU/iO2zhyOSJUJ2acTs/J8fJQorgh77cUMdZpshjAsnqLo wuLts9qr3s6i6gccxINHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduuddgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Jun 2024 20:02:03 -0400 (EDT) Message-ID: <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Date: Tue, 11 Jun 2024 03:02:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86cyoqjdcq.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 09/06/2024 19:51, Juri Linkov wrote: >>> But the problem is that in this case it drops the current file name >>> as the default value that is also useful in many cases. >>> Fortunately, the minibuffer supports a list of default values, >>> like in the following patch: >> >> This seems like a good idea, except it reverses the priority: previously, >> if file-at-point was present, it would be the default, not the current file >> name. > > I mentioned in the log message that this change was intentional. > >> So how about this? > > The reason of this change to make the first item of the M-n list > more deterministic: Okay, now I see that line, thanks. > 1. when there is no thing-at-point, then the first item will be > buffer-file-name; > > 2. and also when there is a thing-at-point, the first item > will remain buffer-file-name. > > Otherwise, it was too unpredictable: after typing 'M-n RET' > to use buffer-file-name, it often did a wrong thing > when point happened to stay in a thing-at-point. Okay, but I'm not sure predictability must be the overriding principle. If 10 people use the thing-at-point default, for example, and only 2 use the buffer-file-name default (or, say, the number of users is the same, but the frequency is higher for the latter), we'd be forcing a lot of people to press C-n to jump over the default they don't use. What's the main usage scenario for the buffer-file-name default? I recall Spencer describing his workflow, but that seems only useful when you have a lot of branches, checked out specifically into worktrees or similar, and switch between them often (while explicitly staying in the "same" file during a switch). Do you do something similar? From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Jun 2024 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 70996@debbugs.gnu.org Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171812579622608 (code B ref 70996); Tue, 11 Jun 2024 17:10:02 +0000 Received: (at 70996) by debbugs.gnu.org; 11 Jun 2024 17:09:56 +0000 Received: from localhost ([127.0.0.1]:36176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH50O-0005sV-A2 for submit@debbugs.gnu.org; Tue, 11 Jun 2024 13:09:56 -0400 Received: from relay2-d.mail.gandi.net ([217.70.183.194]:37207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH50M-0005s5-8s for 70996@debbugs.gnu.org; Tue, 11 Jun 2024 13:09:55 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 1B99040004; Tue, 11 Jun 2024 17:09:25 +0000 (UTC) From: Juri Linkov In-Reply-To: <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> (Dmitry Gutov's message of "Tue, 11 Jun 2024 03:02:01 +0300") Organization: LINKOV.NET References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Date: Tue, 11 Jun 2024 19:58:53 +0300 Message-ID: <86bk47zbne.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 reason of this change to make the first item of the M-n list >> more deterministic: > > Okay, now I see that line, thanks. > >> 1. when there is no thing-at-point, then the first item will be >> buffer-file-name; >> 2. and also when there is a thing-at-point, the first item >> will remain buffer-file-name. >> Otherwise, it was too unpredictable: after typing 'M-n RET' >> to use buffer-file-name, it often did a wrong thing >> when point happened to stay in a thing-at-point. > > Okay, but I'm not sure predictability must be the overriding principle. > > If 10 people use the thing-at-point default, for example, and only 2 use > the buffer-file-name default (or, say, the number of users is the same, but > the frequency is higher for the latter), we'd be forcing a lot of people to > press C-n to jump over the default they don't use. > > What's the main usage scenario for the buffer-file-name default? I recall > Spencer describing his workflow, but that seems only useful when you have > a lot of branches, checked out specifically into worktrees or similar, and > switch between them often (while explicitly staying in the "same" file > during a switch). Do you do something similar? I recall Spencer mentioned that 'C-x p f M-n' is the quickest way getting a file name relative to the project root for using it for external references. And I use the same case very often too. (I mean the case of '(project--find-default-from buffer-file-name pr)'). OTOH, thing-at-point is too specific to a programming language, and can be used to navigate source code by placing point on an "include" directive with relative a file name, then 'C-x p f M-n M-n' will help to find the referenced file. This is a poor man's way for source code navigation, since 'M-.' doesn't support navigation by project relative file names. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Jun 2024 20:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 70996@debbugs.gnu.org Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.17181363028391 (code B ref 70996); Tue, 11 Jun 2024 20:06:02 +0000 Received: (at 70996) by debbugs.gnu.org; 11 Jun 2024 20:05:02 +0000 Received: from localhost ([127.0.0.1]:36294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7jq-0002BG-BU for submit@debbugs.gnu.org; Tue, 11 Jun 2024 16:05:02 -0400 Received: from wfout2-smtp.messagingengine.com ([64.147.123.145]:55821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sH7jn-0002Ad-Gy for 70996@debbugs.gnu.org; Tue, 11 Jun 2024 16:05:00 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.west.internal (Postfix) with ESMTP id 5B6221C0015C; Tue, 11 Jun 2024 16:04:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 11 Jun 2024 16:04:55 -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:subject:subject:to:to; s=fm3; t=1718136295; x=1718222695; bh=U7IdOXNfTXvaRiX9urZplOAXEl4oBAux3bKpe1Eoxco=; b= DwcmO3ITRfMOKPSGGXPFd3YkP2G8ChoQ5M4jRh3QH8X9X4ZZ7PP9e09u6AvmhxGZ z/f6JjomTdfDBq+2G4suZrARtTZakJr6Iero1TbAoYG0HR+kg1I9qkp4SucnruPk pDkPeEwDg2aPeylBdEsKgymUTndVLzN77keIxQm7JJbiG6kUYy12G1XyxZr2pM2F cbnuvZsLpYgG7eRKDlYbPkIyarkIorKkMwv+EE0CbS22GA1oo7EQX7mBeV7XvLXJ ZSuMZ6XR5nyju67CtLbljujFmalx4TUHVJvG8rkXbBLeJC6q+QWD4vicyyJguu0V 1LmDOyeQrQZUxpPPkVm9bw== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718136295; x= 1718222695; bh=U7IdOXNfTXvaRiX9urZplOAXEl4oBAux3bKpe1Eoxco=; b=A nJ/J/9/fJgrub/CU9BssR5LvzC4Zmgwuxz90vghp/LQJ/8zp87lY9ek+UHvwihMZ IjQqz/0Zg93drZrF5F9IRKuCgcNEPD34pQRIlaWYnLGFL9gJSHP33rVFieKMKZSz TgdJfrcLSgMwpJHqz9KTWkIs8ElsMeqgjI713JkKc1tTehwA+XI0LIaUunET0Vbs K9StzIhVr2bAWHfAHz+yNhhnT6BHWYHmuSWo/Cor+uWlyxFRXgmTN0tfvKnGCAB4 Fpi21Q5yC8Qp5yiKDo578IKSiuaCTjXiih9MvBsVRqW4q9G9W/pSJ/y5gm7IfRg4 AB7wcU3J5H4wzwgwS8ZbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduvddgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 11 Jun 2024 16:04:53 -0400 (EDT) Message-ID: Date: Tue, 11 Jun 2024 23:04:52 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> <86bk47zbne.fsf@mail.linkov.net> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86bk47zbne.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 11/06/2024 19:58, Juri Linkov wrote: >> What's the main usage scenario for the buffer-file-name default? I recall >> Spencer describing his workflow, but that seems only useful when you have >> a lot of branches, checked out specifically into worktrees or similar, and >> switch between them often (while explicitly staying in the "same" file >> during a switch). Do you do something similar? > I recall Spencer mentioned that 'C-x p f M-n' is the quickest way getting > a file name relative to the project root for using it for external references. > And I use the same case very often too. (I mean the case of > '(project--find-default-from buffer-file-name pr)'). Hmm, that sounds good and useful, but it's also, like, a secondary purpose - using a command's history while aborting the command itself. To copy the relative file name, you also need to select it, right? Doesn't that mean that you will look at the minibuffer first? Or do you do like C-x p f M-n C-h C-w automatically? > OTOH, thing-at-point is too specific to a programming language, > and can be used to navigate source code by placing point on > an "include" directive with relative a file name, then > 'C-x p f M-n M-n' will help to find the referenced file. > This is a poor man's way for source code navigation, since 'M-.' > doesn't support navigation by project relative file names. Sometimes it does (certain backends), but indeed this is a way to visit an included file, for example. And here the core behavior (find-file) does get executed. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Jun 2024 00:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 70996@debbugs.gnu.org, Juri Linkov Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.17181510952524 (code B ref 70996); Wed, 12 Jun 2024 00:12:01 +0000 Received: (at 70996) by debbugs.gnu.org; 12 Jun 2024 00:11:35 +0000 Received: from localhost ([127.0.0.1]:37068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHBaR-0000ee-73 for submit@debbugs.gnu.org; Tue, 11 Jun 2024 20:11:35 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:48733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHBaO-0000eQ-JS for 70996@debbugs.gnu.org; Tue, 11 Jun 2024 20:11:33 -0400 From: Spencer Baugh In-Reply-To: <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> (Dmitry Gutov's message of "Tue, 11 Jun 2024 03:02:01 +0300") References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Date: Tue, 11 Jun 2024 20:11:28 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1718151088; bh=0A6B+YIaoyCRp7mC+Xf11NEKDNoE3uQCTkGBf5L3DqA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=c5UlhDm9Fn2xCFpyI7QsjnjgJ5GNBPYxztlx5GeW1+3+5y7bUGrVAUPCItCvQwtDP u0Hm4/TtqT+usy9/LVHsTuTtKdE8ujxsz2d+5Pdo62ENmJKV7V0eQf2LnXtN3Unggi JZHI72ASqr3Kg0xx8idroT34EuF0c0qn7wMZ+YkHulgN5gFLm3piCp5tjRn8Q+pcgY TwVOf5Lw2vKRecYwDfOCyeH4veGPOe2Ln/6Mk6TP1U/xLVSBy4A0oNmOMF9MV9bF5z e8/FpwYqB681aUjwnv+0DpdT+rFQ1T2ism4wGaJNeL6ZRW9Cc2rb7n2ByBrK3rez4t kMx7Pc7xrkLPA== 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 09/06/2024 19:51, Juri Linkov wrote: >>>> But the problem is that in this case it drops the current file name >>>> as the default value that is also useful in many cases. >>>> Fortunately, the minibuffer supports a list of default values, >>>> like in the following patch: >>> >>> This seems like a good idea, except it reverses the priority: previously, >>> if file-at-point was present, it would be the default, not the current file >>> name. >> I mentioned in the log message that this change was intentional. >> >>> So how about this? >> The reason of this change to make the first item of the M-n list >> more deterministic: > > Okay, now I see that line, thanks. > >> 1. when there is no thing-at-point, then the first item will be >> buffer-file-name; >> 2. and also when there is a thing-at-point, the first item >> will remain buffer-file-name. >> Otherwise, it was too unpredictable: after typing 'M-n RET' >> to use buffer-file-name, it often did a wrong thing >> when point happened to stay in a thing-at-point. > > Okay, but I'm not sure predictability must be the overriding principle. > > If 10 people use the thing-at-point default, for example, and only 2 > use the buffer-file-name default (or, say, the number of users is the > same, but the frequency is higher for the latter), we'd be forcing a > lot of people to press C-n to jump over the default they don't use. It seems to me that we can have the best of both worlds if we match the behavior of find-file, and use something like (run-hook-with-args-until-success 'file-name-at-point-functions) rather than (thing-at-point 'file-name). The default of file-name-at-point-functions is ffap-guess-file-name-at-point, which by default only returns a filename if that file name actually exists in the filesystem. The old behavior of (thing-at-point 'file-name) often got in the way, since it would pick up any random string at point, even if it wasn't referring to an actual file name. Instead we can be like find-file and have: (delq nil (list (run-hook-with-args-until-success 'file-name-at-point-functions) buffer-file-name)) So the file name at point *does* take precedence over buffer-file-name... but the file name at point is only present when it's actually useful - that is, when the file exists. This is especially useful now that there is ffap-in-project by default, so ffap-guess-file-name-at-point will pick up relative file names in the project root. I personally never use the file-name-at-point behavior of project-find-file, but I'm happy with it being higher-precedence because it will match find-file - as long as it also matches find-file in only including filenames of existing files. > What's the main usage scenario for the buffer-file-name default? I > recall Spencer describing his workflow, but that seems only useful > when you have a lot of branches, checked out specifically into > worktrees or similar, and switch between them often (while explicitly > staying in the "same" file during a switch). Do you do something > similar? For me, two use cases: 1. Copy project-relative filename: C-x p f M-n C-a C-k 2. Switch to the same file in another project: C-x p p [type project name] f M-n RET About half of my use for 2 is switching between my emacs-29 and trunk git worktrees. (The other half is switching between checkouts of branches in Jane Street's internal monorepo) From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Jun 2024 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: 70996@debbugs.gnu.org, Juri Linkov Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171820035415471 (code B ref 70996); Wed, 12 Jun 2024 13:53:02 +0000 Received: (at 70996) by debbugs.gnu.org; 12 Jun 2024 13:52:34 +0000 Received: from localhost ([127.0.0.1]:37941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHOOv-00041R-FQ for submit@debbugs.gnu.org; Wed, 12 Jun 2024 09:52:34 -0400 Received: from fhigh6-smtp.messagingengine.com ([103.168.172.157]:37507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHOOr-000411-PR for 70996@debbugs.gnu.org; Wed, 12 Jun 2024 09:52:31 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 512A011401F4; Wed, 12 Jun 2024 09:52:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 12 Jun 2024 09:52:25 -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:subject:subject:to:to; s=fm3; t=1718200345; x=1718286745; bh=zFAVgIMc31wMt5dnQXL8dP4qbg+rePLE9aKZrUILOAc=; b= n18p5WMn7sQPFJPVBdyQWDz3f+cnEOOAY/v9Ql3+DOH3RZLWMIhtlhssyHQScoAd eGklPN2XPLoVQKPMeLmZvSY6Teb0NETLobg8ZRODzl13QI5X8LfENz3Fe7hfgEck rvfH0y2ykTeOr4vxrIKn9m9uHaHZNFVmqLIqr20wAVkZDNNhSWkF9rulSag8MkR7 lxrvhAv4viz/ji46tdy2pddmd/96MAkeKZKrBnxhOLScYtFCuJMEMTKLL10Tc5mr IvTadVaB85uhbjQFI9JXGvigArodEv+9pWris1+IP6qhBIH4v6D4c4UsxK5f9u4U goNMqyg2pXd2PAaGk7GZzg== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718200345; x= 1718286745; bh=zFAVgIMc31wMt5dnQXL8dP4qbg+rePLE9aKZrUILOAc=; b=o 6W7PCauOcT2JU/6ST5kDpzEuhONrwLH6gDRKtye/EUbw6e7dILMvV59w3oab465P PIEKCB10OzAsWhBYHKiGLpxeY6CmXaKEAbaDgi8TNIUcKoqAlq11vPsU13aqXAQR O2r5WdXwOr2Ld7Biu2x+SK2jnUlikF6idx/aUY07DVyXqlSxUNNnpriwL5L6V9pZ G01pjtPdJr1N1wB4tIzreM7kHioyrNIman9wPI0Iyd2WSizusuKboIbeNXcXWlwc Z7YaxsKso11wjgTHvgLZxdUrwrJEQFosmo4obLYO3l43CnercglDgsXay20rcSbQ Vd8gn2HaUeOf0avVvccxA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedugedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Jun 2024 09:52:23 -0400 (EDT) Message-ID: Date: Wed, 12 Jun 2024 16:52:21 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 12/06/2024 03:11, Spencer Baugh wrote: > It seems to me that we can have the best of both worlds if we match the > behavior of find-file, and use something like > (run-hook-with-args-until-success 'file-name-at-point-functions) rather > than (thing-at-point 'file-name). > > The default of file-name-at-point-functions is > ffap-guess-file-name-at-point, which by default only returns a filename > if that file name actually exists in the filesystem. > > The old behavior of (thing-at-point 'file-name) often got in the way, > since it would pick up any random string at point, even if it wasn't > referring to an actual file name. > > Instead we can be like find-file and have: > > (delq nil (list > (run-hook-with-args-until-success 'file-name-at-point-functions) > buffer-file-name)) That's an interesting suggestion, but could we rely on file-name-at-point-functions acting correctly for any project? As luck would have it, ffap-guess-file-name-at-point seems to work fine on relative file names inside a directory, and even file names without extensions, but it could miss them in some odd directory structures. > So the file name at point *does* take precedence over > buffer-file-name... but the file name at point is only present when it's > actually useful - that is, when the file exists. Sounds good to me. > This is especially useful now that there is ffap-in-project by default, > so ffap-guess-file-name-at-point will pick up relative file names in the > project root. This one won't pick up base file names inside some directory. Or just names relative to a subdirectory. > I personally never use the file-name-at-point behavior of > project-find-file, but I'm happy with it being higher-precedence because > it will match find-file - as long as it also matches find-file in only > including filenames of existing files. In case you agree with my concerns above (I'm happy to be convinced otherwise), we could try to do something like (completion-try-completion (thing-at-point 'filename) TABLE nil LEN) Unfortunately, we currently call thing-at-point earlier than project-files is called. So some rethinking would have to be done (a breaking change to project-find-file-in, apparently). >> What's the main usage scenario for the buffer-file-name default? I >> recall Spencer describing his workflow, but that seems only useful >> when you have a lot of branches, checked out specifically into >> worktrees or similar, and switch between them often (while explicitly >> staying in the "same" file during a switch). Do you do something >> similar? > > For me, two use cases: > > 1. Copy project-relative filename: > C-x p f M-n C-a C-k > > 2. Switch to the same file in another project: > C-x p p [type project name] f M-n RET > > About half of my use for 2 is switching between my emacs-29 and trunk > git worktrees. (The other half is switching between checkouts of > branches in Jane Street's internal monorepo) I guess my question was whether you do it frequently enough that the change in the order would made a big difference. But the answer you gave above is even better. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Jun 2024 20:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: 70996@debbugs.gnu.org, Stefan Monnier , Juri Linkov Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171822265731925 (code B ref 70996); Wed, 12 Jun 2024 20:05:02 +0000 Received: (at 70996) by debbugs.gnu.org; 12 Jun 2024 20:04:17 +0000 Received: from localhost ([127.0.0.1]:46515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHUCf-0008Iq-7C for submit@debbugs.gnu.org; Wed, 12 Jun 2024 16:04:17 -0400 Received: from fout4-smtp.messagingengine.com ([103.168.172.147]:53075) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sHUCd-0008IM-FP for 70996@debbugs.gnu.org; Wed, 12 Jun 2024 16:04:16 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id D23FA13801B4; Wed, 12 Jun 2024 16:04:10 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 12 Jun 2024 16:04: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:subject:subject:to:to; s=fm3; t=1718222650; x=1718309050; bh=XD/EJQHX97+zEKeVO25VoJxWNedgPHUlj1DCqm1h/zU=; b= WOoraGHQX3JWV3taJ9/n6E3p4Fc24gAUHQfL5lAJE6VOv5doeptr/W0x05OATnrF YuV0wWm4hCzp1w2JWZ4J6UKajdmGsU5p1tcvB/9Kxlcn8rS7SjNZCc4PP8P4TOxP Vp0m8FSoOj1x2TOZwK0Ei4jXUwvDIcFiaihZiu1hnD6nabhnMCTefjfgOIDvWz8d Zg707WuLTcVd59em45JCiuCmYU1rB26Yr9MBCwD5CmWD+aROPbwJGLCrIhriyn6V T6D8kahWmAxptU6v+GBajq3W/DKMMq0WnoitwPADPm+zBZpdIRZwBsWOzqYWsxYu we9ye1pyor6bhyWrzTUXFg== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718222650; x= 1718309050; bh=XD/EJQHX97+zEKeVO25VoJxWNedgPHUlj1DCqm1h/zU=; b=J s5P832eZDwGVy2BxUSrKZwj6i+XmIGcZ+n9pcsDB0/+fOB0z/kMJkiaCVHeSDudL 57ABnNluMk5k9tlZhn25DV79eqdqLBy94rNq3Mn8Rqqayb30wx18S+op5Bqhoplb l5xviWVZYdpZnCGIvKTdXalr4xql/Po57eCuzqRZ59cEAZxA2WoiO1Il01KeTmqt iBg6DukMG7HBVsvW/Qqezn7pCUk9Di6n6lPF52S0ash839lyImV5zr1xDFOOTfvR ynynqtoA7T8Mb+4dXJ5EubVuG3xoEVE7UK9PtPpJJ0f7QJh5tzNlejWoQMzMWPW8 g1GS5mHUgkdjnbN2eW0nQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedugedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuhffvvehfjggtgfesthekredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpedvleeijeevkeejleffgeduiedujeffhfevudduffdvveetkeegveffjefg ffelueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Jun 2024 16:04:09 -0400 (EDT) Message-ID: Date: Wed, 12 Jun 2024 23:04:07 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Dmitry Gutov References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 12/06/2024 16:52, Dmitry Gutov wrote: > > In case you agree with my concerns above (I'm happy to be convinced > otherwise), we could try to do something like > >   (completion-try-completion (thing-at-point 'filename) >                              TABLE nil LEN) > > Unfortunately, we currently call thing-at-point earlier than > project-files is called. So some rethinking would have to be done (a > breaking change to project-find-file-in, apparently). Actually, we could do the check inside project-find-file-in. The tricky part is that project--file-completion-table (which adds the metadata property to the table, allowing for laxer matching due to the entry in completion-category-defaults) is called later - in project--read-file-cpd-relative and project--read-file-absolute. And one reason for that is project--read-file-cpd-relative mapcar's the list through 'substring'. Which requires a list as input, and IIRC so the previous version first called 'all-completions'. Which wasn't free, especially with larger lists - but perhaps since the completion table is functional we could get away with returning a copy of the list when the prefix is empty... Or maybe project--read-file-cpd-relative could use something like completion-table-subvert, which seems like it can avoid extra copying... Alternatively, we'd change the calling convention even more and pass down a function that returns the list of "future history". And takes the completion table as argument, I suppose. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jun 2024 17:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 70996@debbugs.gnu.org, Spencer Baugh Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171838454411381 (code B ref 70996); Fri, 14 Jun 2024 17:03:01 +0000 Received: (at 70996) by debbugs.gnu.org; 14 Jun 2024 17:02:24 +0000 Received: from localhost ([127.0.0.1]:40850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIAJk-0002xT-Ea for submit@debbugs.gnu.org; Fri, 14 Jun 2024 13:02:24 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:52525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIAJf-0002xA-Ri for 70996@debbugs.gnu.org; Fri, 14 Jun 2024 13:02:23 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 41FA9E000A; Fri, 14 Jun 2024 17:02:10 +0000 (UTC) From: Juri Linkov In-Reply-To: (Dmitry Gutov's message of "Wed, 12 Jun 2024 16:52:21 +0300") Organization: LINKOV.NET References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Date: Fri, 14 Jun 2024 20:00:20 +0300 Message-ID: <86tthve9y3.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 (-) >> It seems to me that we can have the best of both worlds if we match the >> behavior of find-file, and use something like >> (run-hook-with-args-until-success 'file-name-at-point-functions) rather >> than (thing-at-point 'file-name). >> The default of file-name-at-point-functions is >> ffap-guess-file-name-at-point, which by default only returns a filename >> if that file name actually exists in the filesystem. >> The old behavior of (thing-at-point 'file-name) often got in the way, >> since it would pick up any random string at point, even if it wasn't >> referring to an actual file name. >> Instead we can be like find-file and have: >> (delq nil (list >> (run-hook-with-args-until-success 'file-name-at-point-functions) >> buffer-file-name)) > > That's an interesting suggestion, but could we rely on > file-name-at-point-functions acting correctly for any project? > > As luck would have it, ffap-guess-file-name-at-point seems to work fine on > relative file names inside a directory, and even file names without > extensions, but it could miss them in some odd directory structures. I tried file-name-at-point-functions with ffap-guess-file-name-at-point, but it fails to pick a file name when it's not relative neither to default-directory nor to the project root. It's easy to blame the design of such languages, but this won't solve the problem. So I see no way to reliable pick a file name. Therefore the need to fall back to (thing-at-point 'filename). >> I personally never use the file-name-at-point behavior of >> project-find-file, but I'm happy with it being higher-precedence because >> it will match find-file - as long as it also matches find-file in only >> including filenames of existing files. > > In case you agree with my concerns above (I'm happy to be convinced > otherwise), we could try to do something like > > (completion-try-completion (thing-at-point 'filename) > TABLE nil LEN) Unfortunately, this might get a false positive on a short word under point that with high likelihood will match a file name with a short substring. From unknown Mon Aug 18 11:21:29 2025 X-Loop: help-debbugs@gnu.org Subject: bug#70996: project-find-file defaults Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jun 2024 17:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70996 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Juri Linkov Cc: 70996@debbugs.gnu.org, Spencer Baugh Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.171838588413622 (code B ref 70996); Fri, 14 Jun 2024 17:25:01 +0000 Received: (at 70996) by debbugs.gnu.org; 14 Jun 2024 17:24:44 +0000 Received: from localhost ([127.0.0.1]:40869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIAfM-0003Xe-A2 for submit@debbugs.gnu.org; Fri, 14 Jun 2024 13:24:44 -0400 Received: from fout8-smtp.messagingengine.com ([103.168.172.151]:34893) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sIAfJ-0003XQ-SQ for 70996@debbugs.gnu.org; Fri, 14 Jun 2024 13:24:43 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id E3DE41380171; Fri, 14 Jun 2024 13:24:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 14 Jun 2024 13:24:35 -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:subject:subject:to:to; s=fm3; t=1718385875; x=1718472275; bh=YiYGQ5Kwsv3RAUx2rxlOrS/ShVnrgOQlHCbsjoMMOAI=; b= DdlpDecQcdMJgMTpucTTjypiqy65iwji2kTXw6hLMzNVAoxpKedBBrDT80ytJHcN fVvZDiIcW7cq9WFb4kSfQGMpNVTmVh0rYwmwyDUT7VC6tAurNWhXcKgeBUuYsHDt SQ/2ejH71KKY/rC/abNSyB8DpqG7/MqV4qmDZ9sTxqtyAPTWNoVWsI64IHkAB8R5 Nr8aseR3GtVuy3rmKows2rHPm74hTykDNG1EON1tKHwUBiLBhtjunSvMd6TKKKA1 b98uTzdFhkEg178ELWbnKm0mFIXqrUemXwswKB4MXpVO/Z42QP09qgYSuWrPqrYq ehEcYJcJ1s2OnQE0brtA9w== 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:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1718385875; x= 1718472275; bh=YiYGQ5Kwsv3RAUx2rxlOrS/ShVnrgOQlHCbsjoMMOAI=; b=P +ne1sbvwZ02civwBCdJ3I56O2ifg/PVyQqfE0cHydoD8apNi7NratTQUWfZCiVz3 yMXVJCjziQZb4uH319iask+Lwu42nUS/0cPUcsg93mBwHRaERr8+lZi7MO/F9W5O e5NbIAysgwP8a8c3yAANOibvhfixEFZSTrl76LuLsBJOc/Z/dfMpEOn8en8i7UIK K6ocHOt3zql9GWDl09DfnQtjIglyyyNLKEjb9rePKLQRr84AQszypp11tGzDHMeR 9TG8+9BAVoTiriJcuAmrL/Y01vXP6nqb09umsAON8yRA3FlbTXSrG/sV2pqAEOWB 0A0Iaii1Et81um39JKWlA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeduledgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Jun 2024 13:24:34 -0400 (EDT) Message-ID: <773b24ba-43c9-41e0-9f36-f404c07d0fcd@gutov.dev> Date: Fri, 14 Jun 2024 20:24:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> <86tthve9y3.fsf@mail.linkov.net> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <86tthve9y3.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 14/06/2024 20:00, Juri Linkov wrote: >>> I personally never use the file-name-at-point behavior of >>> project-find-file, but I'm happy with it being higher-precedence because >>> it will match find-file - as long as it also matches find-file in only >>> including filenames of existing files. >> In case you agree with my concerns above (I'm happy to be convinced >> otherwise), we could try to do something like >> >> (completion-try-completion (thing-at-point 'filename) >> TABLE nil LEN) > Unfortunately, this might get a false positive on a short word under point > that with high likelihood will match a file name with a short substring. It might. But we could set up the styles (or some other way to do the matching) so that it would only match full file name segments.