"Unable to write to Workspace Settings because my.workspaceColor is not a registered configuration." / ability to access nested settings about vscode-commands

[frypf]

Well that was a quick turnaround - works perfect thanks again 👍

[usernamehw]

No, it doesn't work with nested configuration in that way or maybe it's a workbench.colorCustomizations problem? I don't know.

Have you tried using Peacock or Profiles for this task?

[usernamehw]

You can create an empty extension to register the my.workspaceColor configuration. Then the update function (at least for that setting) would work.

[usernamehw]

PS: I was originally investigating all this as a workaround for using shell command substitutions as variables. If there was any way to read a command substitution directly into a variable - or even just access the current clipboard OR content from a specified tempfile OR environment variables from an open terminal, I could greatly simplify this or similar sequences by initially using a runInTerminal command to set clipboard via pbcopy / write said tempfile / export said env var. Albeit I don't know enough about TS and the available VSCode APIs to get a feel for how feasible or difficult any of that may prove to implement.

Could you provide a more clear example of what you're trying to achieve?

[frypf]

No, it doesn't work with nested configuration in that way or maybe it's a workbench.colorCustomizations problem? I don't know.
Have you tried using Peacock or Profiles for this task?

No worries I thought as much. I was simply using workbench.colorCustomizations as an arbitrary example as I knew I'd be overwriting it further down the sequence.

I was actually going through the new profiles functionality over the weekend, albeit I still wanted my colours to be different on a per-workspace basis. I'd also tried Peacock but I don't like how strict it is wrt to what UI elements are or aren't given colour. And tbh I was also just curious to see if this extension could work around it to allow me to uninstall something else - I already had pastel installed on my system and I've cut down a fair bit of extension bloat over the past few months thanks to yours!

The empty extension may be the way to go, at least then I could maintain a fairly minimal list of these types of custom variables. I'm guessing these have to be declared in the manifest rather than dynamically?

Could you provide a more clear example of what you're trying to achieve?

Anyway the end goal in this instance was simply to replace / hone the functionality already available via Peacock, although it got me thinking as ever about extensibility and whether the same logic could be applied to other situations. I had originally envisioned generating a random colour via pastel random -n 1 -s rgb | pastel format hex and reading that into an environment variable available for substitution later down the sequence, but that was where I fell into the above rabbit-hole once I realised I couldn't use command substitution in a more direct fashion.

[usernamehw]

I'm guessing these have to be declared in the manifest rather than dynamically?

Yes, all the items in menus and command palette and settings, they are all static:

vscode-commands/package.json

