bug#71823: 31.0.50; project-mode-line and eglot duplicate project-name in mode-line

[Spencer Baugh <sbaugh@janestreet.com>]

Juri Linkov <juri@linkov.net> writes:
>> I do think this is a great way to resolve this - now that
>> project-mode-line exists, using it deletes one small bit of
>> eglot-specific functionality, which is in line with the Eglot design
>> philosophy.
>>
>> The only issue is that this was only added to mode-line-format in Emacs
>> 30, so we can only use it in Emacs 30 or later.
>>
>> The attached patch detects that with:
>>
>> +    (when (member '(project-mode-line project-mode-line-format) mode-line-format)
>>
>> but I'm also totally fine with:
>>
>> +    (when (version<= "30" emacs-version)
>>
>> Or I guess we could sidestep the issue if project.el itself ensured,
>> when loaded, that mode-line-format contains project-mode-line.  eglot
>> itself does this with eglot--mode-line-format, running the following at
>> load time:
>>
>>   (add-to-list 'mode-line-misc-info
>>              `(eglot--managed-mode (" [" eglot--mode-line-format "] ")))
>>
>> Juri, any opinion?
>
> bindings.el already contains '(project-mode-line project-mode-line-format),
> so checking this with (member '(project-mode-line project-mode-line-format)
> mode-line-format) looks fine.

Will do that in the next version of the patch.

> OTOH, I'm not sure if using (setq-local project-mode-line t)
> would be appreciated by users.  I think your initial patch
> was more correct with (bound-and-true-p project-mode-line).

I was also unsure, but after thinking about it, I think it's actually
quite reasonable, for this reason: anyone enabling eglot already had
project-name in their modeline.

This patch just moves the project-name from the [eglot] element to a
separate mode-line element.  So this doesn't actually change the
contents of an eglot user's mode-line, just the order of the elements.

Plus the separate element has the mouse-1 project menu, which is a nice
addition.