Command line option to open multiple files into specific window tag

[SamHasler]

What problem would this solve?

I'd like to have several MarkPad windows open with files related by task in each window. If there are new files created for a task, or edits to files that aren't open yet, I'd like to open the files into the correct window from the command line.

What would you like?

MarkPad --tag "Task 1" C:\path\to\task-1\file1.md "C:\path\to\task-1\folder with spaces\file2.md"

MarkPad --tag "Task 2" "C:\path\to\task 2\file1.md" "C:\path\to\task 2\\file2.md"

If a window with the tag does not exist it would:

• open a new window and set it to use that tag.
• open the two files.
• have the first file in the list as the active tab/editor.

If a window with the tag does exist it would:

• Open the two files in the window, if they are not open already.
• Reload the files if they are already open.
• Switch the active editor in that window to the first file in the list.

Some kind of "flash" to show the tabs for the files might help the user find the files. (or the "<"/">" button(s) if not all the tabs are in view.)

---

You might also want to allow setting which view to start with:

MarkPad --tag "Task 1" --edit         C:\path\to\file1.md
MarkPad --tag "Task 1" --preview      C:\path\to\file1.md
MarkPad --tag "Task 1" --side-by-side C:\path\to\file1.md
MarkPad --tag "Task 1" --zen          C:\path\to\file1.md

and also allow setting/changing the tag color:

MarkPad --tag "Task 1" --color blue

Either open new window with no files and that tag/color, or change the color of the window with that tag.

What have you tried instead?

currently just running the command multiple times for each file and moving files between windows.

[PathGao]

I had a look at what this would cost against master (cebd94d). Notes rather than a patch — not something I'm picking up right now.

Most of the pieces are already in the tree.

what the request needs	what already exists
a window tag with a name and a colour	set_window_meta / is_window_tag_taken, tabManager.windowTag
tag → document set, persisted	pinned-tags.json, where each tag carries its own files
several windows, addressable individually	create_transfer_window, list_viewer_windows, bring_to_front
a second launch reaching the running process	tauri-plugin-single-instance
opening several files in one go	the startup path already loops: for (const path of args) await loadMarkdown(path)
"some kind of flash to show the tabs"	window-identify already flashes a badge on a window

So the work isn't the feature, it's three specific places:

1. startup_paths throws flags away. window_runtime.rs:528 filters on !arg.starts_with('-'). That is deliberate today — argv is the one unvetted path source and everything not path-shaped is dropped. Any of these options needs a real parser there first, and it has to keep answering the existing cases the same way.

2. handle_single_instance delivers one path, to the wrong window. window_runtime.rs:551 takes .into_iter().next() and emits it to whatever pick_delivery_window returns (focused, else last-focused). Routing by tag means resolving a target label out of window_registry — which already holds tag_name per window and is kept current by the frontend — and emitting the whole list rather than the head of it.

3. The new-window case is the one that isn't mechanical. When the tag names no open window, the window has to be built and then handed its files. Startup-file delivery today is process-global: AppState::startup_files, drained by send_markdown_path, and the frontend consumes it only when appWindow.label === 'main' — the comment there records why, letting every window consume it meant each detached window re-opened the file the app was launched with. Targeting a freshly built window needs delivery keyed by window label instead. That's a change to the channel's semantics, not an addition to it, and it's where the review time would go.

Two things worth settling before any of that:

Tag uniqueness. tag_held_by_another_window enforces one window per tag name, because pinned-tags.json is keyed by name alone and two windows sharing one silently overwrite each other's file list (#424 removed the concurrent form of that loss and deliberately said nothing about this one). Whatever --tag does when the name is already taken has to go through the same rule rather than around it.

Scope. The request bundles four things: --tag routing, the view flags, --color, and the flash. The view flags are close to free — OpenFileMode is already 'preview' | 'editor' | 'split' and zen is settings.zenMode, so they need an entry point and not a mechanism — but they don't have to ride along with the delivery-channel change. Landing the routing on its own keeps the part that alters existing behaviour reviewable by itself.

One more to check early rather than late: the examples here are Windows paths, and the command-line entry point for a macOS .app bundle behaves differently.