-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Unable to write to Workspace Settings because my.workspaceColor is not a registered configuration." / ability to access nested settings #42
Comments
You can create an empty extension to register the |
Could you provide a more clear example of what you're trying to achieve? |
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?
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 |
Yes, all the items in menus and command palette and settings, they are all static: Lines 57 to 67 in 7a13e71
|
Maybe it would be easier for you to create an extension (not an empty one) with the intended logic? |
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 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. |
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:
|
Would it be easier if variable substitution supported clipboard value? It's possible to do with vscode api. |
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 |
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. |
Right now it only replaces if the value is of type |
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. |
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! |
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? |
Closing. true/false/null should work. |
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
The |
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 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 |
You can try a new version. Change |
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 I saw in the API docs it does seem possible to get an |
Makes sense. You can try |
Well that was a quick turnaround - works perfect thanks again 👍 |
I was experimenting with the ideas discussed in #25, ie. using custom config settings to pass as variables to other commands (eg.
${config:my.workspaceColor}
). I've realised that while this works if I've added it to the json manually, it's impossible at the moment to add or update it via the extension - eg. the following sequence fails with the above notification:Is there any way to force an unknown configuration into settings? The second part of that sequence works as intended on its own, correctly reading the value of a manually-set
my.workspaceColor
into the specified settings. I also noticed the extension doesn't complain if I add my unknown config into a nested object. Thus, as an alternative I attempted:However I then realised it's not possible to grab a nested value from a
${config:...}
variable (I'd also initially tried${config:workbench.colorCustomizations.my.workspaceColor}
). Is there any syntax available to access such nested settings?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.The text was updated successfully, but these errors were encountered: