[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add cl-defgeneric project-name; first use case eglot
From: |
Dmitry Gutov |
Subject: |
Re: Add cl-defgeneric project-name; first use case eglot |
Date: |
Wed, 23 Nov 2022 04:34:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 22/11/22 11:56, Kévin Le Gouguec wrote:
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:
I have just added (efe599df3127) a way to set the project name for VC
backend through dir-locals.
Not sure if this way will be to your liking, but it's the most
straightforward. Though I suppose we could also make this variable take
an alist value, associating root dirs with names.
(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.
You're welcome to experiment with project-prompt-project-dir's code. But
note that until now that function didn't require to "materialize"
project instances for every entry, it just works off saved directory names.
The feature you have in mind seems to require fetching a project
instance for every dir and calling 'project-name' on it. The apparent #1
gotcha would be with remote filesystems where connection is
slow/impossible, but it might be possible to skip those when computing
the names.
(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".
Cool. Hopefully the performance of 'project-current' won't make any of
these applications unfeasible (like the mode-line which has to refresh
after every change in any buffer, every keypress, etc).
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)
The general design is we leave it up to the project implementations how
to implement things internally. E.g. Projectile might already have its
own way to specify the name. So we don't have any global vars which
affect what all projects do.
- Add cl-defgeneric project-name; first use case eglot, Stephen Leake, 2022/11/20
- Re: [SPAM UNSURE] Add cl-defgeneric project-name; first use case eglot, Stephen Leake, 2022/11/20
- Re: [SPAM UNSURE] Add cl-defgeneric project-name; first use case eglot, Stephen Leake, 2022/11/20
- Re: Add cl-defgeneric project-name; first use case eglot, Eli Zaretskii, 2022/11/21
- Re: Add cl-defgeneric project-name; first use case eglot, Kévin Le Gouguec, 2022/11/22
- Re: Add cl-defgeneric project-name; first use case eglot, Kévin Le Gouguec, 2022/11/27
- Re: Add cl-defgeneric project-name; first use case eglot, Dmitry Gutov, 2022/11/27