On Wed, Dec 04, 2024 at 11:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:

Once again, please show some simple Lisp to reproduce the phenomena you are observing. It is hard to discuss these highly technical issues on this abstract level.


Happy to. Sorry, I didn't think it was necessary given Eshel's providing of the recipe. It wasn't lisp though, so here's the lisp version from emacs -Q:

  1. (setq header-line-format "Some Header")
  2. (face-remap-set-base 'header-line 'highlight)
  3. (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10))
  4. (switch-to-buffer-other-window "new")
  5. From within new buffer/window: (set-face-attribute 'default nil :height (+ (face-attribute 'default :height) 10))
You'll see after step 3 the header line switches to the highlight face.
After step 5, the header line in the original buffer switches away from the highlight face, which is unexpected.

If you then switch back to the original buffer and change the font size again, the highlight will display again. Switching back to the new buffer and changing the font size causes it to disappear again, so I was mistaken about it only happening once. It just so happens that a full redisplay only triggers once for me in my normal usage when I have a window without the header line override specified.

On the very basic level of the display code, when a display iterator is initialized, the window for whose display the iterator is used must be given to init_iterator as its argument, and the buffer of that window must be temporarily made to be the current buffer. So this cannot be the problem in this case. If init_iterator would be passed an incorrect window, we'd have much more grave display problems than this minor issue.


Understood, but that's not what I was attempting to describe. I was trying to say that the window passed to init_interator IS the correct window. And that that is used to resolve the remap for the inactive/active faces. However, it does not appear that that same window is used to resolve remapping of faces that are inherited by the inactive/active faces.

From what I can tell, this only applies to header-line-active and header-line-inactive (and their mode line equivalents) and it does not apply to other faces in the header line that may inherit from remapped faces, so that's good.

Also, I understand what you're saying that remapping mode-line was decided in Emacs 29 to not be supported and the conclusion may be the same for header-line. If that's what it needs to be, that's fine. As Eshel said, it will be a breaking change because people have relied on this behavior.

Thanks,