feat: add Bison/Flex Navigation output channel for Show in Generated

[theodevelop]

Type of change

• Bug fix
• New feature
• Refactor / internal improvement
• Docs / config only

What does this PR do?

Fix bisonFlex.buildDirectory not resolved (client/src/lineDirectiveNavigation.ts)
The setting was used raw, causing ${workspaceFolder}/build, build/cobc and ../build/cobc to all fail silently. A new resolveSettingBuildDir() helper substitutes ${workspaceFolder} and resolves relative paths against the workspace folder before searching.
Add "Bison/Flex Navigation" output channel
Show in Generated File now logs every directory and candidate file searched, plus the resolved buildDirectory value. The panel opens automatically (focus preserved) on each invocation to ease debugging.

Related issue

Closes #27

How to test manually

1. Open a project with cobc/parser.y and a generated file in build/cobc/parser.c
2. Set bisonFlex.buildDirectory to "build/cobc", "${workspaceFolder}/build/cobc" or a relative path
3. Right-click in parser.y → Show in Generated File
4. Check Output → Bison/Flex Navigation for the resolved path and files searched

Checklist

• npm run compile passes with no new errors
• Tests added or updated (npx ts-node ...)
• Manual test done in VS Code
• CHANGELOG.md updated
• No unintended files staged (node_modules, .env, dist...)

[GitMensch]

I'm just a g... user - but maybe some of those thoughts are useful.

Side note: shouldn't there be some automated tests for that as well?

[GitMensch]

Not sure, but possibly if there is a code-workspace then this should be used as "root"?
claude says the code above works for all scenarios, but to have it relative to a code workspace one may use vscode.workspace.workspaceFile?.fsPath;

It's "practical example" (untested)

function getWorkspaceInfo() {
  const wsFile = vscode.workspace.workspaceFile;
  const folders = vscode.workspace.workspaceFolders;

  if (!folders || folders.length === 0) {
    // No folder or workspace open at all
    return null;
  }

  if (wsFile) {
    if (wsFile.scheme === 'untitled') {
      // Unsaved multi-root workspace (added folders via "Add Folder to Workspace"
      // but never saved the .code-workspace file)
      console.log('Unsaved workspace, first folder:', folders[0].uri.fsPath);
    } else {
      // Saved .code-workspace file
      console.log('Workspace file:', wsFile.fsPath);
      console.log('First folder:', folders[0].uri.fsPath);
    }
  } else {
    // Single-folder mode — no .code-workspace involved
    console.log('Folder mode, root:', folders[0].uri.fsPath);
  }
}

[GitMensch]

Drop that... a code-workspace can be stored anywhere = also outside of the workspace, so if that is used as a lookup for relative files then it can only be the last fallback.
Documenting that the first folder is used for that in multi-folder workspaces and using that is the right approach.

[theodevelop]

Agreed — added a doc comment to resolveSettingBuildDir explaining that folders[0] is intentionally used as the workspace root for all cases, and why workspaceFile is not suitable (a .code-workspace file can live anywhere outside the workspace folders).

[GitMensch]

That looks nice, but I've meant the buildDir configuration doc and/or README entry.

[theodevelop]

Blimey, I hadn't realised that lol. I've updated the README file.

[GitMensch]

Can this have a static var saving the last result along with the file name?
That would prevent the lookup (reading config, testing files and folders) to be done each time.

[theodevelop]

Done — added a module-level lastFoundCache keyed on (sourceFilePath, buildDirectory setting). On a cache hit the function returns early, before ch.show(true), so the output panel won't pop on repeated navigations to the same file. Only successful lookups are cached, so compiling between two invocations will still trigger a fresh search.

[theodevelop]

Thanks for the review, @GitMensch!

On the tests side note: findGeneratedFile depends on VS Code APIs (workspace.getConfiguration, workspace.findFiles, fs.existsSync), which can't be exercised with the current ts-node-based test infrastructure. Proper coverage would require setting up a VS Code integration test runner (@vscode/test-electron). I'll open a separate issue to track that.

[GitMensch]

🚀 docs are fine, debug output is really useful when not found and resolving the build directory works finally as well