Wrong indent after dynamic surround of 'case' statement with braces

[elmar]

Dear all,

I have noticed the following wrong behavior of the dynamic surround feature for 'case' statements:
Existing code fragment:

Code: [Select]

        switch(bla)
        {
          case dummy:
            printf("hello");
            break;
        }
 
Now I want to insert braces for the 'case' code, so I am inserting a new line below the 'case' and pressing the '{' key.
SlickEdit is inserting also the closing brace immediately and the blue lines for the code block selection are shown, as expected.
But when I am now moving the cursor down to select the code to wrap in braces, each selected line will again be indented with 2 additional spaces. The result is an indentation with 4 spaces within the inserted braces instead of 2:

Code: [Select]

        switch(bla)
        {
          case dummy:
          {
              printf("hello");
              break;
          }
        }

The desired result would be an indentation by just 2 spaces as shown below:

Code: [Select]

        switch(bla)
        {
          case dummy:
          {
            printf("hello");
            break;
          }
        }

The following settings are configured in the "Indent Rule Exceptions" for 'case' statements:
  Indent:   On
  Indent Width:  2
  Brace aligned with case:  On

This behavior has been observed already with SlickEdit 2016 and is still present in the new 2017 version.
Is this a bug or do I have to change anything in the settings?

Best regards

Elmar

[elmar]

... would be great if someone could have a look at this issue.

Best regards

Elmar

[patrick]

I think this is probably a bug.  Very likely hot-fixable, I'll put it next on my list.  Thanks for pinging us, didn't mean to skip this one.

[jwiede]

I think this is probably a bug.  Very likely hot-fixable, I'll put it next on my list.  Thanks for pinging us, didn't mean to skip this one.

Should this be fixed in 22.0.1.0? 

I'm now seeing a slightly different problem (Mac64 v22.0.1.0 on 10.13.2):  Upon typing the inner brace, SE no longer produces a closing brace automatically, nor triggers the behavior where up/down cursor moves subsequent lines in/out of the newly-braced region.  So while the prior problem no longer occurs, the new behavior I'm seeing isn't necessarily any better or more correct, IMO.

[patrick]

@jwiede: No changes went into 22.0.1.0 for elmar's problem.  I can't reproduce the problem you're seeing with the source snippet from this post.  Can you get it to happen with just that example source, or is your source different?  It would also help to post your user.cfg.xml file from your configuration directory.  That may allow me to reproduce it if it's just a matter of differences in our configurations.

One other thing to note - dynamic surround will generally not kick in unless there are statements below that can be sucked into the braces when you arrow down.  So,
you get no surround for this:

Code: [Select]

    switch (x) {
    case blah:
         |                  <- type { with cursor there
    }

But you would get surround for this:

Code: [Select]

   switch (x) {
   case blah:
      |                  <- hit { with cursor there
      something();
      break;
   }

Edit:
Dynamic surround depends on the correct parsing of statements in the area you're working in, and will not kick in if there's any code it can't parse nearby.  It's a pretty forgiving parser, since we expect to be seeing partially typed statements all of the time during normal editing.  So if there's a particular code snippet where it won't kick in for you, we may need to take a closer look at it to see if it's something we can/should handle.

[jwiede]

Given the following as pre-existing text (Mac64 22.0.1.0 on 10.13.2):

Code: [Select]

void foo( void );
void bar( void );
void boo( void );

int main( int argc,  char **argv )
{
  switch( argc )
  {
  case 1:
    foo();
    bar();
    break;

  case 2:
    bar();
    boo();
    break;
  }
}

When I cursor to the first column in the "foo();" line and type '{', nothing happens, no auto-create of closer, no dynamic surround, nothing.  Even worse, when I then delete the '{' I'd just typed, SE then auto-deletes the nearest '}' after that point (erroneously, IMO -- it shouldn't auto-delete if it didn't auto-create), further imbalancing the braces present.

I've attached my user.cfg.xml, fresh from being auto-migrated by v22.0.1.0 from 22.0.0.9.

[davehohl]

I played around with the code snippet in the preceding post. Placing the cursor in column 1 of the "void foo" line and typing '{' does not result in any automatic stuff happening, but I would not expect it to, since a parenthesis does not seem valid in that context. I do not see the behavior of SE deleting a '}' when I delete the '{'.

If I move the cursor to the end of that line, delete the semicolon and then type '{', SE adds a matching '}', but does not do dynamic surround.

If I put the cursor at the end of the line containing "case 1:" and type '{', SE automatically adds '}' after the break statement in case 2, but dynamic surround is not active. But if I put the cursor at the end of the line containing "case 1:", do a carriage return and then type '{', SE adds a '}' immediately after the '{' and turns on dynamic surround.

The behavior certainly seems erratic.

I am running 22.0.1.0 on Win 10 x64.

[patrick]

@jwiede:
    Autobrace and dynamic surround won't kick in if the brace you inserted is not at the end of the line.  That's not something that changed for 22.0.1.  I was originally assuming that you were hitting return after the "case ...:" and then adding the left brace.  I'll look at the deletion of the wrong closing brace.

@davehohl:
   We don't seem to trigger dynamic surround for the braces on a function.  I think the idea was that there was rarely something at the top level that you'd want to slurp into the body of a function.  In this example, you probably wouldn't want to pull in the prototype for "bar" into the body of foo.  I'm going to make a note to look into that though, because dynamic surround would be useful for nested/anonymous functions for the languages that support those.

   For the "case 1:"  example, I get dynamic surround in both cases.  I played around with a few settings, but couldn't reproduce it.  If you want to post your user.cfg.xml file, I can try it with that.

[elmar]

@patrick: I am still getting the same wrong behavior with v22.0.1.0, see attached screen video.
I will send you my user.cfg.xml.

Best regards

Elmar

[patrick]

Sorry, it got lost in the other replies on this thread - the fix for your problem did not go into 22.0.1.  I think it's still doable, but it was too involved to make it into the point release on time. It can still be a hotfix as far as I can tell.

[davehohl]

Config file attached.