932
Advanced UserAdvanced User
932

    Apr 30, 2018#16

    fleggy wrote: Well, I played with my pattern and got a crash. There is definitely a bug in UE/UES regex engine and only God knows which version is not affected.
    28.gif (411Bytes)

    After apply your pattern with successful result, I also can hit UNDO without crash nor other unexpected problem.
    But I'm still confused why that string runs well for some data and runs wrong for others.

    18572
    MasterMaster
    18572

      Apr 30, 2018#17

      Gabarito, can you post here some problematic sample? I'll check the pattern in Notepad++. It is possible that I didn't think of all possibilities :)
      Thanks

      932
      Advanced UserAdvanced User
      932

        Apr 30, 2018#18

        Here you are:
        buttonsoverlay.xul (26.49 KiB)   33



        Note: I already tested it with Notepad++ and got wrong results too.
        Except if I made some mistake.
        Good luck. And tell us the truth about that mystery. 🙂

        18572
        MasterMaster
        18572

          Apr 30, 2018#19

          Well, some links do not start with http(s). This pattern works for me:

          F: (?s)(?:(?<!loadURI\(&quot;).)++((?:(?!&quot;).)++)|.*
          R: \1\r\n

          Thanks, Fleggy

          932
          Advanced UserAdvanced User
          932

            Apr 30, 2018#20

            SOLVED!

            Thank you, Fleggy.

            clapping.gif (2.15KiB)

            6,624550
            Grand MasterGrand Master
            6,624550

              May 01, 2018#21

              Fleggy, I executed the three Perl regular expressions posted by you on the three sample blocks posted by Gabarito (ANSI, DOS) and the attached XUL file (UTF-8, UNIX) using UE v25.00.0.68, v24.20.0.62 and v22.20.0.49 (32-bit versions).

              F: (?s)(?:(?<!loadURI\(&quot;).)++(http(?:(?!&quot;).)++)|.*
              R: \1\r\n

              This first posted expression makes a quite good job as long as a URL starts with http. On first occurrence of a URL after loadURI(&quot; not starting with http the Perl regular expression engine makes the right job: it back tracks to beginning of already matched string and applies second OR argument .* to match greedy everything up to end of file. Therefore the result of running a replace all with that expression is wrong if there is any url not starting with http in file.

              Next I should run tests with:

              F: (?s)(?:(?<!loadURI).)++\(&quot;(http(?:(?!&quot;\)).)++)
              R: \1\r\n

              This expression is really a problem for the Boost Perl regular expression library on first occurrence of a URL not starting with http. It looks like the library runs into loop after finding loadURI(&quot; without http on finding out where in characters stream to restart the search causing more and more usage of stack memory until limit reached. This expression works on the small sample blocks producing the result according to expression, but on XUL file the block after first URL not starting with http is too large and the result is the error message:
              The complexity of matching the expression has exceeded available resources.
              The third expression posted is:

              F: (?s)(?:(?<!loadURI\(&quot;).)++((?:(?!&quot;).)++)|.*
              R: \1\r\n

              And this one without limitation of URL must start with http works fine for the sample blocks as well as for the entire XUL file with all three versions of UltraEdit with the minor exception of producing a blank line at end of file because of replacing file content after last URL by a carriage return + line-feed instead of nothing to just remove that block.

              There was no crash on running the tests with used versions of 32-bit UltraEdit. The Undo command worked also always fine without verifying if it really restored original file content always 100% correct. But I would not be surprised if the second search expression causes a crash depending on file content, character encoding and line ending type as it cause an undefined behavior on execution.
              Best regards from an UC/UE/UES for Windows user from Austria

              18572
              MasterMaster
              18572

                May 02, 2018#22

                Thank you, Mofi

                Read more posts (-8 remaining)