Skip to content

Add Console and File Explorer as built-in open targets#21

Merged
seankearon merged 2 commits into
mainfrom
claude/folder-open-console-explorer-zghirm
Jun 28, 2026
Merged

Add Console and File Explorer as built-in open targets#21
seankearon merged 2 commits into
mainfrom
claude/folder-open-console-explorer-zghirm

Conversation

@seankearon

Copy link
Copy Markdown
Owner

Summary

Extends Fido with two new built-in open targets alongside editors: Console (opens a terminal at the resolved folder) and File Explorer (reveals the folder in the OS file manager). Both work cross-platform on Windows, macOS, and Linux with intelligent auto-detection of the OS defaults and full configurability.

Key Changes

  • New EditorKind enum values: Console and FileExplorer to represent the new target types
  • Refactored launch logic: Extracted LaunchSpec record to represent a planned process launch (program, arguments, working directory, shell-execute flag), making per-platform command construction testable without starting processes
  • Platform-specific implementations:
    • Console: Windows Terminal (wt) / PowerShell / cmd on Windows; Terminal app on macOS; x-terminal-emulator / gnome-terminal / konsole / etc. on Linux
    • File Explorer: explorer.exe on Windows; Finder via open on macOS; xdg-open on Linux
  • Smart terminal handling: Most terminals inherit the working directory; Windows Terminal gets an explicit -d <folder> flag since it ignores the inherited directory
  • Updated Editor.OpensFolderOnly: Now includes Console and FileExplorer alongside WebStorm, forcing folder mode and skipping the solution chooser
  • Configuration migration: Pre-v2 configs are automatically migrated to include the new targets (appended to preserve existing editor positions and default index)
  • UI updates: Added Console and FileExplorer to the editor kind dropdown in Settings; updated placeholders and documentation
  • Command-line support: New slugs term and files allow CLI invocation like fido feature/new-ui term or fido feature/new-ui files

Implementation Details

  • BuildLaunchSpec() is the pure core that constructs the launch plan per platform, enabling comprehensive unit testing without process execution
  • Console and File Explorer are treated as folder-only targets, always receiving the folder path rather than a .sln file
  • Both targets are configurable via the Settings UI (path field) with sensible OS defaults when left blank
  • Existing configs are migrated once on load; the new targets are appended (not inserted) to preserve user's existing editor order and default selection

https://claude.ai/code/session_018AFP3DvYu9aiaNvtbtnBjy

claude added 2 commits June 27, 2026 14:33
Fido can now open the resolved folder in a terminal or the OS file
manager, alongside the editors. Both are modelled as new EditorKinds
(Console, FileExplorer) so they reuse the whole open pipeline: a
secondary button, a Ctrl+1..9 shortcut, and a command-line slug
(`term` for the terminal, `files` for the file explorer). Both always
hand over the folder, never a .sln.

Cross-platform launch/locate:
- Console: Windows Terminal (-d) / PowerShell / cmd; macOS Terminal via
  `open -a`; Linux terminal emulators, opening in the working directory.
- File Explorer: explorer.exe; Finder via `open`; xdg-open / file managers.

The terminal and file-manager programs are configurable per row in
Settings (path blank = OS default). Launch command construction is
extracted into a pure, unit-tested BuildLaunchSpec.

Existing configs are migrated forward once on load (config version 2):
Console and File Explorer are appended to the editor list, preserving
order and the default pointer.

Docs (README, Features, CHANGELOG) updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AFP3DvYu9aiaNvtbtnBjy
Two bugs meant the Console target always opened cmd.exe on Windows:

1. A typed command name (e.g. "wt", "wt.exe", "pwsh") was ignored.
   Locate only honoured a path that existed verbatim on disk, so a bare
   command name failed File.Exists and fell back to auto-detection.
   Locate now resolves a bare command name on PATH (and the Windows
   Store-app alias folder, where wt.exe lives) before falling back.

2. Auto-detection preferred PATH-directory order over name order, so
   cmd.exe in System32 (early on PATH) beat wt.exe / powershell.exe in
   later directories. FindOnPath now tries names in the caller's
   preference order across all directories, so Windows Terminal /
   PowerShell win over cmd as intended.

Docs updated to note a command name (not just a full path) is accepted.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AFP3DvYu9aiaNvtbtnBjy
@seankearon seankearon merged commit d2ac020 into main Jun 28, 2026
2 checks passed
@seankearon seankearon deleted the claude/folder-open-console-explorer-zghirm branch June 28, 2026 07:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants