| T O P I C R E V I E W |
| Mordachai |
Posted - Apr 01 2014 : 10:36:55 AM
I love the case-correction feature *when it works*. :)
However, often, it does not. Exactly because it chooses symbols that are globally defined over ones that are locally defined.
e.g.
template <typename CharType> bool GetNextNonBlankLine(CachedTextFile<CharType> & ctf, CharType<<<--- WHEN TYPING THIS, VA CONVERTS IT TO "CHARTYPE".
If I mouse-over CHARTYPE and use go-to, I find it is defined as an enum in output.c, which is rather an obtuse choice, no?! After all, output.c is not even in the include web... it's a .c file (...\\VC\\crt\\src\\output.c)
And even if it were #included somehow, it would be a really poor choice of symbol, since the template <typename CharType> is definitely what C++ is going to see there (unless of course the case is changed to CHARTYPE, but I *typed* CharType, VA just "FTFY"!) Ugh! :(
So, perhaps the symbol engine could be smartened up a bit and look first at what's closest, and then only after exhausting the far more likely local symbols, offer the far-away symbols. Especially on an auto-correct feature such as case-correction - that's absolutely irritating when it auto-"fixes" the correct case with the wrong one for a symbol that was locally correctly available. It's an anti-feature, in such cases, which are way too common...
|
| 3 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Apr 01 2014 : 5:26:29 PM
Regarding your template example: Visual Assist doesn't suggest template arguments so doesn't have a chance to correct to the right thing:
case=8462 |
| accord |
Posted - Apr 01 2014 : 5:06:25 PM
We're already blocking CamelCase to camelcase:
http://docs.wholetomato.com/default.asp?W344
But CamelCase is corrected to CAMELCASE for some reason. I have put in a feature request to change this:
case=81352 |
| Mordachai |
Posted - Apr 01 2014 : 10:43:36 AM
Maybe in general the repair-case needs a fuzz-factor. Have a candidate likeliness feature, so that I can state that I want matches to be fixed at a 90% threshold, instead of the current "replace every character in what I typed". So like your example, one character w/ wrong case is fixed, but typing CharType would not be, because CHARTYPE is a terrible, poor % match candidate, and can instantly be seen to be wrong always. (A human being isn't going to take the time to type camel-case if they mean all-caps, chartype -> CHARTYPE is a far better match than CharType -> CHARTYPE). |
|
|
