convert "." to "->"

[blueshake]

hello,
This patch can convert "." to "->" when the token is pointer.NOT smart but work.
any idea/comment is welcome.

[MortenMacFly]

This patch can convert "." to "->" when the token is pointer.NOT smart but work.
any idea/comment is welcome.

What would happen if I *really* would like to enter a dot? E.g. the parser has parsed incorrectly? Would it always be replaced with the pointer operator then? If yes, then this should surely be configurable.

[oBFusCATed]

100% make it configurable, so I can disable it  :lol:

[blueshake]

What would happen if I *really* would like to enter a dot? E.g. the parser has parsed incorrectly? Would it always be replaced with the pointer operator then? If yes, then this should surely be configurable.

The following patch can do this.for the second time ,it would not work.(just delete the "->" ,press "." again.)

1.can anyboby make this function be confgurable,I don't know how to do this.
2.not work for abc().:,because now I just simplely skip the "."

Code

struct qq
{
    int x;
    int y;
};
qq* abc(int aa)
{

}
int main()
{
    qq* pp;
    pp->
    cout << "Hello world!" << endl;
    return 0;
}

Edit:

need helps to refine this function.

[killerbot]

sounds nice. From asking around a bit, it seems it should be configurable (some people will turn it of).
The best thing for the moment is to try it out (once you have some more or less final patch), and see how many times the parser would pull our leg.

Some extra thoughts :
* would be nice if it is aware of stl iterators, and do the same trick
* in future this is going to be hell for our parsers,thanks to the auto variable (C++0x will rock, but for parsers/IDE's lofe won't get any easier ;-) )

[blueshake]

update:can work with function now.

Code

Index: src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- src/plugins/codecompletion/codecompletion.cpp	(revision 5891)
+++ src/plugins/codecompletion/codecompletion.cpp	(working copy)
@@ -2040,7 +2040,67 @@
                     return;
                 }
             }
+            static bool repeat = true;
+            if (ch == '.' && repeat)
+            {
+                repeat = false;
+                Parser* parser = m_NativeParser.FindParserFromActiveEditor();
+                if (parser)
+                {
+                    TokenIdxSet result;
+                    int pos = control->GetCurrentPos();
+                    wxString line = control->GetLine(control->LineFromPosition(pos));
 
+                    //skip the "."
+                    int startAt = control->GetColumn(pos) -2;
+                    int nest = 0;
+                    if (line.GetChar(startAt) == ')')
+                    {
+                        ++nest;
+                        while ((--startAt >= 0)
+                                && (nest != 0) )
+                            {
+                                #if wxCHECK_VERSION(2, 9, 0)
+                                switch (line.GetChar(startAt).GetValue())
+                                #else
+                                switch (line.GetChar(startAt))
+                                #endif
+                                {
+                                    case ']':
+                                    case ')': ++nest; --startAt; break;
+
+                                    case '[':
+                                    case '(': --nest; --startAt; break;
+
+                                }
+                            }
+                        if ((   (startAt >= 0)
+                                && ((line.GetChar(startAt) == ')')
+                                || (line.GetChar(startAt) == ']') ) ))
+                        ++nest;
+                        ++startAt;
+
+                    }
+                    int endOfWord = control->WordEndPosition(pos -line.Len() + startAt, true);
+                    if (m_NativeParser.MarkItemsByAI(result, true, true, true, endOfWord))
+                    {
+                        if (result.size() == 1)
+                        {
+                            Token* sel = parser->GetTokens()->at(*(result.begin()));
+                            Manager::Get()->GetLogManager()->DebugLog(sel->m_Type);
+                            if (sel->m_Type.find('*') != wxString::npos)
+                            {
+                                control->SetTargetStart(pos-1);
+                                control->SetTargetEnd(pos);
+                                control->ReplaceTarget(_T("->"));
+                                control->GotoPos(pos +1);
+                            }
+                        }
+                    }
+                }
+            }
+            else
+                repeat = true;
             int timerDelay = cfg->ReadInt(_T("/cc_delay"), 500);
             if (autoCC || timerDelay == 0)
             {

[blueshake]

would be nice if it is aware of stl iterators, and do the same trick

For now ,I just search "*" in token's m_Type ,it is not easy to do this for current parser.

[ollydbg]

* in future this is going to be hell for our parsers,thanks to the auto variable (C++0x will rock, but for parsers/IDE's lofe won't get any easier ;-) )

