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

[Dmitry Gutov <dgutov@yandex.ru>]

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.