Bug: branch component not displaying when opening files via snacks.nvim

[vaspadi]

Self Checks

• [ x] I'm using the latest lualine.
• [ x] I didn't find the issue in existing issues or PRs.

How to reproduce the problem

Install LazyVim (clean setup, no additional custom plugins).

• Open a git project (run git init in any directory).
• Open a file in a subdirectory using <leader><space> (subdir/file.lua).
• Check lualine — the branch component is missing.
• Open a file from the root directory (main.lua).
• The branch component is shown as expected.

Expected behaviour

The branch component should always be visible.

Actual behaviour

When using snacks.nvim (the default file opener in LazyVim) to open files, the branch component is only visible if the file is opened from the top-level directory. If a file is opened from a subdirectory, the component disappears. If I use files.mini to open files, the issue does not occur.

Minimal config to reproduce the issue

I was using a clean installation of LazyVim and hadn’t made any custom configurations yet when I encountered the bug. The lualine configuration is the default one provided by LazyVim.

Additional information

neovim: v0.11.3
OS: Windows 11 Home
snacks.nvim: bc0630e
lualine.nvim: a94fc68

After some debugging, I found that the issue is related to path separator inconsistency.

• snacks.nvim provides paths with / (Unix-style)
• mini.files provides paths with \ (Windows-style)

This causes issues in this line in git_branch.lua, specifically in the find_git_dir method (line 78):

local file_dir = dir_path or vim.fn.expand('%:p:h')

The path being passed to further logic doesn't match what Git or libuv expects on Windows, so the branch isn't detected properly.

I fixed it locally by forcing backslashes:

local file_dir = dir_path or vim.fn.expand('%:p:h'):gsub('/', '\\')

But I believe this is a workaround and not an ideal long-term fix.

I originally created the issue in the LazyVim repository: LazyVim/LazyVim#6308.

[a-usr]

The issue isn't that libuv doesn't expect the path seperators, libuv has no issues with using one or the other, or even mixing them. Instead the issue lies in the logic that attempts to move upwards in the directory to probe the super-directory for a .git folder:

lualine.nvim/lua/lualine/components/branch/git_branch.lua

Line 127 in b8c2315

root_dir = root_dir:match('(.*)' .. sep .. '.-')

[vaspadi]

@a-usr
It’s clear that we get the path separator corresponding only to our own OS, not another one or a mixed type.

lualine.nvim/lua/lualine/components/branch/git_branch.lua

Lines 11 to 12 in b8c2315

	-- os specific path separator
	local sep = package.config:sub(1, 1)

During debugging, I can see that in my case it’s \ (Windows). However, from snacks.nvim I’m receiving the / (Unix) separator.

snacks.nvim provides paths with / (Unix-style)

mini.files provides paths with \ (Windows-style)

[a-usr]

Both vim.fn.expand and vim.fn.fnamemodify reliably return paths that are separated Unix-Style using /, even on windows. Try it yourself! ...what

[a-usr]

Ok, but even then libuv has no issues with using either or both, this doesn't change the fact that the problem lies in the code that attempts to move the search upwards in the directory structure

[a-usr]

I just tested this by manually specifying the path using :edit, and for me expand always returns the path using Unix Path seperators

[vaspadi]

You’re either running macOS/Linux, or you have vim.o.shellslash = true set (which is false by default on Windows).

I tested this using :lua print(vim.fn.expand('%:p:h')) on different buffers, with vim.o.shellslash both enabled and disabled, and opening files via :edit, snack.nvim, and mini.files. Here’s what I found:

With vim.o.shellslash disabled, I always get backslashes in the path — except when using snack.nvim, which consistently returns forward slashes.

With vim.o.shellslash enabled, expand always returns forward slashes. However, lualine.nvim ignores this setting and continues to use the separator that matches the OS.

As a result, the git_branch component breaks and disappears.