Lines 57 to 67 in 7a13e71

	"contributes": {
	"configuration": {
	"type": "object",
	"title": "Commands",
	"properties": {
	"commands.commands": {
	"type": "object",
	"description": "Main extension property. Commands that will be rendered in the View.",
	"scope": "application",
	"default": {}
	},

[usernamehw]

Maybe it would be easier for you to create an extension (not an empty one) with the intended logic?

[frypf]

I may end up doing so, or just cludging together something with jq on the command line if I can figure out a way around any json comments and trailing commas without stripping them altogether. Or actually maybe just writing a tempfile with the command result, setting the appropriate settings to some temporary placeholder value and then running another runInTerminal to replace that value via sed might be simpler - your empty extension idea has got me thinking of just using a temporary-type ${config:...} variable as a means to store something quickly for the duration of a command sequence. Would there be any scope for adding such a temp variable(s) to this extension? I can only envisage needing 1 in this case as I'd then empty it after use at the end of a sequence, although maybe you can see a more generalised use case for having more available?

I remember a while back I tried to get my head around using a command substitution as a variable for something else after reading https://code.visualstudio.com/docs/editor/variables-reference#_command-variables, but came to the conclusion it wasn't possible, or at the very least not simple. I was just wondering again today if there was any way of harnessing the flexibility of your extension to take out the middle man, so-to-speak.

[frypf]

Think I managed to work it out in the end - took a while to figure out the quoting to keep the workspace json nicely formatted but still allow easy undoing in minimal steps. Thanks for pointing me in the right direction:

"cmd.workspace.randomColor ": {
  "sequence": [
    {
      "command": "commands.runInTerminal",
      "args": {
        "text": " pastel random -n 1 -s rgb | pastel format hex >| '/tmp/VSCODE_TEMP_VAR'",
        "name": "cmd.workspace.randomColor"
      }
    },
    {
      "command": "commands.toggleSetting",
      "args": {
        "setting": "workbench.colorCustomizations",
        "target": "workspace",
        "value": [ "<<VSCODE_TEMP_VAR>>" ]
      }
    },
    {
      "command": "workbench.action.terminal.sendSequence",
      "args": {
        "text": " vscode_temp_var=\"$( cat '/tmp/VSCODE_TEMP_VAR' )\" && col_cust=\"{\\n\\t\\t\\t\\\"statusBar.background\\\":\\\"${vscode_temp_var}33\\\",\\n\\t\\t\\t\\\"titleBar.activeBackground\\\":\\\"${vscode_temp_var}33\\\",\\n\\t\\t\\t\\\"tab.activeBackground\\\":\\\"${vscode_temp_var}33\\\",\\n\\t\\t\\t\\\"sideBar.background\\\":\\\"${vscode_temp_var}33\\\"\\n\\t\\t\\t}\" && sed -i '' -e \"s/\\\"<<VSCODE_TEMP_VAR>>\\\"/${col_cust}/\" '${file}' ; rm '/tmp/VSCODE_TEMP_VAR'; exit\n"
      }
    },
  ],
  "when": "editorFocus && resourceExtname == .code-workspace"
}```

[usernamehw]

Would it be easier if variable substitution supported clipboard value? It's possible to do with vscode api.

[frypf]

Ooh, actually yes that would probably help a lot. The sequence I posted above does work, albeit it's a bit janky & slow. If I could access the clipboard directly, it'd just be a matter of piping the initial shell command into pbcopy and then I could hopefully bypass the placeholder value and extra terminal.sendSequence sed call altogether. It would also potentially simplify any other use cases where I need to pass in a shell result. Thanks for your help mate, I appreciate this kind of functionality is probably not what you'd originally envisaged, but as I said before your extension has come in truly useful in some fairly varied and unexpected situations.

[frypf]

No, it doesn't work with nested configuration in that way

Just to revisit accessing settings within nested objects again, is this a VSCode API limitation or would it be possible to return such objects/arrays as a stringified JSON? We could then parse out the required part(s) ourselves in the shell via jq or sed or similar.

[usernamehw]

Just to revisit accessing settings within nested objects again, is this a VSCode API limitation or would it be possible to return such objects/arrays as a stringified JSON?

Right now it only replaces if the value is of type string or number (not vscode limitation). I would need to change the code to return stringified value if it's an array or an object.

[frypf]

Ah I see, just had a quick look at substituteVariables.ts. Would there be any scope for adding additional recursion in there for config-type variables if a property key were given in square brackets, failing with a similar notification if no such key was given? Or would that require too much refactoring / break functionality elsewhere? If it's feasible, between that and the proposed clipboard access as a variable, it would allow for some seriously granular access to and control over individual sub-settings more generally.

[usernamehw]

Clipboard is relatively easy to do 6925d40.
Returning stringified objects/arrays should be too aab3262.

Walking recursively for settings - no plans.

[frypf]

I figured that wouldn't make for a simple change, although tbh even accessing a stringified representation would still allow for some awesome new possibilities. Looking forward to trying out the clipboard functionality once the marketplace picks up the latest commit, thanks again!

[frypf]

Oh, apologies for nagging with multiple (albeit hopefully related) requests, but I've just noticed config retrieval also fails for boolean/undefined values - is it possible to account for those as a simple true|false|null?

[usernamehw]

Closing. true/false/null should work.

[frypf]

Thanks for this, I've tested it a bit and it's definitely a lot smoother than my previous janky sed/placeholder attempt.

Unfortunately I've noticed an issue: when I actually come to use ${clipboard} within toggleSetting it only ever populates with the value of the clipboard as it was at the last window reload (or the last time I made some change to the cmd.workspace.randomColor command/sequence itself within my settings json). I've added a couple of checks to the following sequence just to try to see what was going on:

"cmd.workspace.randomColor ": {
  "sequence": [
    {
      "command": "commands.runInTerminal",
      "args": {
        "text": " pastel random -n 1 -s rgb | pastel format hex | tr -d '\\n' | pbcopy; printf -- '%s\\n' '${clipboard}' >>| vsc_cmd_cb_test",
        // "text": " printf -- '#%s' $( LC_ALL=C tr -dc 'a-f0-9' < /dev/urandom | head -c 6 ) | pbcopy; printf -- '${clipboard}\n' >> cb_test",
        "name": "cmd.workspace.randomColor",
        "reveal": true
      }
    },
    {
      "command": "commands.showStatusBarNotification",
      "args": { "timeout": 2500, "message": "${clipboard}" },
    },
    {
      "command": "commands.toggleSetting",
      "args": {
        "setting": "workbench.colorCustomizations",
        "target": "workspace",
        "value": [ {
            "statusBar.background": "${clipboard}33",
            "titleBar.activeBackground": "${clipboard}33",
            "tab.activeBackground": "${clipboard}33",
            "sideBar.background": "${clipboard}33",
          } ]
      }
    },
  ],
  "when": "editorFocus && resourceExtname == .code-workspace"
},

The ${clipboard} var is definitely being updated by the initial runInTerminal piping into pbcopy, and the extension is definitely seeing the updated value. Both the vsc_cmd_cb_test file & the showStatusMessage correctly show the updated value, but for whatever reason, the setting itself never receives anything other than the old value. Any idea what might be going on here?

[frypf]

Actually I've just noticed that sometimes the workspace just turns bright red (I'm guessing #ff0000 is a fallback value if VSCode can't interpret the given string as a colour). This happens when I have some other string already in the clipboard at the time I reload the window or change the command in settings, which is what then gets populated. It's like it's evaluating ${clipboard} at the time the extension loads, but only when used in toggleSetting - everything else seems to interpret it at the time of invocation 🤔.

UPDATE: I've realised after checking my clipboard history that the value being written to file and shown in the status bar is actually the previous clipboard value - I had wondered if there might be some issue with concurrency. However, if I add a delay of 333ms to showStatusMessage it then consistently displays the updated value, whereas doing the same for toggleSetting still only gets the old value.

[usernamehw]

You can try a new version. Change .zip to .vsix & run Install from VSIX commands-1.8.0.zip

[frypf]

Seems to have done the trick thanks, it's evaluating correctly now. Is there any way around the timing issue beyond hardcoding a delay into the command where I use the clipboard? Maybe a way to make runInTerminal optionally await completion via a non-default option within the JSON?

I saw in the API docs it does seem possible to get an exitStatus back from a terminal once it's closed. Maybe if the runInTerminal was specified with eg. "waitForCompletion": true, then append an "\n exit $?" to its text to make sure it closes itself once done and return a promise which resolves or rejects according to said exitStatus?

[usernamehw]

Makes sense. You can try "waitForExit": true in commands-1.8.0.zip