Allow to specify options for a an arg

[pomdtr]

Raycast has an super useful feature I am not able to replicate in kit.

By hitting the cmd+k shortcut, you are able to provide a list of options for the selected item. However, you can also trigger the main action (opening the file) by just using the enter key. Alfred also provide this feature in the file view using the right arrow key.

I propose this syntax to replicate the feature in kit:

const { title, option } = arg(
  {
    placeholder: "select task",
    options: [
      { title: "edit", description: "edit task", shortcut: "enter" },
      { title: "delete", desription: "delete task", shortcut: "cmd enter" },
    ],
  },
  ["buy milk", "create issue for kit"]
);


if (option == "edit")
   edit_task(title)
else if (option == "delete")
    delete_task(title)

Using the right arrow key, you would list the available options. But you can trigger an option directly with the keyboard shortcut.

It seems the closer alternative in kit is tabs, but I feel like it complicates both the dev experience and the user experience quite a bit. It seems more logical to me to select a task and then select an action.

[johnlindquist]

I was wondering when someone would bring this up 😇

I'm AFK today, but I'll type up what it will look like tomorrow. We should be able to keep it really simple 😊

[johnlindquist]

The concept of an "action" or "context menu" in a UI doesn't really exist when thinking about running a script in a terminal.

The closest concept we have is "flags", e.g., --open, --edit which are boolean values that default to false/undefined.

Flags are already supported (although I've never talked about it) in Script Kit as they're just named booleans on arg:

// testing-flags
let value = await arg("Some file")

if (arg?.open) {
  console.log(`Open ${value}`)
} else {
  console.log(`${value}`)
}

testing-flags pizza.js --open

Note: Looks like "flags first" is broken, I'll get that fixed... 😅

# This is broken:
testing-flags --open pizza.js

Script Kit uses lazy args. If an arg is missing, you'll be prompted for it.

Conversely, we never prompt for flags. We assume false unless provided.

Making the UI flag-aware

It seems more logical to me to select a task and then select an action.

☝️ I agree, in some cases. So we need a way for the user to inject a flag while the script is already running.
So what would does this look like?

// A function which immediately sends flag options to the UI
flags({
  open: {
    shortcut: "cmd+o",
  },
  edit: {
    shortcut: "cmd+e",
  },
})

When the script runs, now the UI would know there are some options/flags for the script. The big difference between Script Kit and other tools is that these are script options (not arg options).

"Submit" a flag

In the UI, a user would expect to right-click on a list item or press a keyboard shortcut to see "options".

So we can do this: if a user right-clicks or presses a shortcut, then prompt for flags. When submitting a flag, we can submit both the flag and the currently selected value. Then the script would continue and you could use the value and flags however you wanted:

// Makes the UI aware of available flags, but doesn't prompt unless user requests
flags({
  open: {
    shortcut: "cmd+o",
  },
  edit: {
    shortcut: "cmd+e",
  },
})

let value = await arg("Some file")

// If the user submit a flag, then Kit internals will toggle these to `true`
if (flags?.open) {
  console.log(`Open ${value}`)
} else {
  console.log(`${value}`)
}

This should feel like the same experience from Raycast/Alfred, just conceptually different.

run with flags

Script Kit allows you to run scripts from other scripts. Using flags looks like this:

await run("testing-flags", "--open")

This would still prompt for a value, but the flags.open would be true.

In progress...

I'm pretty convinced that "this is the way". I know "arg options" is appealing from a UI standpoint, but "script flags" makes much more sense to me in the context of Script Kit goals: Running in the terminal, running in webhooks, etc.

I'll keep the UI simple, just a list. The internal changes should be fairly straightforward as well. It just may take a week or two to put all the pieces together.

[pomdtr]

Thanks for the detailled answer, I really love your focus on scripts interoperability.
I'm also feel like it is the way to go. If I want to have a flag "attached" to a secondary arg, I would always have the possibility to isolate the logic in a single script and call the run method from the main script.

[pomdtr]

You implementation proposal kind of reminds of the lazycli utility : https://github.com/jesseduffield/lazycli
I quite like the user experience of selecting the command/flag in cli context.