GNU bug report logs - #54296
Add buffer-matching functionality

Previous Next

Full log

Message #113 received at 54296 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
Subject: Re: bug#54296: Add buffer-matching functionality
Date: Wed, 15 Jun 2022 14:54:14 +0300

On 15.06.2022 05:34, Eli Zaretskii wrote:
>> Date: Tue, 14 Jun 2022 22:46:49 +0300
>> Cc: 54296 <at> debbugs.gnu.org, philipk <at> posteo.net, larsi <at> gnus.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 14.06.2022 22:17, Eli Zaretskii wrote:
>>> No, I proposed to use the "predicate function" method (which already
>>> exists).
>>
>> Then the downside is "it's not readable". Or editable, really.
>>
>> At this point you could say that we need to support lambas anyway (ok),
>> and if people use them, we can use it for this purpose too.
>>
>> But it seems to me that, by not supporting lambdas so far, over the
>> couple of years since its introduction, project-kill-buffer-conditions
>> has kind of proven its minimal DSL to be viable.
>>
>> And if by having the 'major-mode eq' matcher we manage to avoid the use
>> of lambdas in 99%+ use cases, then that's a win for usability.
> 
> This is all a moot point, since eventually 'major-mode' was left in
> the code.  Any of the suggestions I had for removing it are therefore
> purely academic at this point, nothing to argue about.

'major-mode' that was left works like 'derived-mode' did.

If we take your suggestion as-is, though (and rename 'major-mode' back 
to 'derived-mode'), that would at least fix the main backward 
compatibility concern.

And with that, we could go back to discussing the stuff I wrote above.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.