Is there any method to set the modifier which trigger the go-to-definition feature?
I am used to hold the Ctrl to select multiple words as a whole. This behavior conflicts with the functionality of this extension.
A selection check before triggering is fine for me.
Thanks Mason, that's an item to put on the backlog. I'm mulling over how to expose it, as putting a single options page somewhere in Tools->Options just to select some combination of alt/ctrl/shift seems overkill, but there isn't really another common location to put that option. If you have any ideas, that would be helpful, too :)
I would really like to use this extension but I do not want to "sacrifice" my Ctrl DblClick.
The trigger customization is something that I consider as an enormous benefit for this expansion. I am even absolutely fine with specifying the trigger key manually in the .config file.
Do you use ctrl-click or just double-click? They do the same thing, and this extension (should) only affect the former. If you are used to double-clicking to select a word, then you just need to un-train yourself to hold down control when you do it.
I'll keep the .config option in mind. Also, if you are up for it, you could try grabbing the source (http://github.com/NoahRic/GoToDef) to change it yourself. It's unfortunately not well factored to make it a completely trivial change, but it should be about as easy as replacing all instances of ModifierKeys.Control with ModifierKeys.Alt.
Version 2.1 worked better for me. The new version does not react as I aspect. Clicking first Ctrl and then perform a mouse click does not work any more.. Now it reacts sometimes if a perform a mouse click first and then press ctrl. Is there a possibilty to get the version 2.1.
Hey Chris, I'm not quite sure what you mean :( I generally use it by holding down the ctrl key and then clicking, which is what it sounds like you are saying doesn't work. Could you give me a bit more information on what isn't working?
To get version 2.1, you can download the source at that point (http://github.com/NoahRic/GoToDef/zipball/2.1) and build it yourself, once you've downloaded the SDK.
exactly that is what doesn't work. I'll give you some scenarios and what then is happen.
1. Holding down ctrl and then moving the mouse to the word --> Nothing is happen
2. Moving first to the word then holding down ctrl --> Color of the word is changing and the word is underlined, mouse pointer is sometimes changed
3. Moving the mouse after 2. --> Mouse pointer is rechanged and will never changed back, word is sometimes still blue and underlined
4. Clicking after 2. --> Nothing is happen
5. Moving first to the word then clicking and holding the mouse button down and then holding the ctrl key and finally release the mouse button --> Performs as I expected on 4.
Since version 2.1 works fine for me, I will use this version again.
Do you have any other extensions installed (like the pro power tools)? It's possible there could be something conflicting there. I still can't repro it, so there isn't much I can do to fix it for you, sorry :(
There are some other extensions in the extension manager:
- DevExpress Tools
- Enterprise Library v5 Configuration Editor
- Go To Definition
- Highlight all occurrences of selected word
- PowerCommands for Visual Studio 2010
- Regex Editor
- Visual Studio 2010 Pro Power Tools
But I find a solution so I'm happy again :-)
I'm not sure what else it is, then :-/ It could be an interaction with the DX tools or Nick's highlight references extension (I didn't realize earlier that you had that extension installed; when I saw "highlight references", I assumed the built-in feature). Unfortunately, the only ones I have source for are the pro tools (since it is a copy of this extension) and the regex editor. While the regex editor's implementation of mouse handling is suspicious, it shouldn't be causing a problem except on lines that have "new Regex(".
Noah, this is workaround and it decreases usability of the extension. Try copy with mouse hyperlink
in winword. It's the right behavior. Need to change your mind every time new extension appears is wrong.
The fix I've suggested (just do not navigate on click on selection) is simple. Why not implement it?
The fixes you suggested are not simple in this context, unfortunately. I may try moving the logic back to handling mouse up events and deal with the other issues that crop up (as the extension worked when I first wrote it), but it isn't a simple change. In the editor, mouse interaction is handled in a decentralized and often hard-to-debug manner, which is what makes this complicated in the first place.
If you'd like, you can download the source and make the change on a private version of the extension you are running; the source can be found on github here: http://github.com/noahric/gotodef. If it really is as simple as you say, it should be easy for you to fix.
In the meantime, if I get some time this weekend I'll take a look at fixing this.
Sorry, forgot to add: the hard part of the fixes you mentioned ("fix it", and "add an option") are the mouse interaction for the first part (as I describe in my previous post) and adding an option page (involves adding a package options page some hackery for WPF options pages). Just changing it to not navigate when clicking on the selection wouldn't be difficult, but I don't think that's the right default behavior. However, it should be pretty easy to make that change in a private copy and run that on your own machine.
May be it'll best to align with all links/buttons behavior and navigate on mouse up.
However, there is cludge (done in 5 mins; not debugged yet but seems to work).
Just one line:
// Now, check for valid classification type. C# and C (at least) classify the things we are interested
// in as either "identifier" or "user types" (though "identifier" will yield some false positives). VB, unfortunately,
// doesn't classify identifiers.
foreach (var classification in _aggregator.GetClassificationSpans(extent.Span))
var name = classification.ClassificationType.Classification.ToLower();
if ((name.Contains("identifier") || name.Contains("user types"))
Yeah, as I said in my last post, though, I don't want to make that change by default ("Just changing it to not navigate when clicking on the selection wouldn't be difficult, but I don't think that's the right default behavior.") The hard part is fixing it without introducing that behavior or introducing that behavior as an option.
Bob, the right design is to align behavior with common rule: buttons and links are clicked on mouse up. After that, it's quite simple to ensure that mouse moved out of drag-drop threshold and do not navigate.
Here is what I get when the extension is installed:
Highlight the element.
Hold control key down (underlines).
Mouse-down on the highlighted/underlined text.
Goes right to definition (does not wait for mouse up).
When the extension is not installed, BTW, I am not able to copy drag anyway. Holding the control key down simply extends the highlighting when the mouse is clicked and dragged. Is this a bug or a "feature" in 2010???
Bob, when I said "the right design..." i meant "how things should be done". Sorry if mislead you.
Confirmed - when extension disabled or uninstalled, ctrl should be pressed after mouse key. "Feature", I think.
Bob - it didn't change in VS2010, though this extension conflicted with it.
Bob and Sinix - could you guys give 2.2 a try, if you are still interested in using the extension? I've updated it to work with mouse up and worked around some of the original issues I ran into, so this should now work more sensibly with word selection and drag/drop.
Just a suggestion:
I like to use another extension that supports regex editing using ctl-click on a literal string. Obviously that conflicts with this extensions user of ctl-click. I am guessing this conflict may also be affecting other people. I was wondering if it would be possible to add an option to disable the ctl-click functionality for literal values.
As an aside it would be nice to be able to do the next-reference thing also as an option. eg on alt-click.
Hi Noah - I haven't tried, but curiously why does a task that (to me) seems very straightforward - assigning an action to a mouse+key combo - need an extension? Isn't there someway using the keyboard options to do this?
You can absolutely use the keyboard to do this; by default, F12 is bound to "Go To Definition", and there is also an entry in the context menu of the editor and (I think) the VS menu (so you could use alt shortcuts). However, there are some benefits of having this type of extension/feature:
1) The url-esque underlining is a nice visual hint for what items have definitions. This extension doesn't do this perfectly, but it does help somewhat.
2) It's one fewer action (click vs. click to move caret and then hit F12) per navigation. This doesn't sound like a lot, but it can be useful to just navigate from definition to definition by holding down (and not letting go of) the control key and clicking around).
3) It's also more comfortable to leave your left hand on the control key and leave your right hand on the mouse to navigate than it is to either leave your left hand hovering over F12, moving the left hand to F12 each time (which probably requires that you look at the keyboard each time), or moving the right hand to F12 each time (which is the worst case - you have to look at the keyboard and you spend time moving back and forth between the mouse).
In any event, it isn't a feature that everyone wants or needs, so download it and try it out if you are curious to see what it is like :)
There isn't one published anymore, but you can grab the sources from github from before the changes to update the extension for Beta 2. This should be the one:
I played around with C for a bit, and it does appear to work for it, since the C and C# languages services do a lot of things very similarly. Technically, it makes ctrl click invoke GoToDefinition on whatever word you click on (even if it isn't underlined), so it works in any language. The underlining works by detecting which words are classified as some type of "identifier" or "user type", which C and C# both do. VB, unfortunately, doesn't classify all identifiers/user types, so few things will get underlined. I didn't play around with F# or aspx at all, though the underlining may work to a varying degree with those as well.
You can't change the color of the identifier in the Fonts and Colors options dialog (due to an issue in beta 1), but you could change it programmatically or by modifying the source. I'm hoping to get this extension and the ItalicComments up on codeplex or someplace similar in the near future. In the meantime, if you'd like, I can help you write a little extension for yourself to change the color or get a modified version of this extension with a different color. You can ping me at noahric at microsoft.