bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running

["João Távora" <joaotavora@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

> João Távora <joaotavora@gmail.com> writes:

> What existing hooks?

The major-mode hooks, naturally.

Using major-mode hooks and buffer-local variables is the standard Emacs
way of attaching characteristics to buffers.  The Elisp required is
trivial and there are thousands of examples for doing it out there.
There's no need to introduce new less powerful and more awkward
languages in variables.

>> It's quite clear that _some_ non-file-visiting buffers can be considered
>> as belonging to a project's working set.  But it's very very easy to
>> come up with many that cannot be considered so.
>
> I have to admit that I am more and more inclined to make the list a
> opt-in thing, where  we explicitly mark those major modes that are tied
> to a project.

Yes, and we can always later overhaul project-owned to be function for
doing more complex calculations based on the name of the buffer, for
example.  But a simple boolean would probably suffice for vc buffers,
and other earmuffed buffers created by packages in Emacs.

>> To name one.  The above is just the converse of the solution proposed by
>> Philip before.
>
> I would be fine with this in principle, my only worry is backwards
> compatibility for those who use project.el from ELPA.

We can try to make some backward compatible way, but this seems like the
perfect occasion to activate this most reasonable header in project.el:

    ;; NOTE: The project API is still experimental and can change in major,
    ;; backward-incompatible ways.  Everyone is encouraged to try it, and
    ;; report to us any problems or use cases we hadn't anticipated, by
    ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.

It sure seems like there were things that project.el's authors didn't
anticipate.  A mistake is a mistake there should be no shame in
rectifying it.

In practice, I doubt many people are setting these variables.  A GitHub
code search, where it is normally easy to find customizations of
variables since users version their configurations there, turns up 0
results for customizations of project-ignore-buffer-conditions and not
more than a handful for project-kill-buffer-conditions, for example.  In
contrast you can see hundreds of people setting things like
eglot-autoshutdown or ibuffer-filter-groups (and settings of
scroll-bar-mode are in the thousands).  So I'd say the risk is minimal
and the benefit considerable.

João