No announcement yet.

Matching Lua Comments: BC3 Regular Expression Bug?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Matching Lua Comments: BC3 Regular Expression Bug?

    I'm trying to match Lua block comments (and long strings) in the file format settings of Beyond Compare 3.

    These are defined here:
    Look for "long brackets" and "comments."

    Here's a short description:
    1. A comment marker, --, followed by an opening long bracket, which is a [, N equals signs, and another [.
    2. The comment body, which is anything but a corresponding closing long bracket.
    3. The closing long bracket, which is a ], another N equals signs, and another ].

    N may be any number greater than 0, and is the same for both the opening and closing brackets. (Lua long strings have a similar format, sans the leading dashes.)

    For example:
    [COLOR="green"]--[[ comment is here ]][/COLOR]
    [COLOR="green"]--[==[ comment [[also commented out]] still commented out ]==][/COLOR]
    I figured that I could use a backreference to accomplish the matching, like so:

    This doesn't work. Since I have no idea what BC3 adds in the middle, I also tried just a single expression:
    This didn't work either. I tested this one at to make sure it wasn't some mistake on my part, and it worked fine there.

    It seems that BC3's regular expression system is having trouble with backreferences, perhaps? I may be missing something.

  • #2

    BC3's RegEx capabilities vary a bit depending on what we are able to support. If you use the dropdown arrow next to the textbox, you can see the list of commands. We do not currently support backreferences here, but how would this RegEx work for you?:
    Type Basic RegEx
    Aaron P Scooter Software


    • #3
      *shrug* Well, that is the fallback I'm using right now. Not very happy with it because anytime you actually use long strings with a long bracket of depth greater than zero, you'll certainly be trying to include something like a comment or another long string within it, which defeats the purpose. That is to say, the end of the comment or string within your comment or string will be grabbed and the string or comment state will end prematurely for the purposes of syntax highlighting.

      in lua, you can write long strings like this:
      [[ long
      lines]][/COLOR] still supposed to be a comment but it's not ]=]
      The reason I thought you supported them is that they're listed in the help when you click "RE Examples" in the dialog.

      These are used pretty rarely, so the general "from: --[[, to: ]]" would cover most of the use cases, but BC3's certainly not able to properly support them. It would need to have backreference support here to do so.


      • #4
        We support them where we can, such as the Find dialog, but we have varying support of RegEx depending on the area of the application you are using them. This is something we are working on.

        I'll definitely add your code example to our entry on this subject.
        Aaron P Scooter Software


        • #5
          Hacky Solution

          By the way, I figured out an alternative way of doing this without using backreferences. I figured I'd share it here in case someone else has a similar problem.

          It's a bit of a hack, but it's practical and will probably cover most cases. I just made 8 "comment" and "string" entries, like so:

          Comment=Text from --[=======[ to ]=======]
          Comment=Text from --[======[ to ]======]
          Comment=Text from --[=[ to ]=]
          Comment=Text from --[[ to ]]
          (Strings are the same, they just ommit the leading dashes.)
          This captures long brackets up to level seven, which is probably as high as anyone would go in hand-written code.