-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add Closing Tag token #32202
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
Comments
@lrhn - any comments on this ? |
The latest versions of IntelliJ and VS Code both make visible support added to the analysis server to provide IDE level decorations exactly like what you're describing when the nesting structure of constructor invocations is deep enough. This was initially provided for Flutter build methods where the nesting level can get quite deep. The decorations show up in the edit pane, but are neither selectable nor editable. If you can try out one or the other, we'd love to hear your feedback. |
Do you mean these ghost comments ? https://user-images.githubusercontent.com/3357543/36224109-685b88b0-117b-11e8-9b55-65fc79ea73b5.png They are nice to look at, but not as useful as physical closing tags, because when you are inserting code fragments and your code is temporarily broken, the ghost tags vanish and become unhelpful - exactly when you really need to refer to them. |
Yes, those. It isn't clear to me that having it explicitly in the source code would simplify editing, but then I've never had such a feature available, so perhaps I'd be surprised. That said, it seems like using the existing comment syntax would be as good as introducing a new syntax:
and it would be easy for someone to write a tool to automatically add them when they're missing. |
The purpose of creating a new type of comment specifically for "closing tags" is so the user does not start editing them or think of them as comments. If the user adds their own comment - then an automatic tool could mistake that for an incorrect closing tag and overwrite it. I have edited a lot of code with closing tags in the past in the form of JSTL. A more recent example would be JSX or editing the Android XML layouts. It is quite a bit easier to see where code fragments begin and end in these examples. I think not having the closing tags in flutter is worse, because a lot of the time the mistake which you are trying to fix is small e.g. a missing / misplaced comma or curly bracket. |
Setting the cursor on a closing brace highlights the opening brace (for example in IntelliJ). |
I admit that after developing with Flutter for a couple of months I am better at seeing the patterns in the code than I was so it is not such a big deal. Plus you develop the habits such as finding the bracket insertion positions before pasting the code in place. But I would still argue that its a useful option to have particularly for beginners. If a feature like this makes a transition less jarring for beginners then I think it is worth some effort. Depending on what language you came from the confusion will vary, like your previous language might not have had anonymous functions - and those brackets seem wrong until you have seen them for a while. If you are coming from JSX then having the "ghost tags" move around while you are trying to fix a piece of code would seem like a step-down I am sure. Also, I dont agree that there is added noise because I am talking about replacing the "ghost closing tags" with "physical closing tags" so the "noise" is identical. If you dont like that you would turn the feature off in both cases. |
No plans to use language syntax on this. IDEs are showing the ghost closing tags. |
Add a closing tag token to Dart to permit the addition of xml-like closing tags. These "closing tags" could be added automatically by dartfmt or an editor for example.
I suggest # - or _ but the Dart language creators should decide what is best.
Here is an example of how it would work :
e.g. if we use # for example :
^ This is invalid code currently, and also after the new "closing tags" feature
^ The #Text is not intended for user edits, it is only valid when combined with an end bracket. This is so that it is not confused as a comment for general use. The text after the )# would be ignored by the compiler as per a comment.
More detailed explanation can be seen in :
Idea: Auto generated closing tags
The text was updated successfully, but these errors were encountered: