In bug 83953, the default behaviour of 'Accept Change' (.uno:AcceptTracedChange) and 'Reject Change' (.uno:RejectTracedChange) was changed to automatically jump to the next change, but we still need duplicates of the original commands that do not jump to the next change.
I wish someone could find time to work on this enhancement (or even https://bugs.documentfoundation.org/show_bug.cgi?id=38726) - it's desperately needed, for the production of high quality documents. When tracking changes, a document can quickly become so messy with the visible deltas that you can't see what it would look like with the changes applied. And if you do accept the changes, LO then automatically jumps to the next change, so in general you have a lot of scrolling to do to locate what you just did, and you lose the "visual diff" you'd get from your own short-term memory at seeing the changes applied. It makes what should be a simple task, enormously difficult. I tried simply turning off "Show changes", and using the new Changes toolbar to move from change to change. It's not ideal, though, as there is only an indication of a specific tiny change, so you get no indication of whether there are any other changes nearby. I also discovered that if you accept a change, then it also turns the Show Changes back on. Nor can you see and accept a whole bunch of changes in one operation. The workaround I've had to adopt is to introduce a spurious change somewhere below a set of changes I wish to accept/reject (like adding a space at the end of a paragraph below), then selecting the text before that, then right-clicking and accepting (or rejecting) changes. I can of course also accept/reject individual changes as I wish, so this approach gives me as a user excellent control. If I'm happy with the result, I then delete the just-added space and move to the next set of changes. Another option for the extension might be to add 3 more controls on the Manage Changes dialogue: Checkbox: turn off automatically advance to next change Next change button Previous change button.
I should probably have mentioned I'm using v 4.4.4.3.
I'm finding my workaround is working quite well, since in areas where there are many changes, there's often no need for me to temporarily introduce a spurious change just to prevent the scrolling. I do notice that there's one small improvement that would further help: if I select a range of text that includes changes, I can right click to bring up the context menu to accept or reject all the changes within. (That's an excellent feature, BTW.) But the Accept/Reject buttons on the Changes toolbar are greyed out: I think it would be a nice enhancement if they could be made available directly from there with a single click (instead of requiring: right-click, drag to option, release). Would you prefer I submitted that as a separate enhancement, however?
(In reply to Luke Kendall from comment #3) > I'm finding my workaround is working quite well, since in areas where there > are many changes, there's often no need for me to temporarily introduce a > spurious change just to prevent the scrolling. > > I do notice that there's one small improvement that would further help: if I > select a range of text that includes changes, I can right click to bring up > the context menu to accept or reject all the changes within. (That's an > excellent feature, BTW.) But the Accept/Reject buttons on the Changes > toolbar are greyed out: I think it would be a nice enhancement if they could > be made available directly from there with a single click (instead of > requiring: right-click, drag to option, release). > > Would you prefer I submitted that as a separate enhancement, however? Please ignore this - I docked the toolbar, and the Accept/Reject buttons are not greyed out, and work just fine. I also undocked it, and the same is true. So I can't reproduce it. Maybe it was user error.
I use Track Changes heavily, and I was in the habit of taking advantage of the distinction between the behaviour of the accept/reject dialogue (go to next change) and the behaviour of the context menu (don't go to next change). Things have become more difficult now that they both do the same thing. I would really welcome either additional commands, a checkbox or a preference setting. I consider the current behaviour to be a regression.
Migrating Whiteboard tags to Keywords: (needsDevEval)
I can only confirm the absolute necessity to change this »new« behavior because anyone working with large documents and wishing to read and evaluate the corrected & changed sentence or doing proofreading of an entire text wishes to stay at the current position – and NOT jump to some other place in the text he or she is absolutely not interested in at this moment. For me, working with »newer« versions of Libreoffice (showing this behavior) is currently a no-go.
I agree with what has just been added: It would be very useful for me as user be able to read the sentence for which I've just accepted/rejected a change again to see (and hear) if it's better. At least an option as has just been mentioned would be nice.
I must admit that present behavior of "Accept Change" (automatic jump to next change) makes everyday editing work truly complicated. As it was said - scrolling back pages and looking for previously verified part of text. Is there any development on the issue - so there is an optional "no jump Accept Change" ?
It might be worth reverting to the old behaviour in bug 83953 and then having this enhancement for accept/reject change with jumping, as the change seems to cause more problems than benefits.
(In reply to Yousuf Philips (jay) from comment #10) > It might be worth reverting to the old behaviour in bug 83953 and then > having this enhancement for accept/reject change with jumping, as the change > seems to cause more problems than benefits. I think thats a wise suggestion.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=583aec2552ed7f8eb22ea7ab7fff7d42e09a506d tdf#90597 Revert "Jump to next change when accepting or rejecting a change" It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Reverted the change. Should it be backported to 5.2?
I'm very pleased to see some developments going on – tried LO 5.3 alpha and can confirm that the old behavior is restored. (Some proposed to give the user the possibility to chose between the old and new behavior – I wouldn't mind any of this as long there is a button to chose the »old« behavior of remaining at the current position and not jumping to the next tracked change.) As to the question to backport the reverted change to 5.2: definitely yes in my opinion! Thanks a lot, cekilch
Backport patch for 5.2 is in - https://gerrit.libreoffice.org/28979
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=16981dd39a59d77149cbe922eb3f9a8e8fd5c6a6&h=libreoffice-5-2 tdf#90597 Revert "Jump to next change when accepting or rejecting a change" It will be available in 5.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.