bug#48747: [SPAM UNSURE] Re: bug#48747: add project-name generic

[Dmitry Gutov <dgutov@yandex.ru>]

On 21/11/22 20:59, Stephen Leake wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 21.11.2022 00:17, Stephen Leake wrote:
>>
>> But let's please go back to my question: could we use the new generic
>> in project-prompt-project-dir? And should we?
> 
> project-prompt-project-dir used to chose a project, by choosing a root
> directory (in project-current, project-forget-project, and
> project-switch-project). (that's not guarranteed to be a one-to-one
> mapping, but that's a separate issue). It currently completes on a list
> of file names.
> 
> Those file names come from project-list-file which relies on users or
> clients calling project-remember-project.

I guess what you might be saying is that the file contains directories 
and not project instances. Thus, going to the project name is a 
non-trivial transition anyway. And for the whole list, potentially costly.

> I think a better design would be for the default project-name to return
> nil; then project-prompt-project-dir could use names if they are
> non-nil, falling back to abbreviated file names if the project name is
> nil. That would allow a mix of named and un-named projects. Eglot could
> do the same. project-list-file should store the project name.

That's a problem: if the default is nil, then for every project the user 
will have to customize it somehow. Otherwise the method is not going to 
be usable. That's not a great workflow from my POV.

If the place where you want to use it in Eglot, currently calls

   (file-name-base (directory-file-name root))

then that is probably the best default after all.

> In that case, project-prompt-project-dir could be renamed to
> project-prompt-project.
> 
>> If we do, we'll have to default the return value to
>>
>>    (abbreviate-file-name (project-root pr))
>>
>> rather than your suggested
>>
>>    (file-name-base (directory-file-name (project-root pr)))
> 
> That's a reasonable choice; it does not work for the eglot use case.
> Which argues for the default to be nil.
> 
> I'm not clear why you want this to be the default;
> project-prompt-project-dir does not currently use abbreviate-file-name
> (perhaps it should?).

Abbreviate or not is a minor detail. Not too important for 
project-prompt-project-dir, but could be more valuable in other 
potential places, such as mode-line, which value compactness.

>> Would you say you intend to override project-name a lot?
> 
> I'm not sure what counts as "a lot" here. All wisi projects have a name
> provided by the user, and almost all projects I use are wisi projects.
> So yes? On the other hand, I don't have plans to write any new projects
> that need names. So no?
> 
>> Or do you want to take advantage of the shorter default name in most
>> cases?
> 
> Deriving the project name from the root directory of the project is not
> useful in my use cases. Abbreviating does not make it more useful; the
> only useful label is the string provided by the user. And I
> have situations where the root directory is the same for two projects;
> for example, ada_language_server has main and test projects.
> 
> So wisi will continue to store a user provided string in a project
> object slot; it will override project-name to return that slot.

That answers my questions, thanks.

> Transient projects could also store a name as a plist entry in the
> project object: '(transient /a/root/dir :name "wisitoken main")

Yes, but, for a transient object, there's nowhere to get the custom name 
from. The user just chooses a directory.

Anyway, I think we can proceed with your original proposal (where the 
default name is the base name of the root directory). Some users of 
project-vc backend will probably want to customize it too, we can add a 
buffer-local variable for that (now or later).