Author Topic: Preview window show matching brace  (Read 748 times)

Graeme

  • Senior Community Member
  • Posts: 2366
  • Hero Points: 313
Preview window show matching brace
« on: September 16, 2019, 01:37:41 am »
If the cursor is on a curly brace (C/C++) (or #if / #endif) the preview window has nothing to show.  If the matching brace is off-screen it would be helpful if the preview window showed the code where the matching brace is, preferably with some highlighting so you can see which one - or else make the matching brace line the first (or last) visible line in the preview window.

Also if the code is collapsed with selective display, show the uncollapsed code in the preview window.  It would probably need to show the code adjacent to the visible line the cursor is on in the edit window instead of the "other brace".

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2815
  • Hero Points: 426
Re: Preview window show matching brace
« Reply #1 on: September 17, 2019, 02:03:35 pm »
If you float the mouse over the |+| bitmap when code is collapsed, it will show the uncollapsed code (unless you have mouse-over disabled, of course).

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2815
  • Hero Points: 426
Re: Preview window show matching brace
« Reply #2 on: September 17, 2019, 02:08:45 pm »
I'll double-check if we have a feature request to show the matching brace in the preview window.  The tricky thing with this feature is when you have something like this.

   (|someVariable ...
         ...
         ...
         )

   someFunction|(  ...
                             ...
                                 { lambda
                                     ...
                                      ...
                                  }
                                 ...
                              )

(the vertical bar represents the cursor).  Does the preview window show the close paren, or the definition of "someVariable".  Same for the next case with a large function call.  I think it is natural for the symbol definition to always win in any ambiguous case, but it does somewhat cripple the matching paren logic to do that.