Announcement

Collapse
No announcement yet.

13298 Mystery mismatch

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by Aaron View Post
    That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it, which would make it harder to read.
    Whereas currently it is impossible to read as a match. Please record my request to remedy this failure to accord with documentation and common sense.

    Meanwhile, is there a workaround? I.e. a way to get BC to show all matches?

    PS It would have been useful to have received this information fifteen messages ago when I asked the question.

    Comment


    • #17
      Re http://img844.imageshack.us/img844/4...gnment0nor.png

      Aaron wrote*:
      Thanks, Chris. I added these to our test cases. In this specific
      example, the issue is that the alignment aligns the 0 in an unexpected
      location. The alignment step happens before the text replacement step,
      so by being misalighed, the text replacement does not match the text
      sections.

      Improving our intra-line alignment is on our wishlist. The only
      workaround available in this case would be to mark "\30s\Loud" as an
      unimportant grammar instead of using text replacements.
      Thanks.

      But re "The alignment step happens before the text replacement step, so by being misalighed", are you sure, Aaron? Replacements represent file changes, so surely they must be applied first, if they are to work properly??
      Last edited by chrisjj; 23-May-2011, 06:53 AM.

      Comment


      • #18
        The alignment does occur before the replacement. Expanding and improving replacements is on our wishlist, but the replacement does not currently try to push the alignment.
        Aaron P Scooter Software

        Comment


        • #19
          Originally posted by chrisjj View Post
          Replacements represent file changes, so surely they must be applied first, if they are to work properly??
          Replacements represent optional file changes. When we were working on the feature we considered both approaches and decided on the current one.

          If you have these two files:

          Code:
          apples                 | apples
          apples                 | bananas
          bananas              | bananas
          The first and last lines should appear as exact matches.

          With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line.

          If, instead, we apply the replacements first, internally the files would be represented as:

          Code:
          bananas             | apples
          bananas             | bananas
          bananas             | bananas
          Which would cause problems with the first line. Doing replacements beforehand also causes problems if you have strings like:

          ababababab

          And you want to replace "aba" with "c". In that case you'll end up with something like:

          cbcbab

          The second and fourth "aba" substrings won't be replaced correctly because they've already matched a replacement. The current behavior allows the "c" replacement can occur for any of the "aba" substrings.

          We may support doing pre-replacements at some point, but the current behavior is intentional. On the other hand, the initial alignment should be improved to better group characters, and if it did you wouldn't have had any problems here.
          ZoŽ P Scooter Software

          Comment


          • #20
            Originally posted by Craig View Post
            Replacements represent optional file changes.
            Not according to the documentation, Craig.

            Originally posted by Craig View Post
            With the current behavior, you can add "apples => bananas" as a replacement and it will only affect the middle line
            Aha. I don't think keeping that info from users was a smart idea.

            Originally posted by Craig View Post
            If, instead, we apply the replacements first, internally the files would be represented as:

            Code:
            bananas             | apples
            bananas             | bananas
            bananas             | bananas
            Which would cause problems with the first line.
            That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

            Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.

            Originally posted by Aaron
            improving replacements is on our wishlist
            Thanks. Good luck.

            Comment


            • #21
              Originally posted by chrisjj View Post
              Not according to the documentation, Craig.
              The documentation doesn't say one way or the other. At best, it says they're changes that "should" be considered unimportant, not "must".

              Originally posted by chrisjj View Post
              Aha. I don't think keeping that info from users was a smart idea.
              What, that we made a design decision? We make thousands of decisions about how features should work; we aren't going to document all of the things we decided not to do.

              Originally posted by chrisjj View Post
              That's a faithful execution of the Replacement the user asked for. That's exactly what I want as per "Replacements identify repetitive changes that should be considered unimportant."

              Craig, I cannot imagine when I would find it useful for BC to apply my replacements "optionally". Replacements are no use to me if I cannot trust BC to apply them consistently.
              As I said, we considered both approaches, and we believe that the current behavior is better in more cases. You're welcome to disagree, but you're not the only one we're designing BC for. In source code changes are frequently on a subroutine-by-subroutine basis, rather than over the entire file, so the current behavior is better since it isn't introducing differences that aren't there.

              I'm sorry the current behavior doesn't work for you, but adding the alternate approach is a fairly complex feature and I don't expect us to get to it soon. BC has find and replace support and updates the comparison as it does so, so you can do a global replacement yourself to eliminate them as differences.
              ZoŽ P Scooter Software

              Comment


              • #22
                Originally posted by Craig View Post
                it says they're changes that "should" be considered unimportant, not "must".
                Cute.

                Originally posted by Chris
                Aha. I don't think keeping that info from users was a smart idea.
                Originally posted by Craig View Post
                What, that we made a design decision?
                No - that BC may decide not to apply the user's Replacements.

                Comment


                • #23
                  Originally posted by Aaron View Post
                  That specific coloring is because BC3 does not color single character matches (checker-boarding). If it did match and color it, the "s\30s\Loud" would have a single black character in it
                  For the record, that is exactly what I do see when BC is working better e.g. at the caret here:

                  Comment

                  Working...
                  X