GNU bug report logs - #70996
project-find-file defaults

Previous Next

Full log

Message #31 received at 70996 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 70996 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#70996: project-find-file defaults
Date: Wed, 12 Jun 2024 16:52:21 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.