Plugin editor always adding improper closing brace

If I hit Enter to create a new line in the c# code editor window, the editor will always insert a new closing brace for that scope. For example:

void func()
{
    if ( foo )
    {                    <- put cursor here and hit enter
        bar = 1;
        xyzzy = 0
    }
}

results in:

void func()
{
    if ( foo )
    {
                     < - cursor is here
    } <- BOGUS!
        bar = 1;
        xyzzy = 0
    }
}

Where the indentation level is seems to make a difference on whether this happens or not; if the keyword the brace belongs to is not at the current scope indentation, a new brace will not be inserted:

void func()
{
    if ( foo )
    {
        bar = 1;

            if ( worksok )
            {       <- put cursor here and hit enter
                plover = 1;
            }

        xyzzy = 0
    }
}

That works as expected.

It’s a pain to constantly have to delete these extra braces. What’s odd is that when you put the cursor in front of the opening brace before hitting Enter, it correctly highlights the matching closing race, but then goes ahead and sticks another one in.

I haven’t exhaustively profiled this, and can attach a file if this is not reproducible. This is with 45beta26, and I have VS2010 installed.

Is there some editor setting that is doing this?

my result was this:

void func()
{
    if ( foo )
    {                    
    	<- put cursor here and hit enter
        bar = 1;
        xyzzy = 0
    }
}

no BOGUS brace. but it seems to me i also had that behaviour you describe once but i’m not able to reproduce it right now :/

edit:
just had a look at the code. it simply looks for a closing brace at the same indentation level. if it doesn’t find a closing brace or the one found is at a lower indentation level it inserts one. this solution might be too simple as it seems, but for the time being i can’t think of a better one (which would be as easy to implement).

Hmmm, seems there is something funky about the file I was editing. Here’s a test case, made by cutting and pasting from the problem file, and then removing stuff down to the bare minimum. Problem shows every time for me with this file.

As you can see here, when you put the cursor in front of the brace with my comment, the correct matching brace is highlighted, but hit enter and another is created. Some odd invisible character here throwing the count off?

Thanks Elias!

Test case showing bogus brace insertion (6.6 kB)

Any ideas on this? Elias, does this file show the same behavior to you? My file is still exhibiting this behavior, and since cutting and pasting into a new file carries the same behavior over, the only way I can see to get rid of it is to manually type in the file again. (And I thought this was a good debugging case for you devvvvs…)

yes, i see exactly the same behaviour. reason is that your if statement uses spaces for identation, whereas the closing braces further down use tabs for identation.
remove those spaces before the if statement, replace them with tabs and the BOGUS brace is gone (fast way would either be to press ctrl+i, or select the 3 lines and press ctrl+i, for auto-ident).

Thanks Elias, but needless to say that’s a little non-obvious! But seriously, since the code lines up properly in the editor no matter what kind of white space is used, it seems odd the brace-identifier is thrown off by it.

This is not really just nit-picking, as when a dynamic plugin causes a crash an external editor has to be used to clean it up. Different editors have different strategies for handling indented whitespace, and can completely mix tabs and spaces.

Thanks for the tip on cleaning it up!

if your dynamic plugin causes a crash there is another way to get to the code. use the project explorer (ctrl+j), select “show unused projects”, open your project and you should be able to change the code from inside of vvvv. as long as the plugin is not in use it can’t cause a crash.