You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using an Emacs theme, there will inevitably be packages in my configuration which are not covered by the theme. To get a uniform look&feel, I will need to look up the colour definitions in the theme's source code, and then say things like
in my configuration. This is due to the fact, that most themes (nord-emacs being one of this class) simply let-bind a set of clolour symbols, which are then used in an ocean of backtick expressions making up the arguments of a custom-theme-set-faces call. While this is convenient for the theme author(s), it keeps the colour symbols' visibility constrained to the theme's code itself, and thus inaccessible for the user. As a consequence, users will need to have a peek into the engine room to borrow the colours' RGB values, and "adorn" their configuration with (IMHO) unnecessarily wordy, and (due to the use of raw RGB values) hard to read face specifications.
Needless to say that this applies to the vast majority of Emacs themes, and none of it is specific to nord-emacs.
Notwithstanding that fact, I have added to nord-emsacs a prototype implementation of a mechanism, which allows users to put things like this in their configuration:
Before spending the time converting it into a PR, I felt that testing the grounds up front might seem called for. The reason being that, beyond offering more end-user convenience, it would open the door to users overriding the theme's design choices (since I can of course specify for- and background of - for instance - the default face in the nord-user-faces list).
Dear maintainers, what's your take on this? A welcome addition, or having the dog guard the sausages?
The text was updated successfully, but these errors were encountered:
When using an Emacs theme, there will inevitably be packages in my configuration which are not covered by the theme. To get a uniform look&feel, I will need to look up the colour definitions in the theme's source code, and then say things like
in my configuration. This is due to the fact, that most themes (
nord-emacs
being one of this class) simplylet
-bind a set of clolour symbols, which are then used in an ocean of backtick expressions making up the arguments of acustom-theme-set-faces
call. While this is convenient for the theme author(s), it keeps the colour symbols' visibility constrained to the theme's code itself, and thus inaccessible for the user. As a consequence, users will need to have a peek into the engine room to borrow the colours' RGB values, and "adorn" their configuration with (IMHO) unnecessarily wordy, and (due to the use of raw RGB values) hard to read face specifications.Needless to say that this applies to the vast majority of Emacs themes, and none of it is specific to
nord-emacs
.Notwithstanding that fact, I have added to
nord-emsacs
a prototype implementation of a mechanism, which allows users to put things like this in their configuration:Before spending the time converting it into a PR, I felt that testing the grounds up front might seem called for. The reason being that, beyond offering more end-user convenience, it would open the door to users overriding the theme's design choices (since I can of course specify for- and background of - for instance - the
default
face in thenord-user-faces
list).Dear maintainers, what's your take on this? A welcome addition, or having the dog guard the sausages?
The text was updated successfully, but these errors were encountered: