bug#36837: 26.2; whitespace-mode: whitespace-line-column is not set to local fill-column

["Štěpán Němec" <stepnem@gmail.com>]

On Fri, 02 Aug 2019 17:14:34 -0400
Noam Postavsky wrote:

> (setq some-var some-value) in your init file as a global setting,
> (add-hook some-mode-hook (lambda () (setq some-var another-value)) as
> a mode-specific seting, and
> -*- some-var: yet-another-value -*- as a file-specific setting.
>
> So they go in that order: global may be overridden by mode-specific,
> which may be overriden by file-specific.

Yes, but OP's case is a bit more subtle, as I described in my very
first e-mail. Maybe a more visual representation will help. Here's
what happens (simplified) when visiting test.cfg during OP's recipe:

1. fill-column is at default value
2. `run-mode-hooks' is called
3. `conf-mode-hook' is run
4. `whitespace-mode' is called
5. `whitespace-color-on' is called, which sets up whitespace-font-lock-keywords,
    still with the default value of fill-column
6. `hack-local-variables' is called to parse and apply file-local settings
7. fill-column is set to 200

If what's really intended is that file-local settings prevail as much
as possible, this is a failure. That's why I'm wondering whether
reversing the order wouldn't actually work better, for reasons I
detailed in the reply to Andreas. As this case illustrates, libraries
often do all kinds of setup during load or mode activation, so unless
the relevant settings are applied before that, they don't really take
the desired effect.

Sure, if the order _was_ reversed and the mode hooks run _after_
`hack-local-variables', they could override file-local variable
settings, but I'm wondering how likely such conflicts really are or if
that's really a bad thing at all, given typical usage.

-- 
Štěpán