A problem with implementation might not always be a bug. I’m not sure which this one falls into, because it’s two competing features that are designed to help, but almost make each other less useful in certain situations.
Box Selection and Multi-Line Editing in Visual Studio 2010
By now, you’ve likely seen Brittany Behrens and teams’ implementation of Box Selection in the VS2010 IDE. It allows you to modify your selection based on screen real estate (rather than characters and lines) and then edit the selection in intuitive ways. You can see Brittany’s walkthrough here and my lovin’ it here.
Where it Falls Short
Unfortunately, as rosy as it is, I don’t think it’s yet been fully implemented…or at least it doesn’t go as far as it could.
When working in the HTML editor in Visual Studio 2010, the box selection feature works brilliantly until you try to close tags. What you end up with is a poorly-formatted HTML document as a result of the multi-line editing feature.
That’s because it butts heads with the auto-complete feature on HTML tags. If you were trying to get a bunch of anchored list items into an unordered list, for example, the output becomes:
As you close the last HTML tag, only the last line item is properly completed, leaving all other lines non-compliant.
Is it a Bug?
I don’t think you can classify this as a bug, however, as it’s just supplemental functionality that is, perhaps, not being used as originally intended. If, however, multi-line editing is to server more than just code files and classes, and the HTML editor was in-scope for the feature, this could be classified as a defect.
I’ll leave that up to the smarter-folks-than-I on the IDE team.
Thankfully, the workaround is built into the feature ;o)
All you need to do is reselect the boundary space (between the characters) with box selection, and then complete the tag manually. Multi-line editing takes over and lets us complete (in the example above) all four lines at once.
More "unimplemented behavior" than a bug, I suppose.
ReplyDeleteMutli-line insertion was introduced fairly late in the product cycle, with the understanding that most languages wouldn't really integrate intellisense-esque features with it (no multi-line completion, for example, and auto-insert, as you discovered), as it would have complicated the feature even further. Like you point out, there's a workaround for accomplishing what you need, so hopefully it doesn't kill the utility of multi-line insertion for you :)
I'm guessing the most likely "fix" would be to turn off auto-complete when multi-line insertions are being made (since it's not always easy to guarantee syntactic or semantic correctness when you are making insertions in more than one context). If you have the inclination, can you file a bug on Connect (https://connect.microsoft.com/VisualStudio)? It very likely won't change before VS2010 is released, but it could get consideration in future releases or service packs.
Oh, and in the interest of full disclosure, I'm the developer that wrote most of box selection and multi-line insertion in VS2010.
Thanks for the comment, Noah, and the work.
ReplyDeleteLike I said, it's brilliant enough to be immediately useful and to also provide a viable workaround to its own problem.
I've filed the bug with the connect.
Cheers,
-jc