Re: Add cl-defgeneric project-name; first use case eglot

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: João Távora <joaotavora@gmail.com>
>> Date: Sun, 20 Nov 2022 14:09:49 -0800

[...]

>> So I'd like to add a new cl-defgeneric to project.el:
>> 
>> (cl-defgeneric project-name (project)
>>   "A human-readable name for the project."
>>   (file-name-base (directory-file-name (project-root project))))
>> 
>> Then I can override that in my projects, and eglot will use my desired
>> name.
>
> I don't see why the needs of Eglot usage justify another generic in
> project.el, or should be solved in project.el to begin with.  If Dmitry
> wants to add such a generic for his own reasons, with some future
> development of project.el in mind, I won't object, of course.

FWIW, being able to tell project.el "this project is named foobar,
nevermind the path" would help me in a couple of situations:

(1) C-x p p emacs TAB is currently rather crowded, because I stuff a lot
of things under ~/src/emacs: emacs.git worktrees, elpa.git, upstream
repos for *ELPA packages…

If I could "name" projects such that only emacs.git worktrees included
the string "emacs" (rather than all repos under ~/src/emacs), that'd
make completion more efficient.

(2) I'd like to be able to give nicknames to projects.  I could make
project-prompt-project-dir use the flex style to match e.g. "fts" to
"foo-testsuite", but I can think of other nicknames that wouldn't match
(e.g. "xfoo" for "cross-foo").

(3) I'd like to stick (project-name) in my frame-title-format; currently
using "(file-name-base (directory-file-name (project-root
(project-current))))", but my lack of creativity in worktree naming is
biting me in the rear ("ah yes, the “master” project 😐").

Granted, I would still need to come up with my own logic for more
informative project names, but at least I could keep it separate from my
frame-title-format logic.  E.g. if I had different project-naming
conventions for $HOBBIES and $DAYJOB, I could keep frame-title-format in
sync everywhere, but give different machines different project-naming
code.

Granted², I can already define my own indirection layer today; I don't
need to wait for project-name to be introduced.

(4) Similar itch with Magit buffer names:

(info "(magit) Naming Buffers")
https://magit.vc/manual/magit.html#Naming-Buffers

Being able to stick a (project-name) in there (or a "%p") would be
convenient, for the same reasons as frame-title-format: use the same
Magit buffer-name config everywhere; keep project-naming logic
"workplace-bound".


ISTM those look like "use-cases" for teaching project.el about "project
names" untangled from project root paths.  I'd make use of that feature,
regardless of what Eglot does.

(Can't say whether a defgeneric is the most suited technical answer;
FWIW I'd expect my project-naming code to look at various things,
e.g. the project path, the repo's upstream URL, the current branch.  Not
sure it matters much to me whether we use a defgeneric or a
project-name-function, but then I'm not very familiar with generics)

>                                                                Otherwise, it
> sounds like the wrong way of solving specific problems: by generalizing the
> heck out of them.  E.g., tomorrow we decide that Eglot shouldn't use the
> project name on the mode line, and puff! your solution evaporates.