emacs-sideline / sideline

Show information on the side
GNU General Public License v3.0
118 stars 14 forks source link

Fix text align for `buffer-face-mode` #20

Closed chuxubank closed 5 months ago

chuxubank commented 5 months ago

When we use buffer-face-mode and set different font other than the default font, the text align of sideline is incorrect, like this:

image

After this fix, it would looks like:

image

See also: https://github.com/emacs-lsp/lsp-ui/issues/184

jcs090218 commented 5 months ago

This solution doesn't look right since the length function isn't accurate enough for wider characters. 🤔

And it doesn't work on my machine:

2024-03-18 12 02 50

chuxubank commented 5 months ago

Wow, it seemed you are using variable pitch font for programming, thats cool. I will try to fix this :P

The length only calculate the string's length, the issue is the (window-font-width) do not work if the font's width is not fixed. Seemed not easy to fix it. (One possible fix could change the sideline's font to a mono font.)

I will keep this PR open and use the modified version in my Emacs config for now.

jcs090218 commented 5 months ago

Wow, it seemed you are using variable pitch font for programming, thats cool.

No, those are the default for buffer-face-mode on Windows. I use Ubuntu Mono by default.

The length only calculate the string's length, the issue is the (window-font-width) do not work if the font's width is not fixed. Seemed not easy to fix it. (One possible fix could change the sideline's font to a mono font.)

Yes, this is not trivial. I have spent countless hours but still haven't found the ideal solution. 😓

chuxubank commented 5 months ago

No, those are the default for buffer-face-mode on Windows. I use Ubuntu Mono by default.

I see, I think my fix should work for mono fonts when using buffer-face-mode, and it also benefit the text-scale-mode

I am using Iosevka as default font and use Victor Mono for programming.

In https://github.com/emacs-lsp/lsp-ui/issues/184#issuecomment-1162406920 there's a function to do with the variable pitch font but kind of heavy.

I think my fix is enough for most cases when using mono fonts.

gustavotcabral commented 5 months ago

No, those are the default for buffer-face-mode on Windows. I use Ubuntu Mono by default.

I see, I think my fix should work for mono fonts when using buffer-face-mode, and it also benefit the text-scale-mode

I am using Iosevka as default font and use Victor Mono for programming.

In emacs-lsp/lsp-ui#184 (comment) there's a function to do with the variable pitch font but kind of heavy.

I think my fix is enough for most cases when using mono fonts.

I've been using my fix since then (Ubuntu 22.04, using Wayland and variable-width fonts), flawlessy. I didn't even know this bug hadn't been fixed yet.

variable_width

jcs090218 commented 5 months ago

and it also benefit the text-scale-mode

How about something like?

(defun sideline--align-right (str offset)
  "Align sideline STR from the right of the window.

Argument OFFSET is additional calculation from the right alignment."
  (let ((graphic-p (display-graphic-p))
        (fringes (window-fringes)))
    (list (+
           ;; If the sideline text is displayed without at least 1 pixel gap from the right fringe and
           ;; overflow-newline-into-fringe is not true, emacs will line wrap it.
           (if (and graphic-p
                    (> (nth 1 fringes) 0)
                    (not overflow-newline-into-fringe))
               1
             0)
           (* (window-font-width)
              (+ offset (if graphic-p
                            ;; If right fringe deactivated add 1 offset
                            (if (= 0 (nth 1 fringes)) 1 0)
                          1)
                 (sideline--str-len str)))))))

I think my fix is enough for most cases when using mono fonts.

It won't work if you have wide characters. The above patch should fix this as well.

chuxubank commented 5 months ago

This version works well for me. Thanks! I will update this PR.

jcs090218 commented 5 months ago

Thank you!