vimpostor / vim-tpipeline

Embed your vim statusline in tmux
GNU General Public License v3.0
369 stars 11 forks source link

Doubled statusline with "sttusline" plugin #63

Closed avih7531 closed 8 months ago

avih7531 commented 8 months ago

Describe the bug

I'm getting both my native nvim statusline (sttusline) and then a recreation of it via vim-tpipeline which works perfectly, but the nvim status line stays.

To reproduce

Enter a new tmux session and go into nvim. See below for my config files

.tmux.conf

unbind r
bind r source-file ~/.tmux.conf

set -g prefix C-a

set -g mouse on

bind-key h select-pane -L
bind-key j select-pane -D
bind-key k select-pane -U
bind-key l select-pane -R

set -g focus-events on
set -g status-style bg=default
set -g status-left-length 90
set -g status-right-length 90
set -g status-justify centre

set -sg escape-time 0

set -g default-terminal "xterm-256color"

set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'catppuccin/tmux'
set -g @plugin 'christoomey/vim-tmux-navigator'

set -g @catppuccin_window_left_separator ""
set -g @catppuccin_window_right_separator " "
set -g @catppuccin_window_middle_separator " █"
set -g @catppuccin_window_number_position "right"

set -g @catppuccin_window_default_fill "number"
set -g @catppuccin_window_default_text "#W"

set -g @catppuccin_window_current_fill "number"
set -g @catppuccin_window_current_text "#W"

set -g @catppuccin_status_modules_right "directory session"
set -g @catppuccin_status_left_separator  " "
set -g @catppuccin_status_right_separator ""
set -g @catppuccin_status_right_separator_inverse "no"
set -g @catppuccin_status_fill "icon"
set -g @catppuccin_status_connect_separator "no"

set -g @catppuccin_directory_text "#{pane_current_path}"
run '~/.tmux/plugins/tpm/tpm'

sttusline setup via Lazy

return {
    "sontungexpt/sttusline",
    dependencies = {
        "nvim-tree/nvim-web-devicons",
    },
    event = { "BufEnter" },

    config = function()
        local mode = require("sttusline.components.mode")
        mode.set_config({
            modes = {
                ["no"] = { "DELETE", "STTUSLINE_DELETE_MODE" },
            },
            mode_colors = {
                ["STTUSLINE_VISUAL_MODE"] = { fg = "#cf9e40" },
                ["STTUSLINE_DELETE_MODE"] = { fg = "#df2020" },
                ["STTUSLINE_INSERT_MODE"] = { fg = "#a4aa4e" },
            },
        })
        require("sttusline").setup({
            statusline_color = "#242933",
            laststatus = 3,
            disabled = {
                filetypes = {
                    "neo-tree",
                    "lazy",
                    "No File",
                    "Mason",
                },
                buftypes = {
                    "terminal",
                },
            },
            components = {
                "mode",
                "filename",
                "git-branch",
                "git-diff",
                "%=",
                "diagnostics",
                "lsps-formatters",
                "copilot",
                "indent",
                "encoding",
                "pos-cursor",
                "pos-cursor-progress",
            },
        })
        vim.cmd("set noshowmode")
    end,
}

Expected behavior

That there would only be one status line which integrates neovim + tmux

Terminal emulator

Alacritty

Debug output

I did this in an empty buffer:

{'native_str': 'COMMAND  No File                                                                                                                                    NO LSP, FORMATTER 
avih7531 commented 8 months ago

I know the screenshot contradicts what I said, but it's because Hyprland treats screenshots as focusing on a different window. When in tmux and in the nvim pane the tpipline is the normal neovim one with the tmux additions. Still it demonstrates the two status lines: 20240329_00h31m38s_grim

avih7531 commented 8 months ago

Update: It is 100% a sttusline problem -- I just tried it with lualine and it was seamless.

Could this please be patched for sttusline in the future? Would love to help but have no idea where to start.

Thanks!

vimpostor commented 8 months ago

Could this please be patched for sttusline in the future?

Yes, but why are you opening the issue here and not in sttusline?

You can use :verbose set laststatus to see that sttusline is overwriting the laststatus option without any reason whatsoever, which causes the statusline to be displayed in vim again (hence you seeing two statuslines).

The reason is this line in sttusline.

This is probably the most idiotic code I have ever read in my life. You can grep sttusline for all usages of laststatus. They are literally just exposing an internal laststatus option for absolutely no fucking reason and then just set the vim laststatus option to the value of their own laststatus option, WTF why in the name of Jesus Christ would you do something unhinged like this, any sane user would just set vim's laststatus directly instead of using your fucking useless option. All you are accomplishing is breaking unrelated configs, because you hardcode laststatus to 3 for people that don't set your stupid internal option, even if they set the real laststatus inside their vimrc.

It is 100% a sttusline problem -- I just tried it with lualine and it was seamless.

Lualine did the same stupid shit and it is clear that the author of sttusline probably copied that practice from there (or used the garbage output of an LLM). Unfortunately I added a workaround just for lualine, which I now regret.

These statuslines should fix their shit upstream instead of letting other plugins add workarounds, because apparently all neovim plugin developers are incapable of using any vim-idiomatic APIs correctly.

For a quick hacky fix, you can use the workaround from this comment in the meantime. But ultimately statusline plugins should stop hardcoding laststatus for absolutely no fucking reason.

P.S.: Excuse my language, but this is the third time now, that this unnecessary kind of hardcoding breaks stuff, and it always takes time to debug where the problem is coming from, only to then realize in the end that my plugin is working correctly and neovim plugin developers are completely out of their mind.