-
Notifications
You must be signed in to change notification settings - Fork 29.2k
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
Sweep setting descriptions for formatting consistency #54690
Comments
Remaining blocks:
I've assigned a random block of settings to everyone. Please review the settings for the block and check off your name when finished. Thanks!
|
@roblourens please reassign my block to someone else since I am on vacation form 8/25/2018. I can do it when I am back from vacation if it can wait some time. |
@roblourens should the |
Yes, does it not work for you? |
Yes and no. So as long as there is no search (filter) then the link works fine, but if you search, then the links just close the expanded setting -- even if the linked setting also meets the search criteria |
Good catch. I filed #55179 |
@roblourens How can I improve the label for a setting?
Edit: Another example is |
Need manual title:
|
Need manual title:
|
Typescript formatter settings are also very cryptic too me. Too many and repeating the title. |
I'm not convinced that any of these need manual titles. I want to avoid that if at all possible because I think having two names for every setting would be even more confusing than this already is, and I think we can still make the autogenerated names look nicer. @sbatten and I talked about this quite a bit on Friday too. "Ie hack"/"IE hack" I think it would be better to have a list of known acronyms that can be formatted correctly "Markdown.Preview: Breaks" - Settings are displayed in two ways, either in context under their section, "Markdown", or without context in a list of search results. In context where the section title is the same as the first setting component, the first component isn't shown. There's a bug with this in the extension section, but this should be shown as "Preview: Breaks" under the "Markdown" section, which I think is good. But then when the setting is shown in a list of search results, its label needs to include the full context, so "Markdown" must be included. I think "Markdown.Preview:" shows that there is this hierarchy of the "Preview" feature under the "Markdown" section. The display could be nicer, e.g. "Markdown > Preview:". But still, you should only see the context that's needed. @chrmarti I'm not sure what's wrong with those setting names - if the key itself isn't clear, I think we should fix that by having a good description or changing the setting entirely. But I think adding a new name for the same setting will cause issues. @isidorn I'm also not sure what name you would like to use. Fixing the duplication of @aeschli Yes I'd like to give extensions a way to define subcategories, like we have for builtin settings. re: I'm not sure what to do about the format settings. I think it's an issue beyond the settings GUI. Maybe all the descriptions are simply redundant. Of course it would be cool to have a special control that shows you a preview of what those settings do, or something like that. |
"scss.colorDecorators.enable" seems to have been removed from code |
As has "search.globalFindClipboard" |
Well they don't show up in the search |
Settings description update for #54690
Thanks everyone for the help! re: the conversation above, I'm happy to continue the discussion in another issue if anyone wants to. |
If you added a setting within the past couple weeks, please check that it also fits the guidelines, it might not be included in the list above. |
@JacksonKearl the colorDecorator settings are marked as deprecated and are therefore hidden (e.g. don't show up in the code completion for the settings.json). The Settings UI should still show them when set. I created #55646 |
Steps
something.contribution.ts
)Setting description rules
Ideally, enum settings should have a description and enum values clear enough that enumDescriptions aren't needed. But if the enum values aren't self-evident, enum settings should have enumDescriptions.
editor.cursorStyle
.An enum setting description should not duplicate info in the enumDescriptions (enumDescriptions will be rendered next to the description in both setting editors).
If enumDescriptions is specified, the length of enumDescriptions must match the length of enum. An empty string for an enumDescription is ok, if the value is self-evident. Example:
Enum values mentioned in a description must be in backticks with no quotes.
Note - if an enum setting has more than 10 options, its enum descriptions will be rendered inline inside the dropdown control (or in the old settings editor, only in the suggest widget). As far as I can tell, this only affects
files.encoding
.The text was updated successfully, but these errors were encountered: