bug#44232: global-display-fill-column-indicator-mode vs. readonly buffers

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>>> That's basically the same as highlight-changes-global-modes, but with
>>> the added
>>>
>>>          ;; ...the buffer is not internal (name starts with a space)
>>>          (not (eq (aref (buffer-name) 0) ?\ ))
>>>          ;; ...the buffer is not special (name starts with *)
>>>          (or (not (eq (aref (buffer-name) 0) ?*))
>>>
>>> So that's kinda kludgy.
>>
>> It's not quite the same thing, because whitespace-enable-predicate only
>> takes on function values, and is explicitly intended to be customised
>> with the existing DSL of add-function, rather than a new ad-hoc DSL.
>
> I'm not quite sure I follow.  The bit before the thing I quoted was
> pretty much the equivalent of highlight-changes-global-modes:
>
>           ((listp whitespace-global-modes)
>            (if (eq (car-safe whitespace-global-modes) 'not)
>                (not (memq major-mode (cdr whitespace-global-modes)))
>              (memq major-mode whitespace-global-modes)))

Oops, I missed whitespace-global-modes.  Yes, that seems to be the same
thing as highlight-changes-global-modes.

>> [Not that I'd argue for the superiority of whitespace-enable-predicate
>> over other customisation approaches.]
>
> So I'd say whitespace-enable-predicate has the same ad-hoc DSL built in,
> but with an add-function DSL on top of it?

Yep.  Maximal customisability. ;)

-- 
Basil