Dart-code: Closing Labels feedback

[DanTup]

If you've disabled Closing Labels, please leave feedback about why so that we may be able to improve the feature!

[bergwerf]

First of all, I think the prompt redirect to this issue is quite nice!
However, I do not like the closing labels since I do not want plug-ins to mess with the appearance of my code like this. When the closing label appeared I thought is was a silly comment and tried to remove it. After almost cursing VSCode I came upon the idea to look at the dart plugin settings to see if it was some fancy feature.
So personally I do not like the labels (if a closing label would really be appropriate for readability I would add an actual comment so everyone can see it, additionally the label might surpass the 80 chars line which although not entirely relevant anymore, is kind of holy to me). So i suggest to make the closing labels clearly different from comments (probably do not use a // and instead a thin arrow or something). Additionally I think this should be an opt-in rather than an opt-out feature (maybe announce the feature via a notification). If possible, it would be nice to show a notification about this feature if the user tries to remove the comment to avoid frustration.

(I love the rest of the Dart-Code plug-in though! It has provided me with a great developer experience :D)

[DanTup]

@bergwerf Thanks for taking time to post feedback! The change to enable this was included in the release notes, but if they weren't read much previously, VS Code's automatic updating of extensions has probably only made that worse (FWIW, major features are usually called out on twitter). Probably for a feature like this one I should've included a prompt with a link to more info (and easy disable) - similar to the prompt for "Just My Code" debugging. I'll consider this for future features that might not be obvious to users.

It's not an accident that closing labels look like comments as they were somewhat intended to replace the comments that people would often add themselves (but remove the need to maintain them). Changing the styling is possible, though the options are relatively limited. I'll see what other feedback comes in about this before making any decisions.

Cheers!

[Mohammed90]

First, thank you for the amazing work on Dart-Code!
I love the feature and have had it enabled since the preview. Just today I found a point of improvement: anonymous functions don't have closing tags. I think the extension looks for a right/closing parenthesis, while anonymous functions close with right/closing brace. Consider the following Flutter code snippet:

new MaterialButton(
    child: const Text(
        "Press Me",
    ), // <-- closing tag is displayed here
    onPressed: () {
        //...
    }, // <-- closing tag is not displayed here, but would be nice if...
)

Not sure how technically easy to do, and it's not really a big deal. It'll just be nice-to-have.

[DanTup]

@Mohammed90 In an earlier prototype we did have param names shown in some places but removed them because they seemed noisy (we'd had them prefixed to the type) and in most cases the param name was child or children. I'm not sure if we thought about this specific case; maybe it makes sense to show something here (though it needs to be balanced against how much noise it may add).

We've since moved the implementation of this to the analyser so any changes here are part of the SDK, so I've raised an issue to discuss this at https://github.com/dart-lang/sdk/issues/31523 to see what the Dart team think.

Thanks for the feedback! 👍

[brettpappas]

Very cool feature but I disabled it because I wanted to be able to make it a little darker in my dark theme so it didn't stand out so much. Could you change it from true/false to maybe a color code / transparent? Or a second setting to set the color to avoid breaking existing configs.

[DanTup]

@brettpappas You can actually control the colour using workbench colour cusomisations! Add this to your user settings:

"workbench.colorCustomizations": {
    "dart.closingLabels": "#ff0000"
}

It defaults to using tab.inactiveForeground if you haven't explicitly set anything. I'll make a note to document this somewhere!

[brettpappas]

Perfect! Thanks for the info.

[rayfarias56]

Finally came across this when editing some old code that used List.generate. My experience was much like @bergwerf's. I don't mind this feature existing, but wish it was easier to find a way to turn it off. It took me a bit of time combing through intellij's settings to find this setting. When I googled it to make sure that it was indeed the culprit I found this thread. So thanks for taking feedback.

I'd suggest that if at all possible you allow some easier way to quickly turn this feature off from the editor. Clicking on the "closing label" or hovering to throw up some "Disable" box in intellij.

Thanks.

[DanTup]

@rayfarias56 This projects is the VS Code plugin so it's a bit different to IntelliJ. It's a fair point that it's not obvious what these things are called if you wanted to search for them - I'm hoping to improve documentation in the near future so hopefully it'll become easier to find info about them once I have!

[sean-clayton]

Came here from the popup. The reason I turned it off is because I don't really like looking at my code and see text that isn't my code. Personally, I turn off all extensions/settings that add any kind of words to the actual editor itself (on hover is fine, just not while reading code please).

[felideon]

Honestly, imo it added way too much noise to the code, at least when going through the Flutter tutorials. I also thought it was quite redundant given VSCode's indent guides and paren-highlighting.

It's also possible that my theme's tab.inactiveForeground was not the best default choice, as perhaps the closing labels should be a lot more subdued than the rest of the code.

Thanks for requesting feedback!

[DanTup]

@felideon Thanks for the feedback! Your colour is definitely less subtle than mine and the other screenshots I've seen, though it's hard to pick something that'll work well with all (I now wonder whether we could've gone with the main text colour with a lower alpha to ensure it's similarly subtle for everyone? not sure if the colour is that flexible where we declare it though). I think the indent guides have improved in Code recently too which probably eats away at it's usefulness a little.

As you probably saw above, you can tweak the colour if you'd like to try a more subtle one. It sounds like your mind is made up, but if you tried it, I'd be curious if it felt better if it was less "loud" (if so, maybe we can review whether we can get a better default to improve the experience for others).

[felideon]

@DanTup Regarding the colors, yeah, that makes sense. I figured it probably depended a lot on the contrast against the background color, and is perhaps even a bug in the theme I'm using since it doesn't seem much like an "inactive" color.

I'll re-enable it and customize the color, though. It does seem slightly more useful to have the labels than to rely on the paren-matching highlights only.

[DanTup]

@felideon Great, let me know how it feels after you've used it for a while, and if you think it's good this way (and it was mainly the colour that was the issue), I'll go back and look at our options for the colours. Thanks!

[ejabu]

Came here because the super innovative pop-up. Thanks !

@felideon wow, nice color scheme, would you like to share it the configurations ?

@DanTup , I also disabled it because its kinda distracting me. Is it possible to make the font appear smaller ? But I guess, I will try the color scheme that @felideon provided above.

[felideon]

@ejabu Hey sure, here are the pertinent settings:

{
    "workbench.colorTheme": "Monokai Dimmed",
    "editor.fontFamily": "'DejaVu Sans Mono', Menlo, Monaco, 'Courier New', monospace",
    "editor.fontSize": 14,
    "workbench.colorCustomizations": {
        "dart.closingLabels": "#464646"
    },
    "editor.renderIndentGuides": false,
    "editor.formatOnSave": true,
}

Notice I ended up hiding Indent Guides.

[DanTup]

@ejabu It's currently only possible to change the colour. I think changing the font size might look a bit weird, but if you want to open an issue I don't mind looking at it (or it might make a good first contribution 😉)!

[gspencergoog]

Honestly, the main thing I don't like about it is that it looks just like a comment, including the // beforehand. I'd rather it looked like some kind of non-code tag, maybe something that looks like a dim-colored Material Design "Chip" widget with the class name inside, or just something with a different background color and font size. That way my eye wouldn't go "Whoa! Who added that redundant comment in my code?!?" every time I see one.

I leave it turned on because it's useful information, but it is often distracting.

[blueneogeo]

I like that the feature was added, and I would not like it to be removed, however in practice I turned it off, since it added more noise for me than it solved the way it works now, especially with the theme I am using.

I do like this kind of feedback, but I would prefer it be used debugging values, like IntelliJ does:

[DanTup]

@blueneogeo If the only problem is that it's not subtle enough, you can tweak the colour (see above). It's hard for me to tweak the default in a way that will work well in all themes, so I just had to pick another theme value that seemed like it'd be subtle against the BG (I can't get at the actual background colour to do my own calculations, so I need to use another named theme colour - I can change this is anyone can find a better one though).

As for debugger values - it looks like VS Code actually has a setting for this - debug.inlineValues however it doesn't seem to work great in my testing:

Possibly we could file some bugs/requests against VS Code to improve this though. Feel free to test it out and open issues where it falls down against Dart Code and I'll do some digging into what I can fix here and file VS Code issues where it requires some help from there).

[blueneogeo]

@DanTup thanks, I had looked for but not found that setting! My experience with it is similar to yours, right now it works partially, it has some trouble deconstructing objects into informative values. It might simply be how it is being presented.

[DanTup]

I opened an issue about better supporting debug.inlineValues at https://github.com/Dart-Code/Dart-Code/issues/1163. Based on the lack of docs, I suspect it might not be entirely finished from VS Code's side, but I'll see if I can make some improvements anyway.

[dxps]

Thank you @DanTup and @felideon for the details.
I just enabled again the dart.closingLabels option, but added a subtle color to the result, so now it looks way better in my case:

using:

"dart.closingLabels": true,
"editor.matchBrackets": false,
"editor.minimap.enabled": false,
"editor.renderIndentGuides": false,
"editor.suggestOnTriggerCharacters": false,
"workbench.colorCustomizations": {
    "dart.closingLabels": "#3a525e",
},
"bracket-pair-colorizer-2.rulerPosition": "Left",
"bracket-pair-colorizer-2.highlightActiveScope": true,
"bracket-pair-colorizer-2.showHorizontalScopeLine": false,
"bracket-pair-colorizer-2.showBracketsInGutter": true,
"bracket-pair-colorizer-2.showBracketsInRuler": true,

[korgara]

I have 13 inch monitor, and they just took to much of space. Also they additionally confuse eyes.

[ArtemGr]

1) We (human beings) need space. Most of us do. Like when you see some pages left blank in a book, or the spacing between paragraph, or the fields, that kind of stuff. With labels the code feels crowded, oppressive even.
2) I would sometimes use a Python-like formatting, moving the closing braces up. This makes code shorter, easier to read, and allows me to put more space (blank lines) in a most meaningful fashion.
3) I agree with other people here in that displaying the closing labels as normal comments is wrong. I pay close attention to the comments I write, and seeing these pseudo-comments is super-confusing. I'm getting the knee-jerk "_Eh, did I write that? What was I thinking? I need to fix that comment!_" reaction.

The closing labels are an interesting idea, allowing to explore the hierarchy of a pirce of code bottom-up, but not something I would use.

A much more useful thing for me would have had been if the IDE displayed that kind of information on hover. And/or in the status bar whenever I navigate the closing labels with the text cursor.

[dxps]

The breadcrumb could get more granular than just the class and method, by including the widget scope.

[DanTup]

@vision8tech Do you mean like this?

That's not really related to closing-labels, but I've opened an issue at #1455 with details of where this is. I'd like to support it but it's blocked on VS Code issues (for ex https://github.com/Microsoft/vscode/issues/51332 - please add a 👍!).

[dxps]

@DanTup Did it. Thanks Danny for the feedback.

[DanTup]

Closing this as we're no longer pointing people here and I think we collected all the feedback we're likely to get.

The latest release has a UI Guides preview which may provide a less-noisy way to visualise build methods that I'd encourage you to try :-)

[ziqq]

@brettpappas You can actually control the colour using workbench colour cusomisations! Add this to your user settings:

"workbench.colorCustomizations": {
    "dart.closingLabels": "#ff0000"
}

It defaults to using tab.inactiveForeground if you haven't explicitly set anything. I'll make a note to document this somewhere!

It's work for me! thx!