all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 70996@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#70996: project-find-file defaults
Date: Tue, 11 Jun 2024 20:11:28 -0400	[thread overview]
Message-ID: <ier4j9zow9b.fsf@janestreet.com> (raw)
In-Reply-To: <67beb5e6-8e74-4320-ba2f-7ceca2aae963@gutov.dev> (Dmitry Gutov's message of "Tue, 11 Jun 2024 03:02:01 +0300")

Dmitry Gutov <dmitry@gutov.dev> 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)





  parent reply	other threads:[~2024-06-12  0:11 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 [this message]
2024-06-12 13:52         ` Dmitry Gutov
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=ier4j9zow9b.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=70996@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=juri@linkov.net \
    /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.