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

[Dmitry Gutov]

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
> implementation?
>
> 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
>    project).
>
>    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.