centaur-tabs
centaur-tabs copied to clipboard
Switching themes creates 'artifacts' on tabs
When switching themes, it seems more common between light to dark and vice versa, the look on the tabs gets distorted as shown in the pictures below:
(the images are different instances. First one started with light theme, second one started with dark theme)
-
Light to Dark
-
Dark to Light
Could you share your setup and which themes you're using? Can't reproduce.
I should clarify that this happens when switching theme in the same emacs session, without restarting it after the switch.
This first happened when trying out a package called heaven and hell, which lets you define two themes from which one can toggle one or the other via a defined hotkey. Currently I have set kaolin-light and kaolin-temple (from kaoling-themes). I've tried with doom-themes and spacemacs-theme as well, with similar results.
The same happens if I change the theme using M-x load-theme
or M-x consult-theme
. Tested with the above package turned on and off.
I separate my init into several files for organizing, that are then require
d in init.el; but I don't think that would affect.
This is my config for centaur-tabs:
(use-package centaur-tabs
:config
(centaur-tabs-mode t)
(centaur-tabs-headline-match)
:custom
(centaur-tabs-style "box")
(centaur-tabs-height 32)
(centaur-tabs-set-icons t)
(centaur-tabs-plain-icons t)
(centaur-tabs-set-bar 'under)
(x-underline-at-descent-line t)
(centaur-tabs-set-modified-marker t)
(centaur-tabs-modified-marker "~")
(centaur-tabs-close-button "×")
:hook
(dired-mode . centaur-tabs-local-mode)
(dashboard-mode . centaur-tabs-local-mode)
(helpful-mode . centaur-tabs-local-mode)
:bind
("C-<prior>" . centaur-tabs-backward)
("C-<next>" . centaur-tabs-forward))
and for my themes:
(use-package spacemacs-theme
:custom
(spacemacs-theme-comment-bg nil)
(spacemacs-theme-comment-italic t))
(use-package doom-themes
:config
(doom-themes-visual-bell-config)
(setq doom-themes-enable-bold t
doom-themes-enable-italic t))
(use-package kaolin-themes)
(use-package heaven-and-hell
:init
(setq heaven-and-hell-theme-type 'dark)
(setq heaven-and-hell-load-theme-no-confirm t)
(setq heaven-and-hell-themes '((light . kaolin-light)
(dark . kaolin-temple)))
:hook (after-init . heaven-and-hell-init-hook)
:bind (("C-c <f6>" . heaven-and-hell-load-default-theme)
("<f6>" . heaven-and-hell-toggle-theme)))
@r-katabasis Before loading a new theme, are you running M-x disable-theme
to disable the previously loaded one?
It’s good practice to only keep one theme loaded at a time. Loading multiple themes on top of each other causes unpredictable behaviour, especially in the margins and modeline in my experience.
Edit: After looking at the source of heaven and hell, it seems that it does disable all old themes before loading new ones.
The real issue seems to be that all-the-icons
renders the background as well in a PNG image. Any operation that causes centaur-tabs to redisplay seems to fix the issue (try switching/killing tabs or opening a new tab within the same group), since all-the-icons must redraw the PNGs.
Perhaps you should hook into load-theme centaur-tabs’ redisplay alias.
I am aware that load-theme doesn’t have a hook, so we can define one like:
;; Create `after-load-theme-hook'.
;; TODO submit this upstream?
(defvar after-load-theme-hook nil
"Hook run after a color theme is loaded using `load-theme'.")
(defadvice load-theme (after run-after-load-theme-hook activate)
"Run `after-load-theme-hook'."
(run-hooks 'after-load-theme-hook))
The real issue seems to be that
all-the-icons
renders the background as well in a PNG image. Any operation that causes centaur-tabs to redisplay seems to fix the issue (try switching/killing tabs or opening a new tab within the same group), since all-the-icons must redraw the PNGs.
Switching tabs does indeed update the icon,
After switching a tab
however there remains some 'artifacts' between the tabs even when deleting and creating new tabs
For reference, here is how it should look (which now I see I should have posted earlier, my bad)
Something to note is that if I switch the theme in Dashboard, which is hooked to centaur-tabs-local-mode
thus tabs is disabled. This only works the first time emacs is launched. After the switch if I open a file, then go back to dashboard and switch again, the same 'artifacts' appear.
Perhaps you should hook into load-theme centaur-tabs’ redisplay alias.
I am aware that load-theme doesn’t have a hook, so we can define one like:
;; Create `after-load-theme-hook'. ;; TODO submit this upstream? (defvar after-load-theme-hook nil "Hook run after a color theme is loaded using `load-theme'.") (defadvice load-theme (after run-after-load-theme-hook activate) "Run `after-load-theme-hook'." (run-hooks 'after-load-theme-hook))
I'll have a try at this, and come with the result at a later time.
Thanks the support @nebhrajani-a
Edit: There was no noticeable change when setting up the load-theme hook and the redisplay alias. It looked the same as with img. 2
Edit 2:
I just notice that when setting centaur-tabs-style
to "bar", only the icon are not displayed properly.
The last remaining artifacts seem to be from centaur-tabs-style
. If you are okay with using bar
, there is only one thing remaining to add to the load-theme
hook: centaur-tabs-headline-match
, which will fix the background color of the tab-line.
That is, after-load-theme-hook
should have, hooked into it, (centaur-tabs-display-update)
and centaur-tabs-headline-match
.
Meanwhile, I will look into the artifacts created by the other styles: I think there should be a way to recompute and reapply those. They're cached, and I wasn't able to figure out a way to reset it, so perhaps @ema2159 can help us here?
Sure. Indeed there are several things that have to be done after loading a theme to remove the artifacts. For reference, this is what I do when I load a new theme: https://github.com/ema2159/emmacs_config/blob/25b3bc503cbadf6426cccddc356bb37b6d4aa047/core/2_emmacs_ui.el#L411
If I am not wrong, it is similar to the solutions you've discussed in this thread.
The last remaining artifacts are indeed generated by the other styles, it is a bug and I suspect it has something to do with the memoization of the separators. This is an issue that must be investigated and fixed.
While the subject of themes is being discussed, I want to raise an issue that I think is neglected almost everywhere. The great majority of themes posted for Emacs are dark themes, but in my experience, almost everyone I know strongly prefers paper white backgrounds. The default themes of all editors and IDEs that I've used, have paper-white backgrounds. Similarly, almost all popular apps that involve reading and/or writing, employ paper-white backgrounds, including word processors, other office apps, email clients, note taking apps, etc., etc., etc. The only apps that don't, are niche apps that appeal mostly to tinkerers, like Emacs, terminal emulators, Linux desktop themes, etc.
It's my own observation, that the only people I personally know who can even tolerate dark themes, are on the autism spectrum. This is consistent with the general phenomenon that autistic people have very different responses to sensory experiences than non-autistics. By the way, that's in no way intended as a put down, as I myself am probably on the spectrum, as is my brother to a greater degree, along with many other people I respect and like. For instance, one of my autistic friends finds the feeling of synthetic fabrics "extremely itchy," is very distracted and annoyed by sounds that most people don't notice, and ... finds white backgrounds "hurt his eyes."
I think it's generally accepted that a high proportion of programmers are on the autism spectrum. This probably goes double for people who like Emacs, terminal apps, and similar. Nevertheless, I still think the majority of Emacs users are not autistic and would prefer the paper-white themes that most people prefer.
I think we need to recognize that there are at least two diametrically opposite preferences for color schemes, and the dark themes are probably grossly over-represented in online repositories. My theory is that this is because the rare people who like dark themes, are much more likely to be detail oriented tweakers, and hence willing to author color themes. God bless them. I'm glad they are using their talents to make the world a more interesting place. I just wish I were one of the very rare people who can use dark themes, but I'm not.
It's unfortunate that all of the screenshots and all of the themes recommended for centaur-tabs have dark backgrounds. So dark in fact, that I can't make out the details. For instance, I can't make out the tab shapes in the screenshots for tab-styles, nor could anyone else I showed these screenshots to.
I think this is unfortunate, because it's also my experience that autistic people are less interested in user interface features like tabs than non-autistics. So, I suspect that by only showing dark themes, you are probably putting off almost everyone who would be interested in centaur-tabs from wanting to use it.
I have no objection to making a large selection of dark themes available for autistic users, or whoever else might like them, but it would be wise to also make sure that a decent selection of paper-white themes is available, and feature them in the documentation.
@Addlai while I'm not sure about the theme preference variance between autistic and non-autistic users, I feel that you raise an excellent point: our README screenshots and recommendations are biased towards dark themes. I'll work on testing some light themes with Centaur (most Doom light themes are excellent, in case you're looking for any) and add them to the README.
@Addlai while I'm not sure about the theme preference variance between autistic and non-autistic users,
Perhaps I'm wrong about the reason, but the question fascinates me and I do think the preference can be strong in either direction. I very much appreciate keeping us light-themers in mind.
By the way, centaur-tabs is a very cool package that improves the Emacs experience a lot!