Show modified should render the results similar to a search

[ramya-rao-a]

Steps to Reproduce:

1. In the new settings editor, choose Show modified settings from the menu
2. Observe the results are rendered under their header and sub header instead of a linear result that is rendered when doing a simple search

vs

[roblourens]

Not sure, I think the structured view is better for browsing and looking for a certain setting, and the flat view is better for a search where the results are ordered by relevance, so the user should focus on the top one.

But, it might be nice if the TOC takes the filtered form with counts like during search.

[ramya-rao-a]

With the structured view, a lot of space gets taken up by the header and sub header which is helpful when looking at all settings, but get noisy when looking at a subset of settings.

In the former case, we would have multiple settings under a header/sub-header, so grouping makes sense.
In the latter case, we would most likely end up with a one or two settings under each header resulting in a lot of scrolling.

cc @Microsoft/vscode

[chrmarti]

Whether or not grouping makes sense depends on the number of settings that are modified. Maybe subsections with only 1 or 2 settings could be flattened out, aiming at best of both approaches.

[octref]

I'm actually on the opposite opinion: I very much want to see the headers / subheaders when searching. Seeing a flattened list of matches is disorienting. If it's not justified by that results are ranked by relevance, I would want the structured view.

[octref]

a lot of space gets taken up by the header and sub header which is helpful when looking at all settings, but get noisy when looking at a subset of settings.

On the other hand, they teach users which section each setting belongs to. I personally think 1st image looks fine.

[Tyriar]

In the bottom screenshot, why are the sections (before the :) inconsistent? For example Workbench: ... (1st level) vs Workbench.Settings: ... (1st and 2nd level) vs Update: ... (2nd level). Why not be consistent throughout?

Workbench.Workbench:
Workbench.SettingsEditor:
Application.Update: 
etc.

[roblourens]

@Tyriar Those are derived from the setting key, some have 2 components, some have more. Are you saying that we should pad it with a duplicated name to even them out? Workbench.Workbench:

[kieferrm]

In the first screenshot I have no indication of how many settings I have modified. I'd like to see this information. Also, I have always 2-3 headers before I get to the actual information. For me those headers are noise when I'm in a filtered list.

[Tyriar]

@roblourens well that could be just "Workbench", but my main point is that you don't know that "Update" is under "Applications" and "JavaScript.Format" is under "Extensions" (and TypeScript?).

[roblourens]

Oh got it, that's right that the category context is lost here. The user should be able to understand the setting without that, but it might be useful too.