GNU bug report logs -
#58839
29.0.50; project-kill-buffer fails when Eglot is running
Previous Next
Full log
Message #203 received at 58839 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
>> I've explained to Philip objective reasons why I think evaluated
>> mini-languages are almost always inferior to a decent Lisp such as Elisp.
>> You could perfectly reasonably deprecate these two variables.
> Not where this discussion is going, is it?
Not sure. This started has a report of hidden buffer being incorrectly
killed by project.el. After much insistence, you've agreed to plug the
hole in that library. During tests I also discovered that project.el is
killing other buffers nonsensically, like Gnus buffers, *ibuffer*, and
many other global. It was actually easier to find false-positives of
your heuristic than true ones. Again, after some insistence, you seem
to have come around that these things represent bugs.
Three people here have suggested an opt-in approach for the true
positives. Now your strategy seems to be "OK: let all these false
positives remain nonsensically associated with a project in
project-buffers but let's have global databases of exceptions for
specific operations, using a (largely redundant) mini-language for
buffer-matching".
If that doesn't sound like a bad idea in the face of much better other
ideas, I don't know what else to tell you.
>> > I'm fairly sure that the solution I offered would be easy enough
>> > implement, to actually protect the vulnerable buffer.
>> > I suppose we are not doing that, however.
>> You sketched an untested code-less idea and I explained how flawed
>> it was.
>
> Back atcha. Modulo "code-less".
Not only did I provide code, I also verified that it works. Anyone can
see my messages to verify that.
João
This bug report was last modified 2 years and 280 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.