Bug fixes

I took a little break from the Markdown work to fix a few bugs and annoyances in my other extensions.

Go To Definition

Go To Definition on github.

Updated Go To Definition on VSGallery.

There were two known issues with this one. The first was reported by a user, Craig Gidney, who noticed that you can't ctrl-click on an identifier if there is either a breakpoint or a "highlight references" marker over the token.

The other is an issue I noticed while using the extension in my normal work, which is that you can't activate a smart tag with ctrl-. (period) if your mouse happens to be over a token that is underlined.

The underlying cause of both of these turned out to be the same, which is that the logic in the classifier was causing spurious and constant layouts when the mouse was moving over the token that was already highlighted. The change was a simple one; if the classifier is asked to highlight a new span, it doesn't do any work if the old and new highlight spans are the same.

You can view the diff on github, if you want to see specifically what I mean.

Triple-click

Triple-click on github.

Updated Triple-click on VSGallery.

This one comes from Chris Dias, who is the Group Program Manager of the Visual Studio Platform team (he's basically chief PM of all the PMs that I work with). He noticed that triple-click in most other applications selects the a line and the line break, whereas this extension doesn't include the line break. That means that if you select a line and then press delete/backspace or cut, it wouldn't actually get rid of the line (in the sense that you'd want). He also noticed that it just seemed to not work sometimes, though he had no idea how he got into the state.

In addition to the bug fixes, I wanted to add drag support, to select whole lines at a time after you've clicked (and held the mouse down). Most other applications support those, though some (like IE) have some strange line-select/word-select hybrid once you start dragging. For most other applications, it works like word-selection, where the original word/line remains highlighted as the "anchor" of the text you are selecting.

The first change was really easy; ITextLine has two properties for the extent of a line: Extent and ExtentIncludingLineBreak. All I had to do was switch from using the former to the latter.

The second fix was also easy, once I realized the (very dumb) logic error I had made. Note to self and everyone else – when computing the coordinates of the mouse relative to an IWpfTextView, make sure to add the ViewportTop, not subtract it.

Drag support wasn't too bad, either. I added handlers for mouse move and left button up (for tracking the state of a drag that started with a triple-click), and then wrote a little piece of logic for determining the extent of the drag, making sure to always include the original line that was selected.

I also took this opportunity to create an icon and screenshot for this extension. I'll be writing another article in the near future about icons and screenshots, as I just went through and updated all of them (though haven't uploaded the changes quite yet for everything).

Here's the diff for the first bug fix and the drag support, if you are curious. Here's the diff for fixing the dumb logic error and the new icon/screenshot.

Updating

If you haven't already, I'd advise turning on the automatic updating logic in VS, which you can find under:

 Tools->Options->General->Environment->Extension Manager->Automatically check for updates to installed extensions

Also, if you want to see all the extensions I've installed, you can search directly in the extension manager for Noah Richards. So far, I have five: Triple Click, Go To Definition, Gradient Selection, Italic Comments, and Fix Mixed Tabs (the newest one). I run all but Gradient Selection locally (I don't mind the flat selection, and I'm using VS inside a VM running on my laptop, so I appreciate the quicker selection model). My extensions page has more information about each.

And last but not least – if you find bugs in any of these extensions, please let me know in the comments. No guarantees that I'll get things fixed in a timely manner, but I do read every email and comment sent my way.

Comments

• Anonymous
  January 21, 2010
  Hi Noah, Just updated to the latest version of triple click & italic comments (thanks for writing these btw) and gave them a little test. Initially the italic comments only work on regular comment, not the xml comments.  If you go to the fonts and colors dialog page, just look at it and press ok you don't have to make any changes, then the xml comments change to italic as well.  And at the same time, the gradient selection changes to a solid fill brush as well.  The italic comments extension beahved this way before the update too. David.

• Anonymous
  January 28, 2010
  I think it may be related to another bug I discovered last week, which is that the format map's CurrentPriorityOrder doesn't contain all the items in the format map, which I was assuming.  I think I'll try working around it by special casing XML Doc Tag and see where that leaves me. Thanks for reporting this! -Noah

• Anonymous
  January 28, 2010
  Hey David, not sure if you'll see this, but I've updated both the ItalicComments and GradientSelection extensions to fix those bugs.  I'll write a blog article about the bugs and fixes soon-ish, but let me know if you get a chance to try out the updates. -Noah

• Anonymous
  February 11, 2010
  Hi Noah, I just updated to the RC and latest version of your extensions, definitely closer now :-)   This time when you open visual studio, load a project and look at the source the XML comments are not italic.  as soon as you click in the source somewhere or change the zoom level they switch to italic.  Regular comments are correct.  Closing the file, re-opening has no effect, they stay italic, it's just on the initial load. The gradient disappearing problem has gone though, and looks lovely on my black background too :-) Again, thanks for writing & updating these, David.

• Anonymous
  February 11, 2010
  Yeah, that sounds like a side-effect of the workaround the code uses for detecting at what point it should "fix" up comments.  Right now, it happens the first time the view gets aggregate focus (which explains what you are seeing).  It should probably be when the view is connected to a presentation source instead, so I'll switch that over and see.  Keep checking the extension for updates in the next couple of days, and you should get an updated version on the gallery. Thanks for reporting all these :) -Noah