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

When using multiple windows, mode indicators currently just disappear when their windows are inactive #9878

Open
7ombie opened this issue Mar 15, 2024 · 7 comments
Labels
S-needs-discussion Status: Needs discussion or design.

Comments

@7ombie
Copy link
Contributor

7ombie commented Mar 15, 2024

I've mentioned this issue before (#9876), but I also suggested a solution (which was rejected), leading to the entire issue being closed.

This is the just issue.

@kirawi
Copy link
Member

kirawi commented Mar 15, 2024

This was mentioned in the comment I think:

modes do not exist per view and are global. This is intentional, it was different in the past and caused significant problems/bugs.

View is roughly equivalent to a buffer IIRC

@7ombie
Copy link
Contributor Author

7ombie commented Mar 15, 2024

I understand that modes are global, but the mode-indicator is per-window, and the indicator currently acts as though modes are per-window. The indicator disappears when its window loses focus.

It's not the modes (nor their global nature) that's the problem. It's the mode indicator, as a UI element.

@7ombie
Copy link
Contributor Author

7ombie commented Mar 16, 2024

I understand that modes are global...

To be fair, I should have said that I now understand that modes are global. I didn't really appreciate that when I opened #9876 (which was correctly rejected).


Thinking about this some more, the issue with the mode indicators seems to stem from the fact that the statusline is per-window, while the mode is global and the bufferline is (similarly) unified.

There's obviously a lot of benefit in retaining all of the current information about the buffers, available (as it is now) per-window (and this can only go in the statusline). However, the statusline could still be defined in terms of the overall state, without changing it very much in practice.

The main difference would be that the statusline would start with a single, unified mode indicator, followed by the information for each of the currently visible buffers, with each buffer's information spaced to left-align with the corresponding buffer above.

Note: Due to the mode indicator, the leftmost window would have the same amount of space (and information) as it does now, and any other windows would have half a dozen or more extra spaces (and no more information). The mode indicators are merged into one, and everything else slides left to realign.

Styles bound to ui.statusline and ui.statusline.inactive in the current themes could be reused to distinguish active-buffer-info from inactive-buffer-info (across the unified statusline).

@7ombie
Copy link
Contributor Author

7ombie commented Mar 16, 2024

You could even move the mode indicator to the bufferline (either top-left, immediately before the buffer-names, or top-right, on its own, at the very end of the bufferline), so the statusline always looks the same for each window.

@kirawi
Copy link
Member

kirawi commented Mar 16, 2024

To be clear, closing issues is about maintaining an organized tracker rather than shutting the door on further conversation. We've had several closed issues where conversation continued for a while, and some that were reopened.

@7ombie
Copy link
Contributor Author

7ombie commented Mar 17, 2024

@kirawi - No worries. Do you think I should close this issue? I'm happy to, if it helps.

@7ombie
Copy link
Contributor Author

7ombie commented Mar 20, 2024

If we agree that the issue with the mode indicators stems from the fact that the statusline is per-window, and that this is worth trying to fix, the effect on the existing APIs (configuration and theming) would need considering quiet deeply. I think it could plausibly be achieved without breaking anything, but you'd have to carefully repurpose parts of the existing APIs to make it work.

If you want to move this to a discussion, maybe that'd be better?? Whatever's best.

@kirawi kirawi added the S-needs-discussion Status: Needs discussion or design. label Apr 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-needs-discussion Status: Needs discussion or design.
Projects
None yet
Development

No branches or pull requests

2 participants