Linux port: open a file named on the command line, not just a folder - #2
Open
e-c-hansen wants to merge 1 commit into
Open
Linux port: open a file named on the command line, not just a folder#2e-c-hansen wants to merge 1 commit into
e-c-hansen wants to merge 1 commit into
Conversation
`minicode notes/todo.md` ignored the file and opened the current directory instead, so the only way to get at a file was to pass its parent folder and then click. argv[1] now accepts either: a directory becomes the sidebar root as before, and a file is opened in the editor with the sidebar rooted at the directory holding it, so its neighbours are still listed. Markdown arrives rendered, because this goes through the same openFileCb a sidebar click does. Passing the file was only half of it. GApplication is single-instance, so a second `minicode <path>` typed while a window was already open handed off to the running process and dropped the argument on the floor: the command did nothing at all, which is the state most people are in, since the editor tends to stay open. Registering HANDLES_COMMAND_LINE and reading argv in the command-line handler fixes that — the running instance re-roots its sidebar, opens the file and raises its window. HANDLES_OPEN would have been the shorter route but it insists on treating the argument as a file, and a directory has to keep working. Two details that only show up in the remote case. The path is resolved against the cwd reported by the command line object rather than getcwd, or a relative `../thing` would be resolved against the cwd of whichever process happens to own the window. And "no such file or directory" goes out through g_application_command_line_printerr, so it lands on the terminal the user typed in instead of the stderr of that other process. A path that does not exist still opens the sidebar on its parent, so a mistyped filename lands in the right folder. Verified on a private session bus: a directory as the first launch, a relative file path from a second invocation resolving correctly against the caller's cwd, a directory from a second invocation re-rooting, and a missing path reporting to the caller. The macOS build has the same gap (src/main.mm only accepts a directory) and is untouched here, since it cannot be built or tested from this machine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
minicode notes/todo.mdignored the file and opened the current directory instead, so the only way to reach a file from a shell was to pass its parent folder and then click.What changed
argv[1]now accepts either form:Markdown arrives rendered, because this goes through the same
openFileCba sidebar click uses.The half that was easy to miss
Passing the file was only part of the problem. GApplication is single-instance, so a second
minicode <path>typed while a window was already open handed off to the running process and dropped the argument entirely — the command did nothing at all. That is the state most people are in, since the editor tends to stay open.Registering
HANDLES_COMMAND_LINEand reading argv in the command-line handler fixes it: the running instance re-roots its sidebar, opens the file, and raises its window.HANDLES_OPENwould have been shorter but it insists on treating the argument as a file, and a directory has to keep working.Two details only show up in that remote case:
getcwd, or a relative../thingwould resolve against the cwd of whichever process owns the windowno such file or directorygoes out viag_application_command_line_printerr, so it lands on the terminal the user typed in rather than the other process's stderrA path that does not exist still opens the sidebar on its parent, so a mistyped filename lands in the right folder.
Verification
On a private session bus: a directory as the first launch; a relative file path from a second invocation resolving correctly against the caller's cwd; a directory from a second invocation re-rooting; and a missing path reporting back to the caller. Launching with a Markdown file argument stays alive and renders.
meson testpasses.BUILD-LINUX.mdis updated, including the "Sudden second copy of the app?" section that documented the old limitation.Not included
The macOS build has the same gap —
src/main.mmonly accepts a directory — and is untouched, since it cannot be built or tested from a Linux machine. Worth a follow-up from a Mac.Sidebar selection is also not included: the tree is backed by
GtkDirectoryList, which enumerates asynchronously, so revealing and selecting the opened file reliably is more than this change needs.🤖 Generated with Claude Code