[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54296: Add buffer-matching functionality
From: |
Dmitry Gutov |
Subject: |
bug#54296: Add buffer-matching functionality |
Date: |
Tue, 14 Jun 2022 22:00:20 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 |
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.
bug#54296: Add buffer-matching functionality, Eli Zaretskii, 2022/06/13
- bug#54296: Add buffer-matching functionality,
Dmitry Gutov <=