Use utils functions for path checks

[Davidyz]

(Hopefully) closes #291

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.72%. Comparing base (2c33375) to head (da41706).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #293   +/-   ##
=======================================
  Coverage   99.72%   99.72%           
=======================================
  Files          25       25           
  Lines        1838     1838           
=======================================
  Hits         1833     1833           
  Misses          5        5           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[minusfive]

@Davidyz errors are gone! Thank you!

When I set export VECTORCODE_NVIM_LOG_LEVEL=debug I do see similar messages as before being logged, but doesn't seem to affect anything?

Here's the full log in case there's something you want to keep poking at:

[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/config.lua:123: Received setup opts:
 {
  async_backend = "lsp",
  on_setup = {
    lsp = true,
    update = true
  }
}
[DEBUG Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/jobrunner/cmd.lua:14: cmd jobrunner for buffer 0 args: { "check", "config" }
[DEBUG Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/config.lua:51: Using vim.lsp.config.vectorcode_server for LSP config:
 {
  capabilities = {
    textDocument = {
      completion = {
        completionItem = {
          commitCharactersSupport = false,
          deprecatedSupport = true,
          documentationFormat = { "markdown", "plaintext" },
          insertReplaceSupport = true,
          insertTextModeSupport = {
            valueSet = { 1 }
          },
          labelDetailsSupport = true,
          preselectSupport = false,
          resolveSupport = {
            properties = { "documentation", "detail", "additionalTextEdits", "command", "data" }
          },
          snippetSupport = true,
          tagSupport = {
            valueSet = { 1 }
          }
        },
        completionList = {
          itemDefaults = { "commitCharacters", "editRange", "insertTextFormat", "insertTextMode", "data" }
        },
        contextSupport = true,
        insertTextMode = 1
      }
    },
    workspace = {
      fileOperations = {
        didRename = true,
        willRename = true
      }
    }
  },
  cmd = { "vectorcode-server" },
  name = "vectorcode_server",
  root_dir = "/Users/<user>/dev/personal/dot",
  root_markers = { ".vectorcode", ".git" },
  settings = {}
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/config.lua:143: Finished processing opts:
 {
  async_backend = "lsp",
  async_opts = {
    debounce = 10,
    events = { "BufWritePost", "InsertEnter", "BufReadPost" },
    exclude_this = true,
    n_query = 1,
    notify = true,
    query_cb = <function 1>,
    run_on_register = false,
    single_job = false,
    timeout_ms = 5000
  },
  cli_cmds = {
    vectorcode = "vectorcode"
  },
  exclude_this = true,
  n_query = 1,
  notify = true,
  on_setup = {
    lsp = true,
    update = true
  },
  sync_log_env_var = false,
  timeout_ms = 5000
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:63: Received codecompanion extension opts:
 {
  add_slash_command = true,
  add_tool = true,
  prompt_library = {
    ["Neovim Tutor"] = {
      file_patterns = { "lua/**/*.lua", "doc/**/*.txt" },
      project_root = "/opt/homebrew/Cellar/neovim/0.11.4/share/nvim/runtime"
    }
  },
  tool_group = {
    collapse = true,
    enabled = true,
    extras = { "file_search" }
  },
  tool_opts = {
    files_ls = {},
    files_rm = {},
    ls = {
      include_in_toolbox = true
    },
    query = {
      include_in_toolbox = true
    },
    use_lsp = true,
    vectorise = {
      include_in_toolbox = true
    }
  }
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/integrations/codecompanion/ls_tool.lua:18: Loading `vectorcode_ls` with the following opts:
{
  include_in_toolbox = true,
  requires_approval = false,
  use_lsp = true
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/integrations/codecompanion/common.lua:44: Using LSP runner for CodeCompanion tool.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:90: vectorcode_ls tool has been created.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/integrations/codecompanion/query_tool.lua:140: Loading `vectorcode_query` with the following opts:
{
  chunk_mode = false,
  default_num = 10,
  include_in_toolbox = true,
  max_num = -1,
  no_duplicate = true,
  requires_approval = false,
  summarise = {
    enabled = false,
    query_augmented = true,
    system_prompt = "You are an expert and experienced code analyzer and summarizer. Your primary task is to analyze provided source code, which will be given as a list of XML objects, and generate a comprehensive, well-structured Markdown summary. This summary will serve as a concise source of information for others to quickly understand how the code works and how to interact with it, without needing to delve into the full source code.\n\nInput Format:\nEach XML object represents either a full file or a chunk of a file, containing the following tags:\n- `<path>...</path>`: The absolute file path of the source code.\n- `<document>...</document>`: The full content of a source code file. This tag will not coexist with `<chunk>`.\n- `<chunk>...</chunk>`: A segment of source code from a file. This tag will not coexist with `<document>`.\n- `<start_line>...</start_line>` and `<end_line>...</end_line>`: These tags will be present only when a `<chunk>` tag is used, indicating the starting and ending line numbers of the chunk within its respective file.\n\nYour goal is to process each of these XML objects. If multiple chunks belong to the same file, you must synthesize them to form a cohesive understanding of that file. Generate a single Markdown summary that combines insights from all provided objects.\n\nMarkdown Structure:\n\n    Top-Level Header (#): The absolute or relative file path of the source code.\n\n    Secondary Headers (##): For each top-level symbol (e.g., functions, classes, global variables) defined directly within the source code file that are importable or includable by other programs.\n\n    Tertiary Headers (###): For symbols nested one level deep within a secondary header's symbol (e.g., methods within a class, inner functions).\n\n    Quaternary Headers (####): For symbols nested two levels deep (e.g., a function defined within a method of a class).\n\n    Continue this pattern, incrementing the header level for each deeper level of nesting.\n\nContent for Each Section:\n\n    Descriptive Summary: Each header section (from secondary headers downwards) must contain a concise and informative summary of the symbol defined by that header.\n\n        For Functions/Methods: Explain their purpose, parameters (including types), return values (including types), high-level implementation details, and any significant side effects or core logic. For example, if summarizing a sorting function, include the sorting algorithm used. If summarizing a function that makes an HTTP request, mention the network library employed.\n\n        For Classes: Describe the class's role, its main responsibilities, and key characteristics.\n\n        For Variables (global or within scope): State their purpose, type (if discernible), and initial value or common usage.\n\n        For Modules/Files (under the top-level header): Provide an overall description of the file's purpose, its main components, and its role within the larger project (if context is available).\n\nGeneral Guidelines:\n\n    Clarity and Conciseness: Summaries should be easy to understand, avoiding jargon where possible, and as brief as possible while retaining essential information. The full summary MUST NOT be longer than the original code input. When quoting a symbol in the code, include the line numbers where possible.\n\n    Accuracy: Ensure the summary accurately reflects the code's functionality.\n\n    Focus on Public Interface/Behavior: Prioritize describing what a function/class does and how it's used. Only include details about symbols (variables, functions, classes) that are importable/includable by other programs. DO NOT include local variables and functions that are not accessible by other functions outside their immediate scope.\n\n    No Code Snippets: Do not include any actual code snippets in the summary. Focus solely on descriptive text. If you need to refer to a specific element for context (e.g., in an error description), describe it and provide line numbers for reference from the source code.\n\n    Syntax/Semantic Errors: If the code contains syntax or semantic errors, describe them clearly within the summary, indicating the nature of the error.\n\n    Language Agnostic: Adapt the summary to the specific programming language of the provided source code (e.g., Python, JavaScript, Java, C++, etc.).\n\n    Handle Edge Cases/Dependencies: If a symbol relies heavily on external dependencies or handles specific edge cases, briefly mention these if they are significant to its overall function.\n\n    Information Source: There will be no extra information available to you. Provide the summary solely based on the provided XML objects.\n\n    Omit meaningless results: For an xml object that contains no meaningful information, you're free to omit it, but please leave a sentence in the summary saying that you did this.\n\n    No extra reply: Your reply should solely consist of the summary. Do not say anything else.\n\n    Merge chunks from the same file: When there are chunks that belong to the same file, merge their content so that they're grouped under the same top level header.\n"
  },
  use_lsp = true
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/integrations/codecompanion/query_tool.lua:374: Creating CodeCompanion tool with the following args:
 {
  chunk_mode = false,
  default_num = 10,
  include_in_toolbox = true,
  max_num = -1,
  no_duplicate = true,
  requires_approval = false,
  summarise = {
    enabled = false,
    query_augmented = true,
    system_prompt = "You are an expert and experienced code analyzer and summarizer. Your primary task is to analyze provided source code, which will be given as a list of XML objects, and generate a comprehensive, well-structured Markdown summary. This summary will serve as a concise source of information for others to quickly understand how the code works and how to interact with it, without needing to delve into the full source code.\n\nInput Format:\nEach XML object represents either a full file or a chunk of a file, containing the following tags:\n- `<path>...</path>`: The absolute file path of the source code.\n- `<document>...</document>`: The full content of a source code file. This tag will not coexist with `<chunk>`.\n- `<chunk>...</chunk>`: A segment of source code from a file. This tag will not coexist with `<document>`.\n- `<start_line>...</start_line>` and `<end_line>...</end_line>`: These tags will be present only when a `<chunk>` tag is used, indicating the starting and ending line numbers of the chunk within its respective file.\n\nYour goal is to process each of these XML objects. If multiple chunks belong to the same file, you must synthesize them to form a cohesive understanding of that file. Generate a single Markdown summary that combines insights from all provided objects.\n\nMarkdown Structure:\n\n    Top-Level Header (#): The absolute or relative file path of the source code.\n\n    Secondary Headers (##): For each top-level symbol (e.g., functions, classes, global variables) defined directly within the source code file that are importable or includable by other programs.\n\n    Tertiary Headers (###): For symbols nested one level deep within a secondary header's symbol (e.g., methods within a class, inner functions).\n\n    Quaternary Headers (####): For symbols nested two levels deep (e.g., a function defined within a method of a class).\n\n    Continue this pattern, incrementing the header level for each deeper level of nesting.\n\nContent for Each Section:\n\n    Descriptive Summary: Each header section (from secondary headers downwards) must contain a concise and informative summary of the symbol defined by that header.\n\n        For Functions/Methods: Explain their purpose, parameters (including types), return values (including types), high-level implementation details, and any significant side effects or core logic. For example, if summarizing a sorting function, include the sorting algorithm used. If summarizing a function that makes an HTTP request, mention the network library employed.\n\n        For Classes: Describe the class's role, its main responsibilities, and key characteristics.\n\n        For Variables (global or within scope): State their purpose, type (if discernible), and initial value or common usage.\n\n        For Modules/Files (under the top-level header): Provide an overall description of the file's purpose, its main components, and its role within the larger project (if context is available).\n\nGeneral Guidelines:\n\n    Clarity and Conciseness: Summaries should be easy to understand, avoiding jargon where possible, and as brief as possible while retaining essential information. The full summary MUST NOT be longer than the original code input. When quoting a symbol in the code, include the line numbers where possible.\n\n    Accuracy: Ensure the summary accurately reflects the code's functionality.\n\n    Focus on Public Interface/Behavior: Prioritize describing what a function/class does and how it's used. Only include details about symbols (variables, functions, classes) that are importable/includable by other programs. DO NOT include local variables and functions that are not accessible by other functions outside their immediate scope.\n\n    No Code Snippets: Do not include any actual code snippets in the summary. Focus solely on descriptive text. If you need to refer to a specific element for context (e.g., in an error description), describe it and provide line numbers for reference from the source code.\n\n    Syntax/Semantic Errors: If the code contains syntax or semantic errors, describe them clearly within the summary, indicating the nature of the error.\n\n    Language Agnostic: Adapt the summary to the specific programming language of the provided source code (e.g., Python, JavaScript, Java, C++, etc.).\n\n    Handle Edge Cases/Dependencies: If a symbol relies heavily on external dependencies or handles specific edge cases, briefly mention these if they are significant to its overall function.\n\n    Information Source: There will be no extra information available to you. Provide the summary solely based on the provided XML objects.\n\n    Omit meaningless results: For an xml object that contains no meaningful information, you're free to omit it, but please leave a sentence in the summary saying that you did this.\n\n    No extra reply: Your reply should solely consist of the summary. Do not say anything else.\n\n    Merge chunks from the same file: When there are chunks that belong to the same file, merge their content so that they're grouped under the same top level header.\n"
  },
  use_lsp = true
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:90: vectorcode_query tool has been created.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/integrations/codecompanion/vectorise_tool.lua:23: Loading `vectorcode_vectorise` with the following opts:
{
  include_in_toolbox = true,
  requires_approval = true,
  use_lsp = true
}
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:90: vectorcode_vectorise tool has been created.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:90: vectorcode_files_ls tool has been created.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:90: vectorcode_files_rm tool has been created.
[INFO  Wed Sep 24 10:09:14 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/codecompanion/_extensions/vectorcode/init.lua:107: Loading the following tools into `vectorcode_toolbox` tool group:
{ "vectorcode_ls", "vectorcode_query", "vectorcode_vectorise", "file_search" }
[INFO  Wed Sep 24 10:09:15 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/config.lua:98: Running `vectorcode update` on start up.
[INFO  Wed Sep 24 10:09:15 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/init.lua:150: vectorcode.update:  Expected value but found invalid token at character 1
[DEBUG Wed Sep 24 10:09:15 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/init.lua:155: vectorcode.update cmd args:  { "update" }
[DEBUG Wed Sep 24 10:09:15 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/jobrunner/cmd.lua:14: cmd jobrunner for buffer 10 args: { "update" }
[INFO  Wed Sep 24 10:09:29 2025] /Users/<user>/.local/share/nvim/lazy/VectorCode/lua/vectorcode/init.lua:161: Update result: "Expected value but found invalid token at character 3"

[Davidyz]

Neat. I'll merge this for now, and sort out the logging stuff in a separate PR if necessary. gotta admit, I'm still in the process of learning what to log (and also at what levels).