On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <
dgutov@yandex.ru> wrote:
> I suggest you try it first.
It works in my test
> Disaster, really?
The reason I came about the Gnus problem was when using it
to reply to some emails here and trying out the C-x p k and finding out
all my Gnus buffers were gone.
> Do you know whether CIDER will be satisfied by the same patch I sent
> previously?
No. I don't use it. You should ask Manuel, who reported this in
the original discussion.
> >>> you're making a gun that only backfires 5% of the time.
> >> Yours is the first instance so far.
> > We seem to use different algebraic systems.
> This is literally the first bug report on the subject.
It's Philip's bug report. I don't use C-x p k, in fact I learned about it
here. It's then I started trying it, because in principle it is very useful,
that I found out how broken it is for many other situations: ibuffer, *gnus*,
and it's a shame we can't use it.
> what you are doing is pressuring all other participants into your POV by
> means of an insult. That usually works better if the offending code was
> written by somebody who already left (the project/the discussion/the
> company/etc), or is a little younger.
You are attributing ill-intent to me from a moral high-ground you can't really
claim. I had no idea as to the authorship, so I can't have been engaging in those
perfidious tactics. But do I apologize for the word "abomination". If it helps
I'll show you round to plenty such things written by myself in the past.
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.
> They can, though, even if odds are low. It can also happen through some
> other automation, which Emacs lets the users do freely.
That automation is just as buggy as C-x p k, and should be fixed, but
the only such automation we know is C-x p k.
> 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.
Not to mention it's just [insert acceptably derogatory word here] to protect
implementation details from misbehaving code that is under our control
and can just be fixed.