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.