Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lsp-ui-sideline wrong width calculation? #285

Closed
Dushistov opened this issue May 4, 2019 · 17 comments
Closed

lsp-ui-sideline wrong width calculation? #285

Dushistov opened this issue May 4, 2019 · 17 comments

Comments

@Dushistov
Copy link

Dushistov commented May 4, 2019

Arch Linux amd64 / GNU Emacs 26.2 / lsp-ui 20190428.1045

See screenshot bellow. There is a lot of space at the right side of editor window,
but for some reason lsp-ui-sideline insert new line symbols into my code,
so code in emacs jump up and down during scrolling.

b

@yyoncho
Copy link
Member

yyoncho commented May 4, 2019

I am unable to repro with clean config and using emacs26.2. You may follow the instructions in #284 to disable the sideline.

Which window manager do you use?

@alanz
Copy link
Contributor

alanz commented May 4, 2019

I seem to recall investigating this before, and the problem was the box around the last word, which extends beyond the character bounds, so the end of char calculation is wrong.

So in my customisation section I have

 '(lsp-ui-sideline-current-symbol ((t (:foreground "gray" :box (:line-width -1 :color "cyan") :weight ultra-bold :height 0.99))))

Which basically makes the char size slightly smaller, so the regular calculation error is not longer a problem.

@Dushistov
Copy link
Author

@yyoncho

I am unable to repro with clean config and using emacs26.2

Wild idea, may be lsp-ui code not DPI in-depended,
and you use not "4K" monitor?

$ xdpyinfo | grep screen -A 3
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    3840x2160 pixels (527x296 millimeters)
  resolution:    185x185 dots per inch

Which window manager do you use?

icewm

@Dushistov
Copy link
Author

Dushistov commented May 4, 2019

@alanz

Looks like difference in my case is bigger, so your receipt doesn't work as is.

@yyoncho

I am able to reproduce your

I am unable to repro with clean config

I remove my font preferences, it looks like no bugs,
see attached screenshot.

But if I enable these lines in my ~/.emacs

(if (eq window-system 'x)
     (progn
       (message "we running under X Window system")
       (set-default-font "Consolas-11")
       (set-fontset-font (frame-parameter nil 'font)
			 'han '("Vera Sans YuanTi" . "unicode-bmp"))
))

the bug appears again, some problem with not monospace font?

P.S.
The default font looks very ugly on my monitor,
so I can not use it.

good

@sebastiencs
Copy link
Member

Hi @Dushistov, does f2e2f74 fix your issue ?
If not, what is the value of fringe-mode and (window-margins) in your buffer ?

  • M-: fringe-mode
  • M-: (window-margins)

@Dushistov
Copy link
Author

Thank you, @sebastiencs !

I updated lsp-ui to 20190507.700 and looks it's code contains f2e2f74 .
But f2e2f74 does not fix issue.

fringe-mode mode gives (25 . 0)
(window-margins) gives nil

@fg-cdd
Copy link

fg-cdd commented May 14, 2019

Hello,

I seem to have the same problem, with scala code. I think that it comes from the font-locked string. If I change the code in function lsp--fontlock-with-mode (file lsp-mode) to return the raw string, the problem disappears. The box around the function is not the problem. I also have a very recent version incorporating f2e2f74.
In my case, font-lock puts some keywords in bold, though I use a monospace font, where bold characters don't take more space.

Here is my modified function:

(defun lsp--fontlock-with-mode (str mode)
  "Fontlock STR with MODE."
  str)

I also add 2 screenshots, one showing the problem. The second with the code modified like mentioned above.

emacs-lsp-ui-sideline-problems
emacs-lsp-ui-sideline-ok

@dsyzling
Copy link
Member

I can replicate this behaviour on Windows 10 with Emacs 26.1 and 26.2 - it's fine on Arch Linux with both of those versions.

I think the markdown-mode type face is being set to Courier as a default which is rendering horribly on my system. Try customising the markdown-mode faces and changing markdown-mode-face to use consolas (or whatever font you are using for editing). After apply and save this dropped the following into my custom.el config:

(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.
 '(markdown-code-face ((t (:inherit consolas)))))

@dsyzling
Copy link
Member

This doesn't appear to render the box/rectangle on the end of each of the symbol lines though - but it does avoid the line wrapping. I also noticed markdown files (.md) have the same awful rendering of code blocks in Emacs on windows and this improved the rendering of those docs.

@ciscogarcia
Copy link

I can replicate this behaviour on Windows 10 with Emacs 26.1 and 26.2 - it's fine on Arch Linux with both of those versions.

I think the markdown-mode type face is being set to Courier as a default which is rendering horribly on my system. Try customising the markdown-mode faces and changing markdown-mode-face to use consolas (or whatever font you are using for editing). After apply and save this dropped the following into my custom.el config:

(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.
 '(markdown-code-face ((t (:inherit consolas)))))

This fixed the issue for me. Thank you for the suggestion.

@Yevgnen
Copy link

Yevgnen commented Jun 26, 2019

Same issue with the default emacs theme...and solve with the same solution given by @dsyzling ...

@serhiip
Copy link

serhiip commented Jul 28, 2019

I can replicate this behaviour on Windows 10 with Emacs 26.1 and 26.2 - it's fine on Arch Linux with both of those versions.

I think the markdown-mode type face is being set to Courier as a default which is rendering horribly on my system. Try customising the markdown-mode faces and changing markdown-mode-face to use consolas (or whatever font you are using for editing). After apply and save this dropped the following into my custom.el config:

(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.
 '(markdown-code-face ((t (:inherit consolas)))))

This fixed an issue for me also

@chama-chomo
Copy link

chama-chomo commented Sep 21, 2019

I was experiencing the same issue and finally have a root cause (thanks to @yyoncho), which was enabled 'indent-guide-mode' together with lsp. When I disabled it, calculation of sideline message placement started working properly, so apparently, lsp-ui-sideline is not taking 'indent-mode' mode into account.

@brotzeit
Copy link
Member

Hmmm, I just merged #388. Can somebody please test this ?

@pengwyn
Copy link

pengwyn commented Apr 28, 2020

I'm new to this issue and lsp-ui in general, but I came across the same issue. I have a version past #388 (version 20200402.839 on melpa). It was fixed by following @dsyzling's comment, although I just the face to inherit from default. I also had the same issue as @chama-chomo and had to disable indent-guide-mode.

@sebastiencs
Copy link
Member

Since 1f3e970 lsp-ui-sideline force the size of the text to be a fixed value.
Allowing different sizes would make difficult and probably impossible the computation of the space width (emacs doesn't provide such API)

I think that commit fixed the issue, closing

@ntc2
Copy link

ntc2 commented Sep 22, 2023

I'm experiencing this issue in Emacs 27.1 with lsp-ui version 8.0.1 on Ubuntu 22.04, using the Terminus-14 font via

(set-face-attribute 'default nil :font "Terminus-14")

I was able to fix the problem using a variant of the fix suggested in the comments above, which I got from a reddit post about a similar problem. Here is the variant I used:

  (custom-set-faces
   '(markdown-code-face ((t (:inherit default)))))

Please add the fix to the issue description, since many people commented here to say it worked for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests