bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails whe


From: João Távora
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Date: Sat, 29 Oct 2022 12:05:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Philip Kaludercic <philipk@posteo.net> writes:

> This is my perspective too.  I am under the impression that João or
> looking at this from a too technical perspective, and is missing the way
> users perceive the situation.

You're not reading what I am writing.  Here's a summary again:

1. buffer is implementation detail.  Users don't see it any more than
   they see values of internal global variables.  In fact I think
   lsp-mode, perfectly legitimately, uses (or used to use) a process,
   but doesn't make use of its buffer at all.  It uses a special filter
   that processes and stores strings in global variables.  These
   variables also "service a project" and occupy resources but I doubt
   project.el has a claim to their ownership.  jsonrpc.el use buffers
   internally, just because that was deemed more convenient and
   efficient for parsing.

2. Users like you who are interested in controlling the RAM and CPU
   resources taken by the running a LSP server, even when Emacs is not
   visiting any files in a project should use the variable
   eglot-autoshutdown.  This variable is exactly what you want.  There
   is no other "user perception" here that I have been made aware of.

3. Even if we were to neglect point 1, as you seem to be, fixing things
   with kill-buffer-query-functions duplicates programming logic, which
   is very bad.  And most important of all, there's no place to put the
   reference to kill-buffer-query-functions short of many lines
   completely throwing away encapsulation and unique resource ownership.

If this is too technical, then I'm sorry: this is a technical mailing
list.

João








reply via email to

[Prev in Thread] Current Thread [Next in Thread]