Conversation
|
I'm also cross-validating this with the schema by moving these settings to settings.json and running the updated schema on it. Here's some interesting findings:
I can add "null" as acceptable via the schema and double check it serializes them properly by setting them in "profiles.defaults" then trying to unset them in my "profiles.list". But again, I want a "go-ahead" before I start doing that. |
|
Null is allowable for those. |
|
I like the changes if user feedback is a factor here. Use of null makes sense to me for those particular settings. You can always define those manually in
Yes.
This would prove helpful when configuring your own keybindings (instead of having to go to docs). Basically the |
zadjii-msft
left a comment
There was a problem hiding this comment.
- I like the format of using the
profiles.defaultslike this. - If it isn't terribly difficult to add the possible keybinding args too, that would probably also be appreciated.
| // If `profiles` was an object, then look for the `defaults` object | ||
| // underneath it for the default profile settings. | ||
| auto defaultSettings{ Json::Value::null }; | ||
| auto primaryDefaultSettings{ Json::Value::null }; |
There was a problem hiding this comment.
This is implemented in somewhat the wrong order. Right now we...
- Load defaults/profiles.list
- Apply defaults/profiles.defaults
- Apply user/profiles.defaults
- Load user/profiles.list
when what we really want is to swap 1 and 2.
There was a problem hiding this comment.
Yeah. This was a lot larger and more complex of a change than we hoped. Removed the code changes and opened #5276
|
Follow-up tasks:
I'll probably do them all as one PR. But I'll update this comment with the appropriate follow-up GH issues. |
sorry, what? absolutely not. |
Well, this one's annoying. So we have the { "command": "closeTab", "keys": null },but I'm not fond of it. |
|
FYI: I omitted adding the newTerminalArgs for |
|
This is an example of somewhere we definitely shouldn't violate our schema just to educate users about an option they almost certainly do not want to begin with. |
|
like, put that thing in a comment with a keys value and say it closes a whole tab without confirmation even if it has multiple panes in |
|
@DHowett-MSFT hmm, should I do the same with this then? There's no real value for a user to define them as null.
|
|
For those, there is. Cascading settings mean that they could be inherited from some other place, and they would need to be uninherited. |
e85da26 to
8914042
Compare
| // Miscellaneous | ||
| "confirmCloseAllTabs": true, | ||
| "theme": "system", | ||
| "rowsToScroll": "system", |
| "source": null, | ||
|
|
||
| // Experimental Settings | ||
| "experimental.retroTerminalEffect": false |
There was a problem hiding this comment.
so we're going with the "don't make any code changes, and hope that these match the compiled-in defaults forever" option?
There was a problem hiding this comment.
nope. Latest commit removed these. Unfortunately, if we have profiles as an object instead of a list, I think we just lose all of the profiles.defaults info. So, I've turned it back into a list.
Not happy about this change :/ but I'm still brainstorming a way to make it look prettier.
|
Should we put somewhere that |
|
If we consider it implicit that every tab contains a single pane by default, it is implied. |
|
I would argue people would assume there aren't any panes if they didn't split any. |
|
We should rename it to |
I think that's something worth mentioning. But defaults.json isn't the place for it. Definitely in the docs though. And the schema too, if it isn't in there already. |
| { "command": "find", "keys": "ctrl+shift+f" }, | ||
|
|
||
| // Tab Management | ||
| // "command": "closeTab" is unbound by default. |
There was a problem hiding this comment.
Should we bind this to something? This seems like basic functionality we should have a binding for.
There was a problem hiding this comment.
The windows "standard" is ctrl+f4, but be aware that it doesn't ask for confirmation and will destroy any number of panes worth of work.
There was a problem hiding this comment.
I mean, we don't ask for confirmation when you click the 'x' button on the tab now.
There was a problem hiding this comment.
You're right. I'm not saying it's more dangerous than the X button, just that it's as dangerous. If we litter minefields around folks' keyboards, like we once did with ctrl+w, there's a chance for DSAT. Not a huge one, just a chance.
There was a problem hiding this comment.
I'm personally ok with it being unbound be default. Mainly because there's other methods to close a tab (i.e.: exit, click X button, close pane, etc...)
There was a problem hiding this comment.
I'd prefer it to be bound to ctrl+f4. Every other command except unbound has a default binding.
There was a problem hiding this comment.
@cinnamon-msft and I had an offline discussion. We'll be holding off on ctrl+f4 being bound to close tab until we can get a confirmation dialog for closing the tab, if multiple panes are open.
follow-up work item: #5301
|
Any changes you make to this file please make sure you reflect to the universal file. Do remember the profiles differ 😄 |
Co-Authored-By: Dustin L. Howett (MSFT) <[email protected]>
|
Hello @carlos-zamora! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
🎉 Handy links: |
Summary of the Pull Request
This updates defaults.json to include the default values for all global and profile settings. Most default keybinding args are added too. This also updates a few outdated items found in the docs.
PR Checklist
Validation Steps Performed
After making the changes, I made sure all of the settings are deserialized by debugging and stepping through the
LayerJsoncode.I was mainly looking for two things: