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

Previous Next

Full log

Message #92 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: Tue, 14 Jun 2022 22:00:20 +0300

On 13.06.2022 15:13, Eli Zaretskii wrote:
> My "still don't think I understand" comment was about the need to
> support major-mode when apparently the_only_  user of that is
> fundamental-mode, where we cannot use derived-mode instead.

There are two uses of it inside project-kill-buffer-conditions.

One is

  (major-mode . fundamental-mode)

, and another is

  (and (derived-mode . special-mode)
         (not (major-mode . help-mode)))

I suppose in the latter it doesn't really matter whether the check uses 
'derived-mode-p', but the current way is more conservative.

Also see the turn-on-font-lock-if-desired example from the other email.

> If indeed
> fundamental-mode is the only case where major-mode is useful, I asked
> why not use a predicate that tests explicitly for that case.

If a predicate is a lambda, then it's not as readable.

> And if I understand your reasoning above, then doesn't
> 
>    (eq major-mode 'fundamental-mode)
> 
> provide an easy default that can be read at a glance?

Are you proposing adding a "keyword" 'eq' which would have a variable 
name as its first arg and the value as its second arg?

That would work (aside from the backward compatibility concerns). It 
might look confusing to a Lisp programmer, resembling "regular" code too 
much, creating false expectations.

Previous Next

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