Compare Plugin 1.5 released

2007-11-29
2012-11-13
1 2 > >> (Page 1 of 2)
  • Just wanted to put up a post to let everyone know that the compare plugin has been updated.

    A lot of improvements have been made over the past few weeks, so check it out and please let me know if you experience any bugs.

    You can grab the latest version from here:
    http://sourceforge.net/project/showfiles.php?group_id=189927&package_id=244011

     
    • I see some nice additions!

      I tried "Compare to last save", that's what I would call it instead of "Show changes since last save". It's a compare plug-in right, not a "show changes" plug-in.

      I really like this feature. However, when my files match, after clicking OK to that message, the second view is closed immediately. Perhaps you could make this optional. At first, I wouldn't expect the second view to close, then.

      Secondly, the second view isn't shown in the same language as the source document. If you could add this also, that would be very nice. Please make sure the language is the same as the opened document's, which is not necessarily the same as the file's extension. It may have been set to somethinig else in N++.

       
      • Great work!  Here's the problems I had:

        It found all the differences (whole lines were transposed in several places) but I got confused because the last character was always missing on one of the lines - so I thought this was the problem/difference.  I had to open the files elsewhere to see that no character was actually missing.

        Today I opened a file to compare with the one I was editing.  No lines were the same. I went to close the second file I had opened but there was no way to close it until I right-clicked on its tab.  After I closed it, my original file had 800 blank lines in it where the other file "was".  This all didn't seem too graceful - until I saw the way to close the plugin is plugins->compare->clear results.

        it's very important to have.

         
        • I'm not sure what you mean about the missing character. Could you please email me with some more details?

          thanks

           
          • I would be illegal for me to show any of the exact data but I can provide a better description.

            Say I was comparing two files (!!!but I just realized that all line in both files end with CARRIAGE RETURNS ONLY and not Windows carriage return + newline):

            file 1:
            ----------------
            a dog
            a rat
            a cat
            ----------------

            file 2:
            ----------------
            a dog
            a cat
            a rat
            ----------------

            The difference of course being the rat and the cat are on different lines - which the plugin correctly identifies.
            However, on one of the lines being shown as different, the last char is missing:
            for example: "a ca", instead of "a cat" (and I discovered when I "Show end of line" in N++ that cat is actually ca[CR][LF], ie, ca+carriageReturn+lineFeed)

            So I thought one of the files had "a ca" in it but it had "a cat", the difference (between the files) is that the lines where transposed.

            The actual files where about 900 lines long and lines are roughly 100 to 200 characters long.  The caveat I see is that I had manually changed to the end-of-lines to carriage return only (actually I had had to remove all newlines from the files).  I can change the line ends back to Windows format but I hadn't because everything else (including Excel) I was using on the files worked without a hitch so I left them as is.

            So exactly now I just ran the plugin again the sample file data shown above (after saving them in Mac format, ie, carriage returns only) and you can see even stranger results than I described.  So this is reproduceable.  I'm almost sorry for finding all this out.
            Thanks - I wish I would have given better info the first time around.

             
    • Actually, I am beginning to wonder now what the use of this Plug-In may be, reading the first note:

      "Using or clearing the compare plugin will cause the undo buffer to be cleared. Unfortuntely, by adding lines, the editor no longer knows where the edit was, and would put it in a random spot."

      So, I can compare my edited file to the last save, notice what is different and then, when clearing the Compare Plug-In, start all over again??

       
      • Perhaps you could simply create two new documents when comparing with the option Match Lines. This would leave the edited document and its undo buffer intact. This may even be of help in editing the document itself, while the compared copy still has the change marks.

         
    • Thanks for the name idea. I'll go ahead and change it in the next release.

      Dang, I didn't release anyone actually read those notes! Despite how it sounds, English is my native language, I promise! ;p

      Thats a good point about the undo changes being cleared for save comparison. I can't create two new documents, because than you'd have no way of identifying which document was which. What I think I'll do is temporarily disabled the "Align Matches" option when you compare against the local version or the SVN base, so that you don't have to worry about losing the undo/redo list.

       
      • Can't you (re)name the newly opened documents, perhaps by storing them in a temporary folder? It's a real pity we can't _name_ documents beforehand, without saving them. This would help a lot... Funny, I'm thinking it in fact _is_ possible to rename documents, when a Save As fails. The result _will_ be a change in the name of the document... So I guess it is possible to achieve this. You could simply name the comparison version "Copy of ...", "Comparing ..." or alike.

        Isn't it possible to set an undo marker simply at the current state and then end this undo action after aligning? I'm thinking calling StartUndoAction() and EndUndoAction() once "manually" could work...

         
    • As a plugin I don't have the ability to open files or do save as. So I can't change the name of the window. Its a slight inconvenience, but I think it was the right decision on Don's part.

      If I could open or save files without user input, than at the very least, this would result in the "Last Operation Directory" getting screwed up and and subsequent opens or save as's would open in a random directory for the user. At worst, it could cause permission errors when trying to save to a directory its not allowed to, or result in the user's real document being placed in a place they don't know about and all of their changes being lost.

      There is a way to store the alignments in a single undo action. But than when the user called undo, it would just take all the lines away, which would result in the wrong lines being marked as blank and removed on clear or save, or if they tried to undo after clear was called, it would put a lot of lines back in the document that they would have no way to remove!

       
      • Typically, when the undo buffer is cleared, the file can't be saved. So, when one is content about the changes compared to the source file, some other actions are needed to save the improved version. I have this with normal editing, too, sometimes. If a file is changed externally, for instance, and I want to restore the correct version from Notepad++ I have to type in something, remove that (not undo!) and then I can save the file as it was before, again.

         
      • Well, I'm not sure if the file actually gets renamed when Save As failed. I did notice that the name on the tab in fact did. So perhaps it is possible to only change that name, in some way. Furthermore, I would suspect simply using another directory to be possible, without screwing up the current/last operation directory. Or, you could store it and set it back after the action.

        Can't you simply _undo_ you align actions when clearing the Compare Results? I think that would be the way to go, leaving the user with nothing (to undo) that he himself didn't do. You would have to remember if the Align Lines option was set when comparing for that, but I guess that is not the problem.

         
    • I could undo the changes when clearing the Compare results, but in order for that to work I'd have to ensure the the user did not make any changes during the compare. So, both documents would have to be set as read only.

      And you're right about the clear undo buffer preventing the user from saving. I had to get around that by replacing the first letter with itself, so the undo buffer would not be completely clear and the document could maintain its "dirty" state.

       
      • > I could undo the changes when clearing the Compare results, but in order for that to work I'd have to ensure the the user did not make any changes during the compare.

        I think this problem is not limited to the Align Matches option, is it?

        > So, both documents would have to be set as read only.

        Well, if you want to keep the Compare Results, while allowing the user to change things, I think the best way is to separate the edit version and the compared version. So this pleads for creating two new documents for each comparison (possibly read-only). This would also prevent documents to be moved in the tab order, when the Compare Results are cleared. I now feel a growing wish for an option "Close Compare" instead of Clear Compare Results. When the comparison is closed, simply remove the newly created documents. They don't interfere with any user action then.

         
    • No, the problem is only limited to Align Matches. If align matches is disabled, or there if there isn't a need to align them, than the undo buffer is not cleared.

      For that reason, it would make the most sense to disable that feature when using compare with last save, or compare with SVN base.

       
      • Of course, I do not advocate limiting functionality to some specific options.

        I meant to say that a user can also edit a compared document, if it is not match-aligned. Wouldn't that (possibly) mess up the marking also? It may not be a problem to remove the marking on Clear Results, but then I don't see how this would interfere with the undo buffer problem when aligning matches, as you seemed to say before. The marking would be no problem and I think putting all added lines into one undo action would allow removing them all at once again on Clear Results. You could then set the read only flag of the original document (only) when Align Matches is checked. Be careful, however, not to simply _clear_ this flag afterwards, but reset it to the state it was before. (A file may already have been marked in Notepad++ and be compare to the externally changed version.)

         
    • Marking lines and styling do not affect the undo buffer. So the user can add or delete as much as he wants, and while it might cause some line to be marked as a change or insert, when he clears the compare, all the markers are just removed but the actual document is the same.

      heres an example of the added lines problem:
      lets say you have the document
      1
      2
      3
      4

      and you change '3' to '5'. the undo buffer saves something allong the lines of "pos 3 changed from 3 to 5"

      now you compare the document, and you get:

      1
      2
      (added Line)
      5
      4

      if you tried to undo, it would replace pos 3 with '3'

      1
      2
      3
      5
      4

      which is clearly not what you'd expect.

      If the document was readonly during the compare, than we wouldn't have to worry about this problem, because the undo buffer would be in sync after the compare was cleared.

      So the question is, is it better to not align matches and let the user freely edit their document.
      Align the matches, but sacrifice the undos
      Or align the matches, but prevent the user from editing until the compare is cleared.

       
      • > There is a way to store the alignments in a single undo action. But than when the user
        > called undo, it would just take all the lines away, which would result in the wrong
        > lines being marked as blank and removed on clear or save, or if they tried to undo
        > after clear was called, it would put a lot of lines back in the document that they
        > would have no way to remove!

        If you could somehow force both actions to take place at once, that is remove all added lines _and_ remove the marking, then there would be no problem. Since it may be welcome te be able to edit while comparison results are visible, I still think the best way to do this is, is show the comparison results in a separate document. This would leave the source document intact, not interfering with the undo buffer, not moving the tab's position to another view and back to possibly another position, and not removing any selection made, which I also find annoying.

        So if you just open two new documents in multi-view, you would overcome all these problems. If there is no way to _name_ these documents (please investigate this first), I suggest inserting the name of the source document at the top of the compare document. You could also add some info there like the Plug-In version and possibly the time the documents are compared.

         
        • I want to add that I would also like the second view to have the same viewing options as the primary view, like Show all characters etc. That is, if it there wasn't already a document opened in second view. For a comparison it would of course be very logical to have the same viewing options for both views (but which one to choose from the two views, if already present?).

          I also noticed Wrap lines is _un_set when doing a comparison. This setting isn't restored when the comparison is closed.

          Furthermore, I was tricking around a little. I changed one file, I chose Compare and the multi-view showed me two (totally different) document. I then selected the document in the primary view and chose Compare against last save. Now I got another document in the second view, but the previously compared second document (the first document in the second view) still had its comparison markup. After Clear Results, the markup of all documents will be gone, but I don't know about added lines because of the Align Matches option.
          Also, the tab's disk icons still reflected a changed state, while the undo buffer was in fact cleared.

          One more naming tip, I suggest to group all three comparison options and have the Clear Results as fourth option. Also, "last save" may suggest the last save from within Notepad++. Perhaps it is better to call this "saved version/file" or "(source) file on disk".

           
    • Thanks for the tips. I don't think theres much I can do to make the viewing options the same as the primary window. In order to accomplish that, I'd have to list out every concievable option that could be changed, and than maintain that change until the compare is cleared. Something thats beyond the scope of the my little plugin.

      You're right, Wrap Lines should be restored on clear

      The tabbed interface quickly complicates things. If you choose compare without two panels already open, all I can do is call "Go to another view" and hope for the best that the two resulting panels contain what you want to compare.

      It sounds like your second issue with the panels is a valid result. I assume the user might want to compare more than one document at a time, so the plugin does not enforce that the results of the previous compare be cleared before starting a new one. The clear results uses the markers to detect added lines, and not internal data, so clear will always remove the extra added lines, even if its 20 compares later

      I like the new name idea. Truth be told, my main purpose for that feature was so I could see what changes an other application made before I reloaded, and "Compare with (source) file" makes a lot more sense for that.

       
      • You're welcome.

        > It sounds like your second issue with the panels is a valid result. I assume the user
        > might want to compare more than one document at a time, so the plugin does not enforce
        > that the results of the previous compare be cleared before starting a new one. The clear
        > results uses the markers to detect added lines, and not internal data, so clear will
        > always remove the extra added lines, even if its 20 compares later

        Is this still true if I compare the same document over and over again with other documents or files, possibly editing it meanwhile?

         
        • How about this?

          I was comparing two scratch files to get a feeling of the differences between them.
          I closed both files.

          Then I cleared the compare results.
          This opened a new document and seemed to have no further effect.
          Although this is not bothering me much, it doesn't seem necessary (or right).
          Next to that, how about all those "remembered" different lines?
          Will they leave a residu somewhere, if the results aren't cleared before closing?

           
          • No, it should be safe to close a file without clearing. The plugin doesn't maintain any information once the compare is finished

             
    • two plugins is most used by me. compare plugin is one.  another is explorer.

       
      • Thanks! I'm glad you like it :)

         
1 2 > >> (Page 1 of 2)