Closed victorolinasc closed 3 years ago
Try updating the cfrs package. I pushed a fix for just such a bug some time ago: https://github.com/Alexander-Miller/cfrs/commit/d4cee9074b31b283b1475bfc8fe3c63ab51dbb61
If updating doesn't help tell me which message the following code outputs:
(progn
(cfrs-read "> ")
(run-with-timer 0.5 nil (lambda () (message "Cursor %s" cursor-type))))
It prints "Cursor t" but I can't see it heheh
It seems like a color issue here... if I look VERY CLOSELY, when the prompt appears I can see an empty cursor line (bottom right of the screen shot):
It is very subtle and it seems like when there are characters it blends with the background color (just guessing here...)
I've typed "asd" and pressed C-a. I can assure it is on the letter "a" because C-d deletes that char.
I am on Emacs master with full native-comp enabled if that helps.
Forgot to mention I am on master of cfrs too (using melpa and not melpa-stable).
Do use use evil? If not, does this help? (add-hook 'cfrs-input-mode-hook (defun test () (set-cursor-color "blue")))
I don't use evil.
That does help in scratch buffer when I call (cfrs-read "> ")
directly but not in treemacs window.
I do run Emacs in daemon mode.
I use doom theme vibrant.
This is the config I tried:
(use-package treemacs
:defer t
:config
(treemacs-filewatch-mode t)
(treemacs-git-mode 'simple)
(treemacs-resize-icons 22)
(add-hook 'treemacs-mode-hook (lambda() (display-line-numbers-mode -1)))
(add-hook 'cfrs-input-mode-hook (lambda() (set-cursor-color "DeepSkyBlue"))))
Does this hook output the right color?
(add-hook 'cfrs-input-mode-hook (defun test () (message "Color %s" (face-background 'cursor))))
How do you start your daemon - emacs --daemon
? How do you connect to the daemon?
I use systemd unit for the daemon and use emacsclient from a desktop file. After altering my init.el I run systemctl --user restart emacs.service
.
After adding the hook, restarting my daemon and opening treemacs it prints: "Color #292f34" on Messages buffer but still no visible cursor. If I run the prompt manually in a scratch buffer I can see this:
It seems daemon related... I might just give up using the daemon or trying to start it from within the window manager somehow (KDE by the way). I had other issues with things being started this way.
I still think this setup should work but maybe I am wrong.
Yeah, daemon mode tends to do weird things with faces. Another example you might have noticed is treemacs' visual feedback. When I use the daemon (pulse-momentary-highlight-one-line (point) 'treemacs-on-success-pulse-face)
does not pulse at all, the color just gets stuck until you do something else.
At any rate I'll try and reproduce the issue on my end, maybe I'll be able to find a solution. In the meantime you can disable the popup dialog with (setf treemacs-read-string-input 'from-minibuffer)
.
THANKS A LOT! That is awesome support and awesome work from an open-source project! This does the trick for me :)
Please, feel free to close this issue if you think it is not related to treemacs. Once again, thank you very much.
More stuff to try:
Tried the inhibit x-resources but did not work for me =/
Will try default frame alist later today... Also, I will try to start the daemon differently... as I understand it, I am starting from systemd and that starts before any graphical window is shown. I have other visual glitches because of that...
This thread is very timely for me, because I had this very minor annoyance with Treemacs for a while (which I absolutely love btw and is such an integral part of my workflow, especially because of its multiple tree feature and org-based config, that is so great and useful), and only today I decided to try to do something concrete about it. My first guess was some bad interaction with my theme (I use the spacemacs-theme
with a vanilla, non-Spacemacs setup), but when I disabled it I saw that it wasn't the culprit. So I went in the source and found about the 'treemacs-read-string-input
option, which I didn't know about. Using the minibuffer solves it for me, but it would be nice if both options worked flawlessly I guess.
I've managed to reproduce the problem now. At least on my end there was the following configuration that lead to an invisible cursor:
I've pushed an update to cfrs (not treemacs) now that'll do away with that 0. Let me know if it fixes your problem.
It still does not work for me unfortunately. This is my config:
(use-package treemacs
:defer t
:config
(treemacs-filewatch-mode t)
(treemacs-git-mode 'simple)
(treemacs-resize-icons 22)
(add-hook 'treemacs-mode-hook (lambda () (display-line-numbers-mode -1)))
(add-hook 'cfrs-input-mode-hook (lambda() (set-cursor-color "DeepSkyBlue"))))
This is the current version of cfrs: 20210529.1123
.
I will start to tinker with different ways to start the daemon and see if it changes anything... I have issues with doom-modeline and some others as well unfortunately...
For me also unforunately it doesn't seem like it fixes the problem.
Does it work when you explicitly set the frame parameters like this: (setf cfrs-frame-parameters '((cursor-type . bar) (cursor-color . "red")))
?
Yes, it works for me when I do what you last suggested!
Great, then we just need to find out why my workaround didn't work. Here, eval this, and then tell me what it logs:
(defun cfrs--determine-cursor-type ()
(message "Custor Type %s Frame Param %s" cursor-type (frame-parameter (selected-frame) 'cursor-type))
(let ((ct (if (eq t cursor-type)
(frame-parameter (selected-frame) 'cursor-type)
cursor-type)))
(if (and (consp ct) (= 0 (cdr ct)))
(car ct)
ct)))
The result is box
, and the log says: Custor Type t Frame Param box
To be clear this is after I have done everything you suggest above: updating cfrs
to 20210529.1123
and running your setf
command just above (so the cursor now shows, as a red line).
The result is box, and the log says: Custor Type t Frame Param box
That means the workaround is working as intended, and a box
cursor is used. Let's also have a look at the color next:
(defun cfrs--determine-cursor-type ()
(message "Custor Type %s Frame Param %s Color %s"
cursor-type
(frame-parameter (selected-frame) 'cursor-type)
(face-background 'cursor))
(let ((ct (if (eq t cursor-type)
(frame-parameter (selected-frame) 'cursor-type)
cursor-type)))
(if (and (consp ct) (= 0 (cdr ct)))
(car ct)
ct)))
color = #e3dedd
I assume the color is the right one, and should be visible, right?
In that case we need to go back to the cursors. Have a look at the eldoc of cursor-type
and just try using them all in cfrs-frame-parameters
and then tell me which work, and which don't.
So no the color is not the problem, apparently. Ok so please bear with me as my Elisp is quite.. rudimentary.
It seems that the first time your new cfrs--determine-cursor-type
function is called, there are only 1 frame, and the second time, 2 frames (the additional one being the widget just created by cfrs
I assume).
And although I don't understand exactly how it works, it seems that there's some confusion, in this function, about which frame exactly is the (selected-frame)
, in both scenarios (which is the frame from which you extract the cursor-type
property).
So after a lot of experimentation, the only logic making it work for me, in my particular context, is to do this:
(defun cfrs--determine-cursor-type ()
(message "%s frames at the moment the function is called, getting the cursor-type from the last.." (length (frame-list)))
(frame-parameter (car (last (frame-list))) 'cursor-type))
I suspect it's probably not going to be the final solution, as it's probably not general enough, or too fragile or whatever, but perhaps it will help you find a more solid one.
It'd be really strange if some different frame could be selected on subsequent calls. The cursor-color lookup is among the first things that happens, before any frame-focus switches. So let's try logging it as well:
(message "Frame %s\nWindow %s\nBuffer %s"
(selected-frame)
(selected-window)
(current-buffer))
For me this output the same thing for the 1st and 2nd calls:
Frame #<frame *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>* - GNU Emacs at am-laptop 0x558b30394820>
Window #<window 9 on *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>*>
Buffer *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>*
Quit
Frame #<frame *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>* - GNU Emacs at am-laptop 0x558b30394820>
Window #<window 9 on *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>*>
Buffer *Treemacs-Scoped-Buffer-#<frame *Messages* - GNU Emacs at am-laptop 0x558b30394820>*
Hi, it seems that I was confused in my previous analysis.. you are right the problem is not the selected frame.
It seems that in my case, cursor-type
is nil
, rather than t
, when this line runs:
https://github.com/Alexander-Miller/cfrs/blob/e16a01012545d378150432fa10684a2a7d1cc2d1/cfrs.el#L98
which results in ct
being nil
, instead of the value of (frame-parameter (selected-frame) 'cursor-type)
.
So if I replace the above line by:
(let ((ct (if (or (eq t cursor-type) (eq nil cursor-type))
it seems to fix the problem (at least in my context).
I've pushed a patch to take nil into account now. Let me know if it works.
I just upgraded through melpa and it works perfectly, many thanks!
Great. @victorolinasc what about you?
Sorry I haven't been active here...
Just updated, restarted the daemon and it worked! Once again thanks for you work!
Cheers! I'll close the issue
Hi! First of all, thanks a lot for your awesome work. I use it daily and it helps me a lot :)
Second of all, I'm still a noob in ELisp. Sorry if this is completely wrong... I'll update the issue with what I can if given proper directions though!
Can't view the cursor when renaming a node
In the past treemacs had a different UI for renaming a node. After it became "inline" it has been hard to use it because I can't see the cursor and there are plenty of times where I just want to correct a typo. Here is a screen shot about current UI for my configuration.
When I press C-b or C-f it does not show. I think this is a bug but not 100% sure :) If there is anything I might add here just please let me know.
Thanks once again!