[Top][All Lists]

[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: Mon, 28 Nov 2022 03:21:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 27/11/22 20:47, Kévin Le Gouguec wrote:

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.

Thanks!  So to recap, IIUC now users have a couple of ways to control
how projects are named:

(1) Coding up their own project-name defmethod; AFAIU this is what
Stephen has in mind, when he talked about overriding the default

Not very familiar with generic functions yet, so currently going through
"(elisp) Generic Functions" to better understand the mechanics.

   Thoughts after experimenting for 5 minutes: my first instinct was to
   specialize methods by regex-matching on (project-root project), but
   that doesn't seem straightforward to do.  AFAICT the defmethod ARGS
   are not in scope when &context EXPR forms are evaluated?  So I can't
   use &context as an "escape hatch" to string-match-p on (project-root

   IIUC I could define my own "regex" specializer with
   cl-generic-generalizers?  No idea how judicious that is.

I suppose you could just write your own override form (copying either the default definition, or the specialized one -- e.g. for (head vc)), and if you make sure it's evaluated after project.el, you'll use the updated definition.

(2) Through the project-vc-name variable you introduced, using either
.dir-locals.el files or directory classes.

(Neither here nor there, but: I was surprised to see project-name go in
master "so soon"; OT1H I realize that some discussion had already
happened in bug#48747, OTOH I wouldn't have expected this feature to be
committed before the emacs-29 branch was cut, since that pretty much
"cements" the current design, to some extent?)

It's been a long-requested feature, and I haven't seen many comments or alternative suggestions. If you find problems, especially conceptual ones, please don't hesitate to report.

Also, for a :core package, using parallel branches for development is a pain.

[… KLG: lots of my vaporware elided …]

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

Hopefully 🤞  As an anecdata point, I've had project-current in my
frame-title-format for years, with no ill effects.

(<87h7vy9wrv.fsf@gmail.com> is the only time I remember experiencing any
kind of impact, and you dealt with it swiftly enough 🙇)

Nice! Good to hear that.

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.

(Noted; if anything, that's one more reason for me to get around to
learning generics)

Writing a new project backend might not be a best idea for everyone, though, especially if you only wanted to tweak one thing.

So if you don't find a comfortable enough way to customize project-name's logic, we can still plug in a var somewhere. E.g. either introduce a project-name-default-function, or allow project-vc-name to be set to a function as well.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]