From: Dmitry Gutov <dmitry@gutov.dev>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 70996@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#70996: project-find-file defaults
Date: Wed, 12 Jun 2024 16:52:21 +0300 [thread overview]
Message-ID: <ea95360e-ffec-4065-8090-0bff6204ef88@gutov.dev> (raw)
In-Reply-To: <ier4j9zow9b.fsf@janestreet.com>
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.
next prev parent reply other threads:[~2024-06-12 13:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-17 6:36 bug#70996: project-find-file defaults Juri Linkov
2024-05-28 16:32 ` Juri Linkov
2024-06-08 0:28 ` Dmitry Gutov
2024-06-09 16:51 ` Juri Linkov
2024-06-11 0:02 ` Dmitry Gutov
2024-06-11 16:58 ` Juri Linkov
2024-06-11 20:04 ` Dmitry Gutov
2024-06-12 0:11 ` Spencer Baugh
2024-06-12 13:52 ` Dmitry Gutov [this message]
2024-06-12 20:04 ` Dmitry Gutov
2024-06-14 17:00 ` Juri Linkov
2024-06-14 17:24 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea95360e-ffec-4065-8090-0bff6204ef88@gutov.dev \
--to=dmitry@gutov.dev \
--cc=70996@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.