Alexander-Miller / treemacs

GNU General Public License v3.0
2.1k stars 154 forks source link

Can't view the cursor when renaming a node #814

Closed victorolinasc closed 3 years ago

victorolinasc commented 3 years ago

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.

image

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!

Alexander-Miller commented 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))))
victorolinasc commented 3 years ago

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):

image

It is very subtle and it seems like when there are characters it blends with the background color (just guessing here...)

image

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.

victorolinasc commented 3 years ago

Forgot to mention I am on master of cfrs too (using melpa and not melpa-stable).

Alexander-Miller commented 3 years ago

Do use use evil? If not, does this help? (add-hook 'cfrs-input-mode-hook (defun test () (set-cursor-color "blue")))

victorolinasc commented 3 years ago

I don't use evil.

That does help in scratch buffer when I call (cfrs-read "> ") directly but not in treemacs window.

victorolinasc commented 3 years ago

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"))))
Alexander-Miller commented 3 years ago

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?

victorolinasc commented 3 years ago

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:

image

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.

Alexander-Miller commented 3 years ago

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).

victorolinasc commented 3 years ago

THANKS A LOT! That is awesome support and awesome work from an open-source project! This does the trick for me :)

victorolinasc commented 3 years ago

Please, feel free to close this issue if you think it is not related to treemacs. Once again, thank you very much.

Alexander-Miller commented 3 years ago

More stuff to try:

victorolinasc commented 3 years ago

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...

cjauvin commented 3 years ago

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.

Alexander-Miller commented 3 years ago

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.

victorolinasc commented 3 years ago

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...

cjauvin commented 3 years ago

For me also unforunately it doesn't seem like it fixes the problem.

Alexander-Miller commented 3 years ago

Does it work when you explicitly set the frame parameters like this: (setf cfrs-frame-parameters '((cursor-type . bar) (cursor-color . "red")))?

cjauvin commented 3 years ago

Yes, it works for me when I do what you last suggested!

Alexander-Miller commented 3 years ago

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)))
cjauvin commented 3 years ago

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).

Alexander-Miller commented 3 years ago

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)))
cjauvin commented 3 years ago

color = #e3dedd

Alexander-Miller commented 3 years ago

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.

cjauvin commented 3 years ago

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.

Alexander-Miller commented 3 years ago

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>*
cjauvin commented 3 years ago

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).

Alexander-Miller commented 3 years ago

I've pushed a patch to take nil into account now. Let me know if it works.

cjauvin commented 3 years ago

I just upgraded through melpa and it works perfectly, many thanks!

Alexander-Miller commented 3 years ago

Great. @victorolinasc what about you?

victorolinasc commented 3 years ago

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