unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>,
	"Eli Zaretskii" <eliz@gnu.org>
Cc: Stephen Leake <stephen_leake@stephe-leake.org>,
	emacs-devel@gnu.org, joaotavora@gmail.com
Subject: Re: Add cl-defgeneric project-name; first use case eglot
Date: Wed, 23 Nov 2022 04:34:19 +0200	[thread overview]
Message-ID: <0d0c80fa-7db1-be68-0dba-a9dd466d34d5@yandex.ru> (raw)
In-Reply-To: <87h6yrxqga.fsf@gmail.com>

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.



  reply	other threads:[~2022-11-23  2:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-20 22:09 Add cl-defgeneric project-name; first use case eglot Stephen Leake
2022-11-20 22:14 ` [SPAM UNSURE] " Stephen Leake
2022-11-21  0:37 ` Stephen Leake
2022-11-21 13:07 ` Eli Zaretskii
2022-11-21 13:50   ` João Távora
2022-11-21 14:17     ` Eli Zaretskii
2022-11-21 21:29       ` João Távora
2022-11-22  9:56   ` Kévin Le Gouguec
2022-11-23  2:34     ` Dmitry Gutov [this message]
2022-11-23  8:33       ` Juri Linkov
2022-11-23 13:46         ` Dmitry Gutov
2022-11-27 18:47       ` Kévin Le Gouguec
2022-11-28  1:21         ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d0c80fa-7db1-be68-0dba-a9dd466d34d5@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=kevin.legouguec@gmail.com \
    --cc=stephen_leake@stephe-leake.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).