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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4