Auto-completion dialog should prefer variables over types

I will sometimes name properties after the type. Unfortunately, ReSharper seems to prefer the type when doing autocompletion. See screen shot:

6-16-2010 1-30-52 PM.png

This is what happens after typing "ScrollV".

The problem here is that I want to access the local ScrollViewer but unfortunately the default choice is the type. If I hit Tab then it becomes System.Windows.Controls.ScrollViewer which is frustrating to have to go back and fix. I find myself doing this a lot, because in this particular case I must not only make sure the right symbol is selected, but also check the graphic to the left to make sure it's not a type.

S

Suggestion: if there are multiple matches for a given typename, then the default choice should be based on the most local scope. In this case, the local scope has a member ScrollViewer, so that should be the preferred default selection in the listbox.
4 comments
Comment actions Permalink

Hello Scott,

ReSharper uses item completion statistics and pre-selects the most frequently
"chosen" item from the list. You can close Visual Studio and patch the corresponding
.resharper.user
file so that your property has bigger priority than its type in order to
avoid this behavior. Thank you!

Andrey Serebryansky
Support Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

I will sometimes name properties after the type. Unfortunately,
ReSharper seems to prefer the type when doing autocompletion. See
screen shot:

Image:6-16-2010 1-30-52 PM.png

This is what happens after typing "ScrollV".

The problem here is that I want to access the local ScrollViewer but
unfortunately the default choice is the type. If I hit Tab then it
becomes System.Windows.Controls.ScrollViewer which is frustrating to
have to go back and fix. I find myself doing this a lot, because in
this particular case I must not only make sure the right symbol is
selected, but also check the graphic to the left to make sure it's not
a type.S

Suggestion: if there are multiple matches for a given typename, then
the default choice should be based on the most local scope. In this
case, the local scope has a member ScrollViewer, so that should be the
preferred default selection in the listbox.

---
Original message URL:
http://www.jetbrains.net/devnet/message/5265661#5265661



0
Comment actions Permalink

I understand now. Well, in that case, I have a suggestion.

Suggestion: if the user ctrl-z's a completion right after performing it, then undo the statistics update as well. See, the problem I was having is that I'd pick the wrong one on accident. I'd undo it fix it manually, then a day later when I went to do it again, I accidentally picked the wrong one again. It's hard to break out of this cycle without going and patching the resharper file.

Having undo also undo the stats update would totally solve this problem. It means that mistakes would not carry a penalty that would encourage future mistakes.

0
Comment actions Permalink

Hi Scott,

  We'll be improving code completion preference policy for ReSharper v.Next. I think it will resolve your issue.

WBR, Oleg

0
Comment actions Permalink

I hope v.Next comes soon.. This is pretty frustrating. It's happening to me a lot now. Today I typed 'ToolTip.' in a method in a class derived from ListBox and it replaced it with System.Windows.Controls.ToolTip. ToolTip is a property. 99% of the time that a local property or variable exists it will not be the right thing to choose the fully expanded type.

Something's got to be wrong. I'm certain that I did not complete ToolTip with the full type name, even by mistake. Now every time I type 'ToolTip.' fast I get the full expansion. I have to go manually patch my resharper file now to fix this.

How about this:

If there is more than one exact match for text, and the user has not selected anything in the dropdown, then don't do the autoexpansion. I can't see how it would ever be the right thing to do to replace an exact symbol that I have deliberately typed and does exist with something completely different.

0

Please sign in to leave a comment.