Mlscroll starts too small with doom-modeline

[tefkah]

I really like mlscroll-mode, but I have had one persistent issue, namely that no matter my configuration, mlscroll starts at the smallest possible width.

This is my configuration

(use-package! mlscroll
  :init
  (progn
  (setq mlscroll-right-align nil)
  (add-to-list 'mode-line-misc-info '(:eval (mlscroll-mode-line)))
  (setq mlscroll-border 10)
  (setq mlscroll-width-chars 20))
  :config
  (mlscroll-mode 1)
  )

I've tried to load it after doom-modeline, add hooks, put everything in :config, but nothing seems to help. The only thing that seems to work is to call (mlscroll-mode) twice manually, after which it looks like this which is what I want.

Could you point me in the right direction for setting this up? Thanks again for the package!

[jdtsmith]

A few people have asked about integrating with doom-mode-line. That looks really nice, thanks for the contribution. I'm not a doom user so may need a bit of your help debugging this.

First: Your mlscroll-border is quite large! That's the border in pixels on all sides of the display. I think 2–4 is a more reasonable range. When I use such a large border, my MLScroll is not visible (but the space for it is there). Can you try that first?

[jdtsmith]

OK I tried out doom-modeline and had reasonable success with:

(use-package mlscroll
  :ensure t
  :init
  (setq mlscroll-right-align nil)
  (add-to-list 'mode-line-misc-info '(:eval (mlscroll-mode-line)) 'append)
  (setq mlscroll-width-chars 15)
  (setq mlscroll-border (floor (/ doom-modeline-height 4)))
  :config
  (mlscroll-mode 1))

At least MLScroll shows up, looks correct, and is functional with the default doom-mode-line config. So whatever is causing your "too small" issue must result from your additional config. I did discover and fix a small bug that led to misinterpreted mouse events when mlscroll-right-align is nil, but that isn't related.

This setup isn't ideal, e.g. when which-function-mode is enabled. MLScroll really wants to be in a fixed position on the mode-line, rather than moving all around, which is why right-align works so well. I'm not sure how to accomplish that with doom-mode-line. I do notice that it supports nyan-mode and one other, so I suggest opening an issue over there to see if they can add a "segment" (in a fixed location) for MLScroll directly.

I'll leave this open in case you want to dig deeper on the config yourself in addition.

[tefkah]

Thank you for digging into this! Unfortunately, I still can't seem to make it work well, even after removing doom-emacs configuration and all of my custom configuration, at startup it still looks like this

Only after calling it twice do I get the desired result

It probably still has to do with some doom-emacs specific configuration which is not easy to fix. Regardless, thanks for looking into it!

[tefkah]

Those screenshot are a bit unclear, but I think the point is clear haha.

[jdtsmith]

I see. I had just tried the doom-mode-line package, not "full doom", and it worked for me without the re-enabling trick. Can you try moving your setup of MLScroll to be after all your doom mode line stuff?

You can see that it pushed the DOOM version off the RHS, so doom is already clearly right-aligning things in the mode line itself based on some assumptions (which MLScroll violates).

The issue is that all the various tools which hack mode line variables tend to stomp all over each other, so perhaps that's why you have to turn it off then on again. Perhaps you could try it with a simple/default mode line, to rule out some other problem.

I'm quite certain doom provides the means of inserting something more complex in their mode line, I'm just not sure what that is. Given that they support nyan-mode and one other, I bet they'd be able to include it in a less hackish manner. If you open an issue over there, can you please link to it here?

[jdtsmith]

I had a thought about your short initial MLScroll. It finds the pixel width for the scroll bar based on (face-font 'mode-line), which perhaps is in a precarious state when MLScroll is initialized due to Doom or other customizations. When you just start (with the too-small scroller), can you C-h v mlscroll-mode-line-font-width [Ret]? For me it's 7 (pixels wide). This would explain why restarting mlcroll picks up the correct width.

[tefkah]

You are correct! Indeed, at startup it is 1, but after resetting it it becomes 9! I had hoped I could fix it by manually setting that value at init or after loading, but that does not seem to work.

[tefkah]

That also gave me a hint to the solution, which is slightly embarrassing... I have an open PR at doom-modeline for putting the modeline in the header. I think that because of that, the 'mode-line font gets set to some weird value, which means that Mlscroll can't read it, possibly? Or perhaps it tries to set it to the header-line value, but the header-line face is not set correctly, as most themes don't support it out of the box.

However, what I said above was incorrect: if I set the "mlscroll-mode-line-font-widthto 9 in the:config` section, it works fine. Unfortunately, doom-modeline does not properly take it's size into account, but that's for another issue. Thanks for your help!

[jdtsmith]

Glad you found a fix. Is there an issue with header line vs. mode line? Perhaps I should not be using (face-font 'mode-line) to determine the character width at all; some people use a different face in the mode line. If you set mode-line-font-width, it will just get reset shortly after. You can try evaluating this (aref (font-info (face-font 'mode-line)) 11) which is how MLScroll winds the character width. Maybe do the same for your header face.

[tefkah]

The plot thickens further: it seems to misbehave when using emacs as a daemon, but not otherwise. I'm pretty sure this is because of some daemon-specific settings in doom-modeline, but I'm not sure which, just leaving this here in case someone else has this issue.

[jdtsmith]

In the sense that (aref (font-info (face-font 'mode-line)) 11) is artificially low (like 1) at startup time?