oXygen: Compare files: "Next Change" behaves differently when invoked in current change block or from previous block

[dma_k]

Suppose we have a block of changes (let's call it X), which has some preceding common block A.

• When the caret is placed inside block X and "Next Change" function is invoked, the next change is correctly highlighted.
• When the caret is placed before block X (e.g. inside block A) and "Next Change" function is invoked, the next block is highlighted but not the change inside that block.

Expected: The function "Next Change" behaves the same way irrespective the caret position.

[dma_k]

Support team, I wonder if above mentioned improvement/fix is feasible? It certainly improves the productivity when there is a need to quickly push changes (left-right or right-left).

[adrian]

Hello,

I can confirm this behavior. When located before a block with multiple changes "Next Change" does indeed select the next block but not the first change inside the block.

I've logged this to our issue tracking tool. This will be analyzed and if found appropriate it will be implemented in a future version of Oxygen.

Regards,
Adrian

[adrian]

Hi,

The issue has been analyzed and this behavior is intended.

The Next Change action provides a finer granularity than Next Block when navigating, but it will also select the blocks before entering them and only afterwards will navigate the individual changes from the block. This allows you to copy the entire block when you navigate, before actually entering it.

Note that the Previous Change is implemented symmetrically. When below a block navigating to the previous change will first select the block and only afterwards navigate the individual changes from the block.

If we would change this to only navigate the individual changes and not the blocks, you would have to keep going back and forth between the Next/Previous Change and Next/Previous Block when merging the files.

Regards,
Adrian

[dma_k]

Adrian, thanks for feedback!

Hi,
If we would change this to only navigate the individual changes and not the blocks, you would have to keep going back and forth between the Next/Previous Change and Next/Previous Block when merging the files.

From your explanation I suppose that "Next Change" function is disabled when there is no active block. Anyway, the note you've made is not completely clear to me: why if "Next Change" always selects the next change, I will have to go back and forth with "Next Block"? Maybe you can provide a concrete example...

My example is following: I have blocks of changes and I need to quickly copy some changes (after reviewing) from e.g. left to right.

Currently:

• If the cursor is outside the block, I have to invoke "Next Change" function twice: once to enter the block and once to select next change.
• When "Copy Left" is applied and the change is actually inserting a newline, then the current block get unselected. That means that "Next Change" twice to select the next change. But if the change does not split the current block, then I need to press it once to select the next change.
• "Next/Previous Change" behave wrong when you reposition the caret (e.g. put the caret before the current change in current block and invoke "Next Change").
• E.g. "Previous Change" does not behave correctly after the current change is applied. For example: in the current block I have three changes. I use "Next Change" to navigate to 2nd one and "Copy Change", Now I invoke "Previous Change" hoping to navigate to previous change but I jump to the end of the document.

From functional point of view there is hardly anything to add, but usability level in general is low.

Ideally, I would like to have a function "Select Next Change" that should always select next change regardless of position (or propose to jump to next file or start from the beginning of document), so that the sequence of my actions is "Next Change", "Copy Left", "Next Change", "Copy Left", and so on. But I clearly can't do it now as sometimes I need to invoke "Next Change" twice. If I occasionally don't do it twice, then "Copy" will copy the whole block, which is a disaster without correctly working undo (see next).

And more points:

• Applying the change does not influence the Undo/Redo stack. Expected: the change is pushed to undo stack.
• I suppose that "Ctrl-S" should save both left and right files. But is saves only the current one. Is there any "Save all" function? The additional UI feature is to show, which of left/right files are changed. Currently there is no indicator (e.g. on status bar), so the user can't be sure everything is saved on Ctrl-S.

If you wish, I can start some of above mentioned points as separate threads.

[dma_k]

Just want to add: all mentioned in my previous post concerns the copying of changes from right to left, with caret being in the right file.

When the caret is in the left, the merging works smoother.

[adrian]

Hello,

From your explanation I suppose that "Next Change" function is disabled when there is no active block. Anyway, the note you've made is not completely clear to me: why if "Next Change" always selects the next change, I will have to go back and forth with "Next Block"? Maybe you can provide a concrete example...

"Next change" is not disabled if there is at least one change(even when outside a block).

Note that there is no "Copy Block" action, the "Copy Change" actions can copy a block if one is selected, not just the individual changes.
If we would modify 'Next change' to only select changes and not blocks, you would not have the opportunity to copy the entire block should you want to. So, you would have to either:

• copy the individual changes from the block(you can have multiple changes in a block so it can be tiresome)
• navigate with the Next/Previous Block to select the entire block and then copy it. This is why I said you'll have to go back and forth between the two groups of actions.

There is a problem with the Previous Change action after a block gets split. I've logged this as a separate issue.

The undo is working correctly, but each editor has its own undo stack. This means you first have to focus the appropriate editor and then invoke the undo action for that editor. This allows you to undo only the modifications you made on one side while preserving the ones from the other side.

The same applies to Save(Ctrl-S), each editor has its own save action, so you have to focus it before saving.
A "Save All" action would be appropriate. I'll log this as an improvement request.

The modified marker state is another possible improvement, but Oxygen doesn't restore its unmodified state after undoing all changes.
If you close the window you will be prompted to save so you won't lose any modifications.

Regards,
Adrian