Square brackets in directory names disable changing working directory.

[strongmove]

Problem

Landing on a file whose path includes a paired square brackets are being ignored by the project.nvim plugin.

Example

/path/to/file/includes/[bracket]/test.py

Relevancy & Context

This is relevant for people working with Next.js as this kind of directory structure is enforced when using the new standard app router.

.
└── [id]
    └── page.tsx

Technical details

When landing on a buffer, project.nvim calls M.on_buf_enter() and validates the path. https://github.com/ahmedkhalf/project.nvim/blob/8c6bad7d22eef1b71144b401c9f74ed01526a4fb/lua/project_nvim/project.lua#L243-L246

The existence of the path is checked using glob. https://github.com/ahmedkhalf/project.nvim/blob/8c6bad7d22eef1b71144b401c9f74ed01526a4fb/lua/project_nvim/utils/path.lua#L33-L35

Glob treats paired square brackets as some kind of regex pattern instead of string literal for the purpose of search. When the path to the buffer contains squared brackets (or other special patterns used by glob), the results are either unexpected or silently ignored.

For my purposes dealing with square brackets for Next.js projects, I've changed my local code to escape them like the following, and it works well.

function M.exists(path)
  local escaped_path = path:gsub("%[", "\\["):gsub("%]", "\\]")
  return vim.fn.empty(vim.fn.glob(escaped_path)) == 0
end

Of course the problem is when project.nvim wants to use glob pattern. In that case, I suggest providing an option (either as global config or per-project) to treat the path string as string literal.

[cabbage]

Why is the current buf's file path even passed through vim.fn.glob? I assume that's an absolute path and therefore shouldn't be expanded, or am I missing something?