One often performs certain actions in an LO Writer document, then navigates elsewhere in the document (e.g. another page), so that the area where the changes took place is not visible. Currently, if one then undoes the action (e.g. Ctrl+Z or using the menus), the document is scrolled to an appropriate position, and the action is undone. (I am ignoring the case in which the action affected a large area which does not fit in the window.) That's not the only possible behavior. Various applications, upon being asked to Undo in the scenario described above, only perform the scrolling / changing of the viewport to the area surrounding the location of the last change; and pressing Undo again actually undoes the action, this time without the need to scroll. I suggest that such behavior be adopted for LO as well. It is IMHO intuitive enough; causes less 'surprises' of an Undo doing something different that what the user was expecting; and has the added benefit of making it easier to review the last change before going ahead and undoing it.
(In reply to Eyal Rozenberg from comment #0) > ...Various applications... only perform the scrolling / > changing of the viewport to the area surrounding the location of the last > change; and pressing Undo again actually undoes the action, this time > without the need to scroll. Got examples?
(In reply to Heiko Tietze from comment #1) > (In reply to Eyal Rozenberg from comment #0) > > ...Various applications... only perform the scrolling / > > changing of the viewport to the area surrounding the location of the last > > change; and pressing Undo again actually undoes the action, this time > > without the need to scroll. > > Got examples? Eclipse - an IDE. Kile - a LaTeX editor. CLion - an IDE.
[Automated Action] NeedInfo-To-Unconfirmed
> > Got examples? > Eclipse - an IDE. > Kile - a LaTeX editor. > CLion - an IDE. I tried this with applications that are not editors/IDEs: Affinity Photo (Image manipulation), Inkscape (Vector Drawing), TextMaker (Word Processing). None of these applications showed the behavior. I understand that such behavior might be useful – seeing what changes makes sense. However, there are difficulties like potentially erratic scroll behavior, timing of the change (probably one would first scroll, then very shortly after execute the change?) and the question of how to return to the starting place and other possible surprises. It thus seems to be a costly feature to implement and one that would need extensive testing. So I would either wontfix or keep it as a potentially interesting idea on low priority.
(In reply to jan d from comment #4) > I tried this with applications that are not editors/IDEs: Affinity Photo > (Image manipulation), Inkscape (Vector Drawing), TextMaker (Word > Processing). None of these applications showed the behavior. I don't know about TextMaker, but for the other two, it typically makes no sense, since, since there's no linearly-scrolled document to go back and forth in (AFAICT). > I understand that such behavior might be useful – seeing what changes makes > sense. > > However, there are difficulties like potentially erratic scroll behavior, Can you explain what you mean? Why would the scroll behavior be erratic? It's like when you click a cross-ref link. > timing of the change (probably one would first scroll, then very shortly > after execute the change?) Ah, actually, sometimes you would make the change - but sometimes you would decide not to. And here's the best thing, which is a completely bonus feature: You can use "undo" to get back to where you last edited if you don't remember where it is :-) > and the question of how to return to the starting > place and other possible surprises. You don't return to the starting place - which is the same as the behavior we have now. Undo means undo. But - you first undo your last move away from the change, then decide if you want to undo the change as well.
We discussed the topic in the design meeting and decided to not change the current behavior. Reasons are + leads to inconsistency (in view vs. out of view) + unexpected for long-term users + not applying Undo does not always makes it clear what exactly has been changed (for example, if you delete one word on a page you wont see it before you undo) + we give feedback by highlighting the undone part + the example are highly structured
(In reply to Heiko Tietze from comment #6) > We discussed the topic in the design meeting and decided to not change the > current behavior. You should really consider inviting conversation-capable contributors to such meetings. Last time I was invited was reasonably useful, IIRC. But actually - last time I was invited, it was just me and you. Would you mind telling me who was involved in the discussion? > Reasons are > + leads to inconsistency (in view vs. out of view) I disagree. The consistent behavior will be that you only undo something you're seeing. > + unexpected for long-term users That is a valid point. However - it's an argument against any non-trivial behavior change. And this could also be mitigated: 1. Introduce this behavior as opt-in at first (or just forever) 2. The first time one runs Writer after an update to a version supporting this, a small dialog box comes up. > + not applying Undo does not always makes it clear what exactly has been > changed (for example, if you delete one word on a page you wont see it > before you undo) It would bring the cursor to where that word was typed in. Unless you walked > + we give feedback by highlighting the undone part No we don't. > + the example are highly structured Not sure what that means.