Script file ”front matter” / config

[PEZ]

If we find a low-friction way to provide configuration/information about the script, in the scripts themselves, this could be used for things like:

• Augment the scripts menu (or even replacing the script path with a string)
• Provide info that Joyride can use to bind some pre-declared/booked keyboard shortcuts (or, if What if Joyride could contribute commands and configuration etcetera? #14 can be implemented, any keyboard shortcut)
• More...

Some ideas for how to provide such info:

• A line comment before the ns form.
• An ignored map in before the ns form
• A line comments anywhere in the file, with some special syntax to mark it as ”front matter”
• An ignored map anywhere in the file, with some special key, like:

  #_{:joyride {:chord "i", :label "Ignore current form”}}

• ...

Predeclared keyboard shortcuts are used by Calva for it's custom REPL Command Snippets as a way to compensate for that it can't declare commands at run time.

[borkdude]

Another option could be a workspace or global config file which contains an index of the scripts that should show up in the menu along with the label / title (I prefer title I think) and key bindings. That would also solve the problem of what files we should not show in the menu if they only contain utility functions. Another problem that would solve is that you could specify which function should be invoked and which arguments should be put into those functions.

index.edn:

[{:chord "i", :title "Ignore current form", :fn ignore-form/main :args [1 2 3]}]

This will likely also be faster to parse on startup than having to traverse a directory with files and read the front matter from those.

[PEZ]

I like the idea with an index.edn. I want it to work such that if you don't provide a config for a file then it is displayed plain as it is now. This can probably be achieved with this central config too. Just noting.

I also have very good experience with ”front matter” style config, since it keeps it together with the thing it configures. If it is mostly a performance concern can probably use a vscode.FileSystemWatcher. And keep an index updated.

[borkdude]

I'm more concerned about startup time: you have to maintain that index in every workspace you start with VSCode. I think it's best if our plugin started as fast as it could and did as little as possible. Opening and reading files isn't free, parsing the individual configs needs good error handling. Having the config in a separate file allows you to control the order in the menu and would also allow you to create a clj-kondo config linter for it. I don't like putting things before the namespace form in a Clojure file, it seems a bit messy to me, but that could just be a matter of getting used to it.

[PEZ]

Makes sense.