| Author |
 Topic  |
|
|
Mordachai
Tomato Guru
USA
224 Posts |
 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...
|
|
|
Mordachai
Tomato Guru
USA
224 Posts |
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). |
Edited by - Mordachai on Apr 01 2014 10:44:09 AM |
 |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
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 |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
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 |
Edited by - accord on Apr 01 2014 5:27:27 PM |
|
|
| |
Topic |
|
|
|
Prefer local symbols for case-conversion / etc.
