Skip to content
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

[Code Style] Give users more control over the visual treatments of each option #13963

Closed
dpoeschl opened this issue Sep 21, 2016 · 3 comments
Closed

Comments

@dpoeschl
Copy link
Contributor

dpoeschl commented Sep 21, 2016

On the Code Style page today, we allow users to choose their style choice and their severity.

image

It would be nice if they could also control the "visual treatment" (working title) of each. Examples include

  1. Inclusion in the Error List
  2. Presence of the "..." or squiggle indicators
  3. Fading out of non-compliant code
  4. Inclusion in the scroll bar

Another open question is whether this level of control should apply to only things on the Code Style page, or all analyzers.

@dpoeschl
Copy link
Contributor Author

Based on conversation with @CyrusNajmabadi @Pilchie @DustinCampbell @kuhlenh

@CyrusNajmabadi
Copy link
Member

Here's an idea:

The code style page currently has 2 columns. One for preference and one for severity. I could imagine a 3rd column. This column would indicate "presentation" or "location" (or some good name). Each style would have a dropdown with checkboxes in it allowing them to control the above options that david laid out (i.e. Show in error list, Show squiggles, etc.)

We would pick the best defaults for each style option we provided, but users could tweak as they want. So, for example, "unused usings" would just have the "fade out" presentation option checked. But users could say "i want this in the scroll bar and error list if they wanted."

Primary concern would be that this would bloat the size of this dialog. However, my hope would be that by the time we did this, we could add the extra inch or so to make this possible.

@Pilchie Pilchie added this to the 2.1 milestone Sep 22, 2016
@Pilchie Pilchie modified the milestones: 15.1, 15.3, 16.0 Mar 29, 2017
@jinujoseph jinujoseph modified the milestones: 16.0, 16.1.P1 Jan 16, 2019
@jinujoseph jinujoseph modified the milestones: 16.1.P1, 16.2 Apr 24, 2019
@jinujoseph jinujoseph modified the milestones: 16.2, Backlog Jun 9, 2019
@CyrusNajmabadi
Copy link
Member

Closing out due to lack of feedback and us not likely changing these experiences.

@CyrusNajmabadi CyrusNajmabadi closed this as not planned Won't fix, can't repro, duplicate, stale Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants