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

[Stephen Leake]

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.

It might be useful to include the project name in the completion list
for project-prompt-project-dir, but with the default implementation
returning the abbreviated project root it would only duplicate
information already in the completion table.

Instead, we could have project-prompt-project-by-name, which would
complete on project names. The list of names could also be in
project-list file, with a change in format; also maintained by
project-remember-project.

The functions that ask the user to complete on projects would have to
choose which way to do that; there would have to be a
project-prompt-style defcustom for the user to set.

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.

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

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

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

> What do you think about the first option anyway?

I don't follow; what is "the first option"?

-- 
-- Stephe