Hi, can you explain this sentence? I can't fully understand you. Thanks.

BTW:My lab's networking was broken, so, I can't test this patch these days till the networking was fixed.

[blueshake]

* in future this is going to be hell for our parsers,thanks to the auto variable (C++0x will rock, but for parsers/IDE's lofe won't get any easier ;-) )

Hi, can you explain this sentence? I can't fully understand you. Thanks.

BTW:My lab's networking was broken, so, I can't test this patch these days till the networking was fixed.

Not understood it fully too. :wink:

[killerbot]

well in C++0x there will be several cases where you no longer will have to specify the type of a variable, the compiler will determine it for you.

Examples :
auto Count = 10;  // --> int

std::vector<std::string> Hello;

for(auto It = Hello.cbegin(); It != Hello.cend(); ++It)
{
  std::cout << *It; // -> std::vector<std::string>const_iterator
}

this last loop can also be written with the new foreach, and also there the compiler will deduce the type.

And so will code completion parsers have to deduce this according to the new language rules.

[thomas]

I'd very much like if no more extra smartness was added to code completion, it is already bad enough as it is now. It already hampers daily work enough the way it is now. Code completion should be the opposite, it should help.

And yes to C++0x, but it's present, not future

[killerbot]

that means Thomas you have the code completion plug-in enabled ?
What a shock ... 

[blueshake]

I'd very much like if no more extra smartness was added to code completion, it is already bad enough as it is now. It already hampers daily work enough the way it is now. Code completion should be the opposite, it should help.

And yes to C++0x, but it's present, not future

I don't understand why it already hampers daily work enough the way it is now.

[thomas]

that means Thomas you have the code completion plug-in enabled ?

Yes, I have it enabled for the odd hope that it might manage with a 1% chance to do a "find definition" correctly when I use a function like snprintf and want to be sure that I'm giving it the correct parameters. Never does, of course. Winning the lottery is more likely to succeed. So I find myself searching through system headers in Windows Explorer instead, every single time.
If CC only was helpful in, say 50% of all cases, and if it was only popping up shit in, say 5% of all cases, I wouldn't be complaining. But it is really only causing extra work and never helping.

I don't understand why it already hampers daily work enough the way it is now.

Because it's fucking dumb and pops up menus that only ever contain shit. And worse, you have to hit ESC to make them go away. If you type fast, it will happen once or twice per week that you type something like
struct SomeName
{

and find that this super smart code completion silently changed it into
struct SomeShitFromWindowsThatIncidentiallyStartsWithSome
{

And once per month, you only notice that after having wasted several minutes on a strange compiler error that you don't understand. Similar thing happens occasionally when changing a variable name in some function. After changing the name and hitting the "up" key 3-4 times (to get to the next line containing the name), you find yourself only scrolling through some flipping popup menu instead of moving the cursor. By the time you've stopped shouting and hitting your monitor with the keyboard, you have forgotten what you actually wanted to change.

Add to that these darn smart braces, which mean that you have double work to fix the indenting for every new scope block, only because the editor deems it a good idea to insert tabs when you never touched the tab key. At least those can be turned off relatively easily in Code::Blocks, but I've yet to find where to disable them in SciTE.

In that sense, I wouldn't want the editor to mess with changing operators silently (and possibly unnoticed). It's the programmer's job to know what operator is the right one, not the editor's. And in this case, it is much more severe than inserting extra tabs (which is only formatting) or inserting some bullshit names (which will not go unnoticed). This is something that even has a realistic (though admittedly small) chance of introducing silent changes which will compile without error, but won't do what the programmer intended.
I mean, you could as well have code completion change all occurrences of var++ to ++var, how does that sound? It's the very same idea.

[MortenMacFly]

or inserting some bullshit names (which will not go unnoticed).

Turn it off.