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

[Bug] #752

Open
3 tasks done
psionic-k opened this issue Dec 5, 2024 · 10 comments
Open
3 tasks done

[Bug] #752

psionic-k opened this issue Dec 5, 2024 · 10 comments
Labels
bug Something isn't working

Comments

@psionic-k
Copy link

psionic-k commented Dec 5, 2024

Thank you for the bug report

  • I am using the latest version of doom-modeline related packages.
  • I checked FAQ.
  • You may also try reproduce the issue using clean environment and minimal configurations with
    the command emacs -Q.

Bug description

I previously had a setting combination to pad my column on the right. This configuration no longer achieves the desired effect. The -3 in mode-line-position-column-format is ignored.

(setopt doom-modeline-position-column-line-format '("%3l:%c"))
(setopt mode-line-position-column-format '(" C%-3c"))

Steps to reproduce

Use settings

Expected behavior

Buffer position is represented with a stable length string that only has a discontinuity on column 1k and again at line 1k, "123:2 " etc. With content positioned afterward, it no longer jitters around wildly.

OS

Linux

Emacs Version

30

Emacs Configurations

No response

Error callstack

No response

Anything else

I played around with the new values, doom-modeline-position-line-format etc. The format spec ends up printing a lot of dashes, like "-----------------------------------------" whenever I use anything like "%3-c" on either column or mode line.

@psionic-k psionic-k added the bug Something isn't working label Dec 5, 2024
@seagle0128
Copy link
Owner

Did you try doom-modeline-position-comumn-format? doom-modeline doesn't respect mode-line-position-column-format, and it's as designed.

@psionic-k
Copy link
Author

Yeah, I set doom-modeline-position-column-line-format to ("%3l:%-3c") and it goes nuts.

This is with doom-modeline-position-line-format set to ("L%l") and doom-modeline-position-column-format set to ("C%c").

I have twiddled them to confirm which ones are even used with line-number-mode and column-number-mode etc. No combination will restore the old behavior. 3 is fine, not what I want, but fine-ish. -3 used to work but now does not.

@seagle0128
Copy link
Owner

There are no changes for this recently in doom-modeline, and the behaviors are exactly same as vanilla Emacs. I tried emacs -Q to check, and -3 doesn't work, either.

@psionic-k
Copy link
Author

The old configuration is not there by accident. I used it for many months.

In any case, it is currently wrong. We cannot actually use these specifiers because they don't respect any normal formatting directives.

@psionic-k
Copy link
Author

That's not really related. At the time, I believe doom read from the normal Emacs variable rather than re-declaring its own. The fact that I stopped at that configuration and had a working solution is proof enough that the support was there. It now is not.

I only use this customization when I use keycast, which I have to hack into doom mode line anyway. My hack is to advise the line position segment. Here we are.

Alternatively I would be more than happy to settle for a stable position for keycast output and to have keycast integration built in. At present I'm just duct taping them together because I can.

@seagle0128
Copy link
Owner

seagle0128 commented Dec 6, 2024

I didn't get the point. mode-line-position-column-format is never supported in doom-modeline, but you said it worked before. And in my env, -3 always shows many dashes, in both vanilla mode-line and doom-modeline. The new options are introduced in d739ab5, because the default values are different from the Emacs variables. As I said, it's as designed. At least Emacs variables aren't used so far. So I am confused.

@psionic-k
Copy link
Author

always shows many dashes

Now. I fixed this about a year ago. I don't disagree that behavior has changed.

Anyway, it doesn't work with format specifiers, and that is a problem that is requiring me to hack around to get a stable segment length so that my hacked on keycast isn't jumping around like a maniac. Keycast has to be last of leading part of the segments or else the key will be jumping around as the command lengths change.

@seagle0128
Copy link
Owner

seagle0128 commented Dec 6, 2024

Now. I fixed this about a year ago. I don't disagree that behavior has changed.

Can you please provide the commit? I will check if it can be merged.

Maybe you should make your own keycast segment to achieve?

@psionic-k
Copy link
Author

I fixed this by customizing options lol. There is no commit. It has just been this way in my config without incident until recently.

@seagle0128
Copy link
Owner

Then I have no idea. I even don't if it's an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants