bug#70996: project-find-file defaults

[Juri Linkov <juri@linkov.net>]

>> 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.