-
-
Notifications
You must be signed in to change notification settings - Fork 198
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]: separator_visible is not used from the highlights for custom separator style #924
Comments
What I see from the behavior, is that
But in contrast the code actually generates 'thin' separators, means only one character between the tabs like
where This can be for example used to have the focused tab with an
I'm not sure this is what had been intended, and that can be changed by the following diff - meaning that the two custom characters are used one left and one right. diff --git a/lua/bufferline/ui.lua b/lua/bufferline/ui.lua
index 440b203..8424c8f 100644
--- a/lua/bufferline/ui.lua
+++ b/lua/bufferline/ui.lua
@@ -251,7 +251,7 @@ end
--- @param focused boolean
--- @param style table | string
local function get_separator(focused, style)
- if type(style) == "table" then return focused and style[1] or style[2] end
+ if type(style) == "table" then return style[1], style[2] end
---@diagnostic disable-next-line: undefined-field
local chars = sep_chars[style] or sep_chars.thin
if is_slant(style) then return chars[1], chars[2] end Regarding the 'wrong color', at least I see something that can count as 'wrong color'. |
@Finii thank you for taking time to reply with details. I know that the author of the plugin does not intend to provide full flexibility with custom separators, so I am not expecting this to be sorted. But I would be happy to open a PR if the author is willing. Otherwise, when I get a chance I will fork and update the code fix this issue regardless. |
Now I also read the previous Issue you linked. Well, what are these custom Ah, with
I can hardly imagine a useful setting for First with normal standard separators, where I adjusted the colors for easy identification: and with custom separators, they all turn red: Ok, this does not look good and seems like a bug. But what was the intention for the custom separator style. There is a comment in the And now all the behavior makes sense.
Well, at least for the active and the invisible tabs. The visible-but-not-active (number 4 in the image), this still looks strange. So I must admit, this is not a bug but the behavior is needed to support this one specific use-case that seemed to have driven the development of the custom separators. It's just not what I (and you and other) would have expected this feature to be for. :-D Edit:The code is really really old, just dove into Example archeological blame, see for example 1a1545b and cab12e4 |
@Finii that was a great analysis and you concluded very similar to what I had in mind. Technically things are working as intended if we go by the code and its comments. But based on how configuration is provided to a user, results are unexpected. I suppose this can be considered a limitation as intended by the author. |
Is there an existing issue for this?
Yes, but it was closed. #859
I understand that you do not want to provide full flexibility, however what is provided in the plugin should work consistently. The option with custom separators in
separator_style
is only about taking in left and right characters, the coloring of them should be the same as standard options like "slant".I am open to creating a PR for this.
What happened?
When configuring highlights
separator_visible
has no effect on separators set usingseparator_style = {'', ''}
. I did not find any reference to that parameter in the code when using individual separators.What did you expect to happen?
Plugin should respect
visible
,selected
for custom separators the same way it does for standard separator styles.Config
I am using LazyVim to load the plugin.
Additional Information
...
commit
Checked the main branch
The text was updated successfully, but these errors were encountered: