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

Previous Next

Full log

View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54296 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#54296: Add buffer-matching functionality
Date: Fri, 11 Mar 2022 16:21:06 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: larsi <at> gnus.org,  54296 <at> debbugs.gnu.org
>> Date: Thu, 10 Mar 2022 12:13:59 +0000
>> 
>> > Do we really need both major-mode and derived-mode?
>> 
>> It seems to have been useful in project.el, see
>> `project-kill-buffer-conditions'.  In that case you want to both be able
>> to say something like "kill buffers only if they are in
>> fundamental-mode", but also something like "kill all buffers that are
>> based on comint-mode".
>
> So this is only because of fundamental-mode?

I wouldn't say so, that is a known use-case, that is one I know of right
now, but there is no reason something like that couldn't come up again?

> If so, shouldn't it be enough to have a possibility to have a
> predicate function, which can do anything one likes?

Everything this patch introduces could be replace by a predicate, but
the other issue is that if the major-mode/derived-mode distinction is
removed the function couldn't be used in project.el anymore, or would
have to break compatibility.

> I think we want in general avoid comparison with major-mode, and
> prefer derived-mode instead, and if so, IMO we had better did as we
> say and not exposed comparison to major mode unless we absolutely
> must.

Would it be enough to clarify this point in the documentation string?

-- 
	Philip Kaludercic

Previous Next

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