solarized-emacs
solarized-emacs copied to clipboard
bbatsov
weird cursor issues
So I really enjoy this mode. I used to use the official one, but I had to patch it to make it do what i need and it wouldn't support light mode. This one just works, so first congrats on that, good job. :)
A weird thing that happens here though is that the cursor disappears when i select backwards. It's a little hard to explain so hopefully a screenshot will help?
This is a normal string of digits, with the cursor at the beginning:
I hit c-space and move the cursor left, the first character is selected:
You can already see the first problem: because there's no distinction between the cursor color and the selection color, it seems that two characters (12) are selected, when in fact, only one is selected (1). Let's try this backwards now. Clear the mark and go to the end of line:
Right. Then let's do c-space again and move the point one character to the left:
Heeey what happened to my cursor! It disappeared!?
That's not so great... now the last character is selected, but there's no visual feedback at all.
This is all quite confusing: I think it would help tremendously if the cursor and the region would have slightly different colors.
I probably noticed this only because I was experimenting with a blinking cursor and recently went back to a fixed one...
Am I the only one seeing this?
another approach i'd consider for this would be to make the cursor face customizable. i'd like, for example, to be able to pick a color like blue-hc for my cursor but that is, naturally, not available outside the color theme.. and while I could put the raw hex value for that color in a custom face, that won't work when flipping back and forth with light and dark...
i know this possibly opens a pandora's box, but can we make at least some faces customizable?
Doesnt emacs use a blinking cursor by default to make it clear where the active current cursor is located?
I even have different cursor colors to highlight different modes but thats not handeled by the theme at all.. Since I use region-bindings-mode I have a special cursor when a region is active so that I know which bindings are active....
;; Settings that might have been set by loading libraries
;; use-package frame.el
(setq-default blink-cursor-mode t
blink-cursor-interval 0.6
cursor-type 'bar)
(blink-cursor-mode)
(defun cursor-style-update-action ()
(when (bound-and-true-p cua-normal-cursor-color)
(let* ((current-cursor-color (cdr (assq 'cursor-color (frame-parameters))))
(cursor-style (cond
((bound-and-true-p region-bindings-mode) (list "#d33682" '(bar . 8) t))
((bound-and-true-p god-local-mode) (list "#268bd2" 'box nil))
((bound-and-true-p buffer-read-only) (list "#859900" 'box nil))
(t (list cua-normal-cursor-color my-normal-cursor-type t)))))
(unless (equal (nth 0 cursor-style) current-cursor-color)
(set-cursor-color (nth 0 cursor-style)))
(unless (equal (nth 1 cursor-style) cursor-type)
(setq cursor-type (nth 1 cursor-style)))
(unless (equal (nth 2 cursor-style) blink-cursor-mode)
(blink-cursor-mode (or (nth 2 cursor-style) -1))))))
(defvar cursor-style-timer nil)
(defun cursor-style-update ()
(when cursor-style-timer
(cancel-timer cursor-style-timer))
(setq cursor-style-timer
(run-with-idle-timer 0.2 nil 'cursor-style-update-action)))
(hook-into-modes 'cursor-style-update
'(activate-mark-hook
deactivate-mark-hook
region-bindings-mode-hook
window-configuration-change-hook
minibuffer-setup-hook
minibuffer-exit-hook
god-mode-enabled-hook
god-mode-disabled-hook
god-local-mode-hook
read-only-mode-hook
after-change-major-mode-hook
focus-in-hook
focus-out-hook
))
(defadvice hardhat-local-hook (after cursor-style-update activate)
(cursor-style-update))
Doesnt emacs use a blinking cursor by default to make it clear where the active current cursor is located?
It makes it clearer, but not clear enough to my taste. Beyond, I disabled the blinking cursor here and I think it's reasonable to support that configuration as well.
So #291 was closed and I'm not sure what the way forward is here: are you saying that the cursor should be a defcustom? How about having the possibility of flipping back and forth between light and dark while keeping meaningful customization?
Idk. we could have an solarized-emphasize-cursor boolean setting or something similar.
what i would really like is the possibility of setting the cursor to an arbitrary solarized color (e.g. "red") and have it switch correctly when i select the dark or light theme (e.g. #FF6E64 vs #990A1B). do you know what i mean? is that even possible?
one thing I have tried is doing a customize-face on the cursor face, but that fails: when Emacs restarts, it reloads the theme which overrides the face customization. That might be a bug in the theme system, but it still makes it difficult to fix this problem.
okay - here's another proposal: how about we make the cursor and region look different? right now, cursor is:
https://github.com/bbatsov/solarized-emacs/blob/7c91f489cf00db39ea1977a0572e2293569b769b/solarized.el#L270
and region is:
https://github.com/bbatsov/solarized-emacs/blob/7c91f489cf00db39ea1977a0572e2293569b769b/solarized.el#L309
I have found I have better results with:
`(cursor ((,class (:foreground ,base03 :background ,base3
:inverse-video t))))
`(region ((,class (:foreground ,base01 :background ,base1))))
Does that make sense?
I don't think that it might skew the intended solarized normal contrasts but I'll try it and see what happens..
Regarding the customization.. If the theme fails to pick it up on emacs start up maybe the theme is loaded before the customization is set in your init file?
I don't think that it might skew the intended solarized normal contrasts but I'll try it and see what happens..
I'm not sure what you mean here, but i must say that i feel it looks much better. The region looks a little more toned down than before and contrasts better with the cursor.
Looking back at the original solarized page I wonder if selection areas shouldn't be using base2/base02 instead, however... It looks like that was reserved for the secondary selection though, so I guess that makes sense as well...
Regarding the customization.. If the theme fails to pick it up on emacs start up maybe the theme is loaded before the customization is set in your init file?
i am not sure what's happening with that... I have a very old .emacs file, created before themese were even a thing, so I may doing something wrong. At the end of the .emacs file, I have:
(load "~/.emacs-custom")
And that's where the theme is configured. First there's something like:
(custom-set-variables
;; ...
'(custom-enabled-themes (quote (solarized-dark)))
;; ...
)
And then at the end of that same file, the faces are set:
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(default ((t (:background nil))))
'(anzu-mode-line ((t (:foreground "orange" :weight bold))))
'(cursor ((t (:background "#990A1B"))))
'(notmuch-search-flagged-face ((t nil)))
'(notmuch-tag-flagged ((t nil))))
At startup, the cursor face does not take effect, but if I visit the .emacs-custom file, and (eval-defun) the (custom-set-faces) block, the cursor gets reset properly.
Not sure wth is going on here...
and for what it's worth, here's what the new region face looks like (without the cursor color modification of course):
I thought that you had created a new defcustom in solarized.el, didn't read your response properly. I don't know about custom-set-faces, I dont think I have ever used that feature in my init files...
The contrast ratio is too low with that region face.. I think you currently have to either use a complicated solution like i do to change the cursor depending on context or just use the default blinking cursor. We try to support as much as possible but if you want less common configuration combinations you probably have to do some work yourself to make it nice.
well... a "low contrast ratio" beats "no contrast ratio at all" IMHO.
i'd be happy to use a slightly more complicated solution, but i think this should be fixed in solarized-emacs itself. a non-blinking cursor is the default behavior in Emacs, AFAICT, and it should be supported...
besides, from what i can tell your solution doesn't adapt to the two solarized styles: it assumes you're in "light" or "dark" mode and does not adapt the cursor depending on which one is enabled. it just hardcodes a color. in that sense, why not just change the color to #859900 or whatever color you picked for one of those modes instead of the ambiguous default? :)
thanks for the feedback!
Blinking cursor is the default emacs -q shows a blinking cursor in both a freshly compiled 26.1 in linux or the precompiled 25.1 i have on my mac.
I have been thinking about the idea to provide one or more additional add on packages to solarized theme which set up related stuff which a theme by itslef can't do but I havent found the time do do it..
Some of it is tagged with the solarized-config label https://github.com/bbatsov/solarized-emacs/labels/solarized-config .. not sure if all of it is still up to date. Some suggestions are in the readme.md file as well.
yeah, it'd be quite useful to have a few more knobs there... i still think my proposed color changes would improve on the default situation though... it seems strange to have the same color for the cursor and the region, in general, no?
Yes it's strange but the solarized palette doesn't give us many options to choose from if we want to keep the fg/bg contrast ratio at the desired level.. Basically the only proper combinations are base0 on base03 OR base 1 on base02 OR any accent color on base0.. The accent colors are used everywhere so defaulting the cursor to one of them can cause a lot of problems.
Since Emacs is more or less infinitely customizable the user can almost always enforce any new behaviour by themselves.
And there is another solarized theme for emcas which has a more heavy and pronounced look for those who wants that.
Since Emacs is more or less infinitely customizable the user can almost always enforce any new behaviour by themselves.
Well, I've had problems trying to override cursor-faces, so this is why I am trying to fix this directly in the theme.
And there is another solarized theme for emcas which has a more heavy and pronounced look for those who wants that.
Yep, I have tried that one and patched it and worked with it for a long time, but never got anywhere. And it doesn't have the light/dark version. Yours is much better and, so far, the cursor issue is the only one I have found, which is an amazing improvement.
Yes it's strange but the solarized palette doesn't give us many options to choose from if we want to keep the fg/bg contrast ratio at the desired level.. Basically the only proper combinations are base0 on base03 OR base 1 on base02 OR any accent color on base0.. The accent colors are used everywhere so defaulting the cursor to one of them can cause a lot of problems.
yeah well, I'm not sure how to deal with that, but the patch I proposed works very well here. I'm not sure i understand what contrast issue you are refering to, in fact...
I see that emacs-24 got a new face spec:
New face spec attribute :distant-foreground
specifies foreground to use if background color is near the foreground color that would otherwise have been used.
that could maybe work...
any update here? what's the next step? i keep on patching this with #291 here which works well...
At startup, the cursor face does not take effect, but if I visit the .emacs-custom file, and (eval-defun) the (custom-set-faces) block, the cursor gets reset properly.
For what it's worth, I traced that behavior back to the emacs --daemon mode. When Emacs is started normally (e.g. on a terminal or a launcher in a GUI), the (custom-set faces '(cursor ((t (:background "#990A1B"))))) entry works correctly. When it's started with emacs --daemon and a new frame is created (with e.g. emacsclient --create-frame), the customization doesn't apply. I asked a question about this on SE, but maybe it's just a bug in emacs itself...
Otherwise I'm truly wondering how I should try and fix this bug in the future. You suggested using :distant-foreground and I acknowledge that, but I'm not sure what color you would like there, so I'm hesitant in trying to push a change there...