On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov 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.