Add ability to enter custom prompts before running custom commands

[idursun]

I think that the only thing missing for me is being able to query the user for custom input to these custom commands. E.g., I would like to create a custom command to create a new bookmark for the current revision. The command should support bookmark set --revision $change_id $inputs.bookmark_name where $prompts is an array of user inputs specified in the custom command, and the .bookmark_name is the specific user input with the value inserted by the user when invoking the custom command through an interactive text field. Something like:

[custom_commands]
"new bookmark" = { 
  key = ["ctrl+b"], 
  args = ["bookmark", "set", "--revision", "$change_id", "$prompts.bookmark_name"],
  prompts = [ {id = bookmark_name, type = "text", title = "Name of the new bookmark"} ]
}

The prompts.type could be selecting from a menu (with filtering support), inputting a custom text, ...

Similarly to what Lazygit does with prompts:

  - key: 'n'
    context: 'localBranches'
    prompts:
      - type: 'menu'
        title: 'What kind of branch is it?'
        key: 'BranchType'
        options:
          - name: 'feature'
            description: 'a feature branch'
            value: 'feature'
          - name: 'hotfix'
            description: 'a hotfix branch'
            value: 'hotfix'
          - name: 'release'
            description: 'a release branch'
            value: 'release'
      - type: 'input'
        title: 'What is the new branch name?'
        key: 'BranchName'
        initialValue: ''
    command: "git flow {{.Form.BranchType}} start {{.Form.BranchName}}"
    loadingText: 'Creating branch'

Originally posted by @Adda0 in https://github.com/idursun/jjui/discussions/63#discussioncomment-12988811

[vic]

Since I've been recently digging in the source code, I'd like to work on this. However, before doing so, I will be thinking and getting back to you on a proposed design for this. (designing is part of working on it)

I understand the use-case for having prompts and the value they add for custom-commands.

However, given that custom-commands are user defined, and we can't possibly control what they do, why not just let custom-commands be user-configured names (and keys) for command-lines that can be run via our new ExecShell.

Because people could be using gum to write tiny scripts that prompt for things as part of their script. And they would totally work with our ExecShell yielding stdio into the user script. This way we don't even have to implement prompts, just instruct people to use gum and let custom-commands be named (and key-bound) ExecShell scripts.

What do you think ?

[vic]

We could have people share tiny gum scripts for use in jjui via gists on a wiki page, or something. and people is responsible for what their custom-commands do (just like they are responsible if they wanted to run $ shutdown via exec).

So (for now) I believe we should not implement a framework for UI prompts.

[vic]

Your original example

[custom_commands]
"new bookmark" = { 
  key = ["ctrl+b"], 
  args = ["bookmark", "set", "--revision", "$change_id", "$prompts.bookmark_name"],
  prompts = [ {id = bookmark_name, type = "text", title = "Name of the new bookmark"} ]
}

can be written today as:

[leader.bn] # bookmark new
help = "Set new bookmark"
send = [ "$", "jj bookmark set -r $change_id $(gum input --placeholder \"Name of the new bookmark\")", "enter" ]

The only difference is it is being part of Leader's keymap tree \ and being executed via $ with full stdio given to it. Instead of how x custom-commands are executed now.

And if #186 gets merged, people don't need to have large command lines on their configs, the user script can be some executable on their filesystem and can still access context values like $change_id.

The only thing I believe is worth having is context an attribute that indicates where the command is available (is it available when selected item is a file ? or over a revision ? etc). This would be something worth having for Leader entries as well: this edit-file leader key should be only available when selecting a file on details view.

[jscarrott]

Since I've been recently digging in the source code, I'd like to work on this. However, before doing so, I will be thinking and getting back to you on a proposed design for this. (designing is part of working on it)

I understand the use-case for having prompts and the value they add for custom-commands.

However, given that custom-commands are user defined, and we can't possibly control what they do, why not just let custom-commands be user-configured names (and keys) for command-lines that can be run via our new ExecShell.

Because people could be using gum to write tiny scripts that prompt for things as part of their script. And they would totally work with our ExecShell yielding stdio into the user script. This way we don't even have to implement prompts, just instruct people to use gum and let custom-commands be named (and key-bound) ExecShell scripts.

What do you think ?

Just FYI I came across this issue looking to do this exactly - I want to run a tiny script that uses gum to help write a conventional commit message. Exec shell seems like exactly what I want. So for now I if I grab the current dev version I run : my-script $change_id and in the future this can be configured with a shortcut?

[vic]

hey, you can already bind any exec shell (or anything you can type directly on jjui) see our Leader page in the wiki, sorry for not providing a link I'm on mobile now :)