Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intellisense + Capital Letters #17275

Closed
josefpihrt opened this issue Feb 21, 2017 · 10 comments · Fixed by #75757
Closed

Intellisense + Capital Letters #17275

josefpihrt opened this issue Feb 21, 2017 · 10 comments · Fixed by #75757

Comments

@josefpihrt
Copy link
Contributor

josefpihrt commented Feb 21, 2017

Version Used: Visual Studio 2017 RC 15.0.0-RC4+26206.0

intellisense

  • Currently, when I type CR, a method with name C...R... is selected only if there is no method with name Cr...

  • I would propose that if I type CR and there is a method with name C...R..., it should take precedence over a method with name Cr...

@Pilchie
Copy link
Member

Pilchie commented Feb 21, 2017

Tag @kuhlenh @CyrusNajmabadi @rchande @DustinCampbell

How do people feel about changing match preferences in cases like this?

@CyrusNajmabadi
Copy link
Member

Basically, an exact case-sensitive, CamelCase match would beat out case-insensitive other matches. I think that's ok. If the filter text contains capital letters, that's a strong signal this is what the usre wants. I think we could safely take this.

@kuhlenh
Copy link

kuhlenh commented Feb 22, 2017

👍 ran into this today...wanted to do DateTime.Now.AD to filter to AddDays() but it kept just preselecting Add(). As long as we make it case-sensitive, this should be fine.

@DustinCampbell
Copy link
Member

I"m also in favor of this. Sounds like a good tweak to me.

@josefpihrt
Copy link
Contributor Author

I realized that name can also start with two upper-case letters (interface name). So I would say that priority should go like this:

  1. AB...
  2. A...B...
  3. Ab...

@miloush
Copy link

miloush commented Feb 22, 2017

Also see #16053 for discussion and the current behavior.

This would address the same issue as tn case mentioned there. Not the MF case though.
EDIT: the tn case there is exact match

@Pilchie Pilchie added the Bug label Feb 22, 2017
@Pilchie Pilchie added this to the 2.1 milestone Feb 22, 2017
@josefpihrt
Copy link
Contributor Author

I would propose to take camel-cased identifiers into consideration. This could improve developer
productivity when typing local variable name (or parameter name).

A simple rule could be applied:

  1. aB...
  2. a...B...

Current behavior:

camelcase

@0xd4d
Copy link

0xd4d commented Mar 2, 2017

How about this one, happens if you have added using System.ComponentModel; :

completion

ArgumentNullException is a better match, and also happens to be exactly what I wanted.

@Pilchie Pilchie modified the milestones: 15.1, 15.3 Mar 29, 2017
@Pilchie Pilchie modified the milestones: 15.later, 15.3 May 22, 2017
@jinujoseph jinujoseph modified the milestones: 15.6, Unknown Nov 3, 2017
@bboyle1234
Copy link

PLEASE make intellisense case-aware.
When I type myV it should select myValue instead of MyValue.
When I type Myv it should select MyValue instead of myValue.

Here's the kicker: When a user bothers to use the shift key to capitalize a letter, they want the variable or member that HAS that letter capitalized.
I'd die of joy if you guys can make this happen. PLEASE.

@bboyle1234
Copy link

@rchande , I have no idea how I managed "unassign" you above ... hopefully you can fix that, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants