Fix non-graphical color switch #24
Conversation
`(display-graphic-p)` will evaluate to nil when starting Emacs in daemon mode. Instead, we now use the attribute switch system provided by custom.el, which apply definitions when a frame is created and will do the right thing when running Emacs daemon. Fixes dracula#23
|
|
| @@ -56,7 +55,8 @@ | |||
| 'dracula | |||
| ;; default | |||
| `(cursor ((,class (:background ,fg3)))) | |||
| `(default ((,class (:background ,bg1 :foreground ,fg1)))) | |||
| `(default ((((type nil)) (:background "#000000" :foreground ,fg1)) | |||
There was a problem hiding this comment.
I like the approach of using type nil but documentation around default is kind of vague. Will having multiple defaults like this mean that if type is nil, then only the background of #000000 will be set, otherwise we'll use the standard bg1 (aka.. if/else)? Or will this apply both but type nil has a different default? I'm just trying to understand how this code is evaluated.
There was a problem hiding this comment.
From my test runs, it’s a short-cut semantics; first match wins. So from my tests, the evaluation goes:
Frame shown on terminal
- tries matching
type nilagainst typetype nil(the value representing terminal frames) - succeeds
- applies settings
- next condition (
,class…) is not checked
Frame shown on non-terminal
- tries matching
type nilagainsttype x,type w32, etc. - fails
- next condition is checked and applied
I tested this by setting only the background in the first condition, and only the foreground in the second condition, and I only ever got one of the two applied.
There was a problem hiding this comment.
Sorry, had to edit. The correct term would be short-cut semantics, not fall-through, which was the term I used accidentally, and which is exactly the opposite.
There was a problem hiding this comment.
Silly me. It’s documented like that, too:
where DISPLAY is a form specifying conditions to match certain
terminals and ATTS is a property list (ATTR VALUE ATTR VALUE...)
specifying face attributes and values for frames on those
terminals. On each terminal, the first element with a matching
DISPLAY specification takes effect, and the remaining elements in
SPEC are disregarded.
C-h f RET defface RET
There was a problem hiding this comment.
I’m not sure I got your question about default though. The current frame being default applies to the invocation of (window-system) without arguments, which I suppose is what custom.el does, and it’s evaluated every time a new frame is created.
There was a problem hiding this comment.
That answers my question, thanks! 🙂
I was just wondering how the code was evaluated. I was guessing it would short circuit, but wasn't sure. Thanks!
|
I don't have a computer with me right now but I'll merge this in tomorrow morning. My phone is currently spazzing so I'll wait until I'm back at my laptop to merge. |
(display-graphic-p)will evaluate to nil when starting Emacs in daemon mode.Instead, we now use the attribute switch system provided by custom.el, which
apply definitions when a frame is created and will do the right thing when
running Emacs daemon.
Fixes #23