bug#41852: 27.0.50; text-scale commands don't scale header of tabulated-list-mode

[martin rudalics <rudalics@gmx.at>]

 >> I'd say "will also scale the text in the mode line when displaying that
 >> buffer".
 >
 > It doesn't scale the text in the mode line, though.

Silly me.  I obviously meant "header line" here.

 >> But if I assign the header line face or some face inheriting from it to
 >> some buffer text (not that I recommend doing that), that text will be
 >> scaled regardless of the value of 'text-scale-remap-header-line-face'.
 >> Right?
 >
 > Yes.  But that seems (in my testing) to be the case for any face I
 > tested that doesn't have an absolute value for :height.  So I'm not sure
 > that it needs to be specifically mentioned in NEWS.

By no means.  I just mentioned it to illustrate how elusive the text
scaling mechanism is.

 >> Here too I would say something like "the buffer text is scaled".  The
 >> default face itself is not scaled by face remapping.  The remapping is
 >> applied by the display engine whenever the buffer is displayed after all
 >> faces have been merged.  But maybe that is clear to everyone and you
 >> should simply ignore what I wrote.
 >
 > I'm not sure it is clear to everyone (it cleared some stuff up for me),
 > but I worry that this might be too detailed for NEWS.  The interesting
 > bits is probably not exactly how it works, but rather what its visible
 > effects are.

Fully agreed.  That's why in NEWS I'd try to talk only about those
visual effects and skip any details of the underlying implementation
like faces, fonts and their scaling.

 >> We might have a problem when these two are set in separate steps.
 >
 > Yes, if the variable is set after scaling, it does not take effect until
 > another scaling operation is done.
 >
 > Adding this seems to fix that:
 >
 > (add-variable-watcher 'text-scale-remap-header-line-face
 > 		      #'text-scale--refresh)
 >
 > (defun text-scale--refresh (symbol newval operation where)
 >    (when (and (eq symbol 'text-scale-remap-header-line-face)
 >               (eq operation 'set)
 >               text-scale-mode)
 >      (with-current-buffer where
 >        (let ((text-scale-remap-header-line-face newval))
 > 	(text-scale-mode 1)))))

Something like that.  Here I have a comment in my private version of
face-remap.el that says

       ;; ... face-remapping first pushes an
       ;; entry to `face-remapping-alist' and then sets its cdr to the
       ;; modified value so our variable watcher won't catch the modified
       ;; value.  Such destructive operations are a general problem with
       ;; watching non-scalar variables.

but I can't tell whether it's directly related.

martin