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

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

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

(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?)

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

Point taken.

>> [… 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 🙇)

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