outli doesn't update headline faces on theme change

[Luis-Henriquez-Perez]

Here I have the theme doom-xcode

Now I change the theme to modus-operandi. And as you can see the faces of the comment headlines haven't changed with the theme.

Here is what it should look like:

I've been dealing with this problem so far just by toggling outli-mode after changing themes.

With little knowledge of faces, the obvious solution is just adding an advice to load-theme to unfontify outli headings before switching a theme and refontify them after switching a theme. But I wonder why a related package, outshine, doesn't have this problem. Its heading faces change color automatically.

[jdtsmith]

As your example shows, it's only the leading comment block face that doesn't update. This is computed by outli based on the background color. If you prefer less styling (like outshine) configure outli-blend to disable this. Alternatively, simply add advice to load-theme, which unfortunately provides no standard hook to do this.

[Luis-Henriquez-Perez]

Ok. I like the leading comment block face so I prefer the advice solution. Is this what the advice would look like?

(defun fontify-outli-headlines (orig-fn &rest args)
  (dolist (buffer (buffer-list))
    (with-current-buffer buffer
      (when outli-mode
        (outli-unfontify))))
  (apply orig-fn args)
  (dolist (buffer (buffer-list))
    (with-current-buffer buffer
      (when outli-mode
        (outli-fontify-headlines)))))

I do notice that applying (outli-unfontify) and (outli-fontify-headings) on the buffer is not quite right.

This is after using eval-expression on outli-unfontify and then outli-fontify-headlines. There is a cool-looking face that shows the level of the headline on the comments. I think this is the style? Not sure.

Probably that outli-fontify-headlines is called with one of its arguments being non-nil when outli-mode is invoked.

[Luis-Henriquez-Perez]

There is a cool-looking face that shows the level of the headline on the comments. I think this is the style? Not sure. Probably that outli-fontify-headlines is called with one of its arguments being non-nil when outli-mode is invoked.

Ah O.K. this is the style. I checked which arguments were passed into outli-fontify-headlines when I toggled outli-mode and they were t and nil.

(defun oo-print-fn-and-args (orig-fn arg1 arg2)
  (message "(outli-fontify-headlines %S %S)" arg1 arg2)
  (funcall orig-fn arg1 arg2))

(advice-add #'outli-fontify-headlines :around #'oo-print-fn-and-args)

So I passed in a different argument for style (nil instead of t) when I invoked outli-fontify-headlines with no arguments.

In the docstring of outli-fontify-headlines:

If STYLE is non-nil, do not style the stem and depth chars
differently. 

Since I like the depth and the stem characters to be styled differently, I'll set this for at least emacs-lisp-mode.

(setf (cl-fourth (assoc 'emacs-lisp-mode outli-heading-config)) nil)

And then I also need the advice I mentioned previously to use the arguments for outli-fontify-headlines specified by outli-heading-config.

[Luis-Henriquez-Perez]

O.K. I refined the advice to this:

(defun @fontify-outli-headlines (orig-fn &rest args)
  (let (outli-buffers)
    (dolist (buffer (buffer-list))
      (with-current-buffer buffer
        (when outli-mode
          (outli-mode -1)
          (push buffer outli-buffers))))
    (unwind-protect (apply orig-fn args)
      (dolist (buffer outli-buffers)
        (with-current-buffer buffer
          (outli-mode 1))))))

(advice-add 'load-theme :around #'@fontify-outli-headlines)

This advice worked for me. At first I thought that it's better to be more specific by using the fontify functions, but then I'd need to read the outli-heading-config and essentually duplicate the code in outli-mode. I didn't want to do that.

If one wants to be more precise, they can check if the specific outli buffer actually has style enabled and only then toggle the mode. Probabl not worth it though.

In my opinion, this advice should either be in outli as a user option OR the fact that this face is not updated on loading a theme by default should be mentioned in the README (as long with code for the solution), maybe in GOOD-TO-KNOW / GOTCHA section or maybe your existing TIPS section because as a user I found this suprising.

[jdtsmith]

OK I have pushed some updates to make all this easier. Instead of hard-coding the colors into the font-lock matching keywords, such that they have to be recreated in all open buffers, I now create and use custom faces (outli-{stem,repeat}[-mode]-N) and simply update those. Any newly opened buffer will update the faces to match the current theme, so that's one approach. You can update all the faces in one go with the new command outli-reset-all-faces, which could be added as a trivial :after advice to load-theme. Please give main a test and let me know how this works for you.

[Luis-Henriquez-Perez]

j> You can update all the faces in one go with the new command outli-reset-all-faces, which could be added as a trivial :after advice to load-theme

Please give main a test and let me know how this works for you.

Cool. I called the new command outli-reset-all-faces interactively and it worked. Also I added this advice to my configuration and tested it, also works.

(advice-add 'load-theme :after (lambda (&rest _) (outli-reset-all-faces)))

If you haven't already I would recommend adding this to the tips section or maybe the "configuration" section of the README would be better.

I am ready to close the issue if nothing else is left to be said.

[jdtsmith]

I've made it possible to add outli-reset-all-faces directly as :after advice and updated the README to suggest. Let me know of any issues.

[jdtsmith]

I recently learned about enable-theme-functions, and am now automatically resetting all faces using this hook. Can you please remove your load-theme advice and try this new version (assuming you are on Emacs 29.1 or later)?