Results 1 to 8 of 8
  1. #1
    Join Date
    Feb 2006
    Posts
    68

    Default Annoying bug in 4.0 text editing

    There's a really annoying problem in 4.0 which I have only just noticed, while doing a complex series of edits on a pair of text files, where I needed to correct specific differences only.

    In a text compare, blocks of differences all have red arrows I can click on to move them from one side to another. If I select say two lines out of a three-line red block, those two lines turn dark blue and have a blue arrow.

    The problem is that if I click the blue arrow, the lines move over BUT REMAIN SELECTED in blue with a blue arrow. I do not want this: I am done with those lines and have no need of a blue arrow to copy them again. The fact that the blue arrow remains is totally wrong in terms of UI feedback, because the action has been completed, yet it implies that nothing has happened and that it is still ready to perform. Why would anyone want to do the same action twice? Why should it be different from clicking the red arrow, which always clears the selection?

    Worse, this 4.0 change has the side effect of hiding all the red arrows in the remainder of the file. So when I want to move the next block of red text in its entirety, I cannot do so without first clicking in the text to deselect the last blue selection. If the blue selection is several pages back, there is no indication of why the red arrow is missing.

    The extra click is a simple workaround but it completely disrupts ones work pattern when performing a complex set of similar edits. I can send you screen shots if my description is unclear. I have verified that the same operation in 3.0 (with a manually selected green block) correctly clears the selection when completed.

    Please fix this, or I will be unable to continue using version 4. And if there is some weird reason why you think retaining the selection is a good and worthwhile new feature, please consider adding a tweak for those who disagree!

  2. #2
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,786

    Default

    Hello,

    Thanks for the report. The current behavior is following a more consistent logic of Selection, in the same way our other commands wouldn't cause a deselection to occur, or to mirror how a selection and copy is handled in other views. We will need to weigh this against the convenience of dismissing the selection after using a gutter selection copy. We'll look into if we can re-enable this behavior or if it might be disruptive to any other assumptions we've made while cleaning up our selection handling.
    Aaron P Scooter Software

  3. #3
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,786

    Default

    Also, one of our developers asked if the File Format option to Treat Lines as Independent would meet your needs?
    Aaron P Scooter Software

  4. #4
    Join Date
    Feb 2006
    Posts
    68

    Default

    I tried making lines independent, which is of no use whatsoever, since it eliminates entirely the ability to copy blocks. Most of the time in text editing I am moving whole blocks. The fact that the occasional copying of gutter-selected lines behaves completely differently is what makes it so annoying. I cannot believe that you can seriously claim that the change has improved consistency or cleaned anything up. Selection perhaps now works similarly to something in another area of the program, but that is only consistency as seen in discussion during a design session. What has happened is that you seem to have destroyed consistency in everyday use, within a single area of operation. I think it needs to be fixed, rather than weighed up!
    Last edited by tfrost; 18-Jul-2014 at 05:51 AM.

  5. #5
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    11,786

    Default

    Thanks for the feedback. I assumed the File Format option would probably not meet your needs, but one of our developers wanted to suggest it on the off chance it might help.

    The previous behavior may not have been entirely intentional, and when our developers re-implemented selection in BC4 we got the current behavior. We'll need to investigate what is involved in implementing the BC3 behavior and make sure it doesn't collide with any of the other BC4 re-implementation logic; it's not quite as simple as reverting, but we'll look into it.
    Aaron P Scooter Software

  6. #6
    Join Date
    Feb 2006
    Posts
    68

    Default

    Thanks for the explanations, and for looking into it.

  7. #7
    Join Date
    Oct 2007
    Location
    Madison, WI
    Posts
    4,669

    Default

    The selection behavior is fixed in Beyond Compare 4.2.4.
    Chris K Scooter Software

  8. #8
    Join Date
    Feb 2006
    Posts
    68

    Default

    Very many thanks for acknowledging this as something that needed to be 'fixed'! It's a great usability improvement, despite the fact that it took you three and a half years....

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •