Closed ttytm closed 5 months ago
Let's base it on #51, then this one can be simplified as well.
Alternatively, this could add the inline comment to the end of the above comments. Maybe with a linebreak if there are already other comments.
I think trailing comments should stay trailing. Just as they are in the source when added.
I think trailing comments should stay trailing. Just as they are in the source when added.
I see and like that Idea. It requires to put some work into how the hover dialog is handled in general. Maybe as a separate feature?
Hmm... visualizing...
How about this: If there is a doc comment above, show the first line of that by default. If there is no doc comment above, but there is a trailing comment, show the first line of the trailing comment. In either case, if there is more than one line of comments (including both doc and trailing), include a more...
link that will expand the hover to show everything.
The reason for this is that when you're just learning how to use a struct, function, etc., you need the full text, but over time, you likely just need a quick reminder.
A change like this is of similar scope - working on the hover dialog itself - as showing a trailing comment in the hover dialog for struct fields with trailing comments. And tbh I don't see myself finding the time working on adding those conditions to the hover dialog yet.
In the meantime, then, how about this...
If there's a doc comment, show it. It there's a trailing comment, show it with a marker in front to indicate trailing comment. If there's both, show both with a blank line between, and a marker to indicate trailing comment. Maybe something line this...
foo is a field that holds bars
... and this is the trailing comment
If you could get a wedge instead of ...
, that would be fine, too. A >
would work if nothing else, but it doesn't really set it off much.
Allow for inline struct field comments. Comments above a struct field are prioritised.
Adds a fast track exit if comments has a length of 0.