From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#70996: project-find-file defaults Date: Tue, 11 Jun 2024 20:11:28 -0400 Message-ID: References: <867cft2ggx.fsf@mail.linkov.net> <86cyoqjdcq.fsf@mail.linkov.net> <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29732"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 70996@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 12 02:12:34 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sHBbN-0007VC-E3 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Jun 2024 02:12:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHBav-0003OG-Q8; Tue, 11 Jun 2024 20:12:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHBau-0003O1-8a for bug-gnu-emacs@gnu.org; Tue, 11 Jun 2024 20:12:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sHBat-0000sm-IE for bug-gnu-emacs@gnu.org; Tue, 11 Jun 2024 20:12:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sHBar-0000fP-R5 for bug-gnu-emacs@gnu.org; Tue, 11 Jun 2024 20:12:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 70996-submit@debbugs.gnu.org id=B70996.17181510952524 (code B ref 70996); Wed, 12 Jun 2024 00:12:01 +0000 Original-Received: (at 70996) by debbugs.gnu.org; 12 Jun 2024 00:11:35 +0000 Original-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 Original-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 In-Reply-To: <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> (Dmitry Gutov's message of "Tue, 11 Jun 2024 03:02:01 +0300") 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287130 Archived-At: 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)