It's really not obvious *what* you can get here.

Change-Id: I1f14b851a127847206f8eb5fd2da778d0acece9b

This is used by Ctrl+Up/Down.

Just iterate movement in SwCursorShell::MovePara() until the point
is at the start (or end) of a frame.

Change-Id: I8abab57f1b549a3d585a385181cf734d73a0286a

E.g. Ctrl+Left/Right, Ctrl+Shift+Del/Backspace, double-click to select
word...

These are all implemented in SwCursor, so they need a layout passed to
them from the SwViewShell.

There was a bug in the while loop in SwCursor::GoSentence() case
NEXT_SENT that triggered assert in the mapping code when the
endOfSentence() returned the length of the SwTextNode but then it was
incremented once more.

Change-Id: Ic3866860a8c07774dce35952271c207eb6e7d182

Actually it already works, this is just a clean up to pass in the
SwCursorShell's layout...

Change-Id: I1a90bbe9966c7f4d5b5e959122ca1f995df93a45

Just put a loop in SwCursor::LeftRight() to repeat a movement if
it didn't actually advance the text frame index; the
SwContentNode::GoPrevious()/GoNext() take into account hidden text
attributes from SwScriptInfo, so this ought to result in end
positions that are neither hidden by attributes nor by redlines.

This requires passing the layout to SwCursor.

Change-Id: Ieb623840f6390fa6f1c78b7458ad8dc6523a2744

This never splits or joins nodes, so it needs yet another different code
to keep the merged text frames up to date.

Change-Id: I151edcec9db34c64bf3a29ecad4396d95669d1c9

This needs to recreate the frames on the node preceding the deleted one,
in case the second node of the join wasn't merged like the first was,
but is merged afterwards...

Change-Id: I001ba3af118614c1cce891cf6faec7e829576d21

There is a special case where the redline that is inserted doesn't have
a valid range and then it's split up inside AppendRedline(), in
SwRedlineTable::InsertWithValidRanges().  This happens for example
with a selection that includes a section start node but not its end node
(or vice versa).

This breaks the UpdateFramesForRemoveDeleteRedline() /
UpdateFramesForAddDeleteRedline() because they assume that the given
range is one SwRangeRedline; the result is duplicate text frames.

This could be worked around by iterating the SwRangeRedline in the given
PaM, but for the Remove case there is the additional complication that
the redlines are actually removed by the time the function is called.

So rework the implementation of DeleteAndJoinWithRedlineImpl()
to call the part of InsertWithValidRanges() that does the splitting
into multiple redlines (extracted into new sw::GetAllValidRanges())
and create multiple SwUndoRedlineDelete actions, each of which now
updates the frames properly.

Also clean up the horrible group-undo code to group before inserting,
instead of after-the-fact cleanup.

Change-Id: Ia279910e0c74edabe56b0c4cf87dbbad688179da

If there's a table or section affected by the editing operation, then
it has to be ensured that the table node / section node has its flag
reset on Undo; also the next text node following the table, as
CheckParaRedlineMerge() isn't called for table nodes.

Change-Id: Ic1b085619adbeba69fa641a3a7492b71966fee6e

Other callers need this too, particularly Undo, so move this into the
function so it's done once.

Change-Id: I58e89899127650157fe2889929c1c6b47c00649b

Re-use some code that is already used elsewhere; for the
UpdateFramesForAddDeleteRedline(), the same code as for switching
the layout to Hide mode should work, for
UpdateFramesForRemoveDeleteRedline() use the code that is used for
SwTextNode::SplitContentNode().

Change-Id: I97601bfb63478cc999cf7017da0225b2dc62ad37

This is called in 2 situations, from ClearDoc() and from SwDoc dtor.

In the latter case, there is no window any more, and in the former case,
surely something else must have invalidated it already.

Change-Id: Ideecdeb145171a4dafbec50a04d4ec5aa2acab82

* test more than 1 paragraph, by calling SplitNode()
* enable Undo, because that's the more usual situation
* remove one mode that is identical to the previous one
* use SwUnoCursor because plain SwCursor isn't corrected when nodes
  are deleted
* create a selection before calling Delete functions

Change-Id: If406bd8c37b005e431fbaebe82f297b051da1ed3

At least with the randomised test, it can happen that deleting one
redline will recursively delete other redlines that are located in
the hidden content section of the redline, or at least try to and
crash because those have already been deleted before.

The callers will either delete 1 redline, or delete all of them
via DeleteAndDestroyAll(), so put a safer loop into
DeleteAndDestroyAll() and have DeleteAndDestroy() only delete 1.

Change-Id: I9c4225544a43a4a03f4eb7b6f56e7fe848c8ca54

... it's at the end of the node already, similar to CanGrouping().

Change-Id: Ic7c6f5caa6e69e9414112cb245db97fd5d79e87d

... characters; if the character is inserted at the end of the node,
the aPam end position will have an invalid index Len()+1 and
the DeleteRedline() will correct existing redlines onto that index,
which will assert later.

Change-Id: Ia31cd1937385fb10fd284e7add61c39f96b917ab

The problem is that SwIndexReg::Update will correct a 1-character
redline in the middle of the newly-inserted part of the overwrite string
into a 0-length redline, which then a later SwTextNode::Update() will
correct in such a way that the whole thing becomes unsorted.

Just delete redlines in the entire overwrite range, which should help;
the aPam actually deletes them in the *last* character only which
seems rather unintentional anyway.

Change-Id: I61b6b312998e0779651d30f636312ef13556428c

... start or end outside of the body in randomTest().

Also, it would be more interesting to delete parts of the one
paragraph, not always the whole thing.

Change-Id: I782bcde24e0ed542c32ae50b50997555fd32813f

When Delete redline is created, removed, accepted, rejected & undo/redo
of all of these, update all the text frames so they're merged or not,
as required.

Change-Id: I08aa6aea270a50d19f4bda0caf016870a42a8dd3

Change-Id: I82893951b6e227ab1ed6423e08a0370561482cd8

The problem is that the SwInsText/SwDelText do not transfer the
"deleted-ness" of the text from one node to the other in the
SwTextFrame, so add a new hint that is sent after SwInsText & before
SwDelText to move the info that is in the extents vector.

Change-Id: I32d8dbe52a18556d8dc2c50a47246a6600fdb355

DocumentContentOperationsManager::DeleteRange* functions should call
CompressRedlines after sw_JoinText, because otherwise if there's a join,
the FillSaveData in SwUndoDelete ctor will split redlines that contain
the selection into 2, and they won't be recombined although CanCombine
is true for them.

If you do 2 operations, then on Undo of the second, SetSaveData
will restore the previous redlines and join them into 1, but then it will
assert because it expects 2 redlines, pointlessly split.

Change-Id: I1df3f2205b4f16904f66b5af1f3b9f0ccbaf24a0

This is problematic because of the calls to SplitNode.
Ideally we'd want the SplitNode to create merged frames already, but
that doesn't seem to be easy to achieve; several problems with this are:

1. the redlines are only restored at the end of UndoImpl
2. even if we store another set of SwRedlineSaveDatas right before the
   Join (while preventing the first SwRedlineSaveDatas from deleting
   them), and restore them by passing a closure to SplitNode, there
   are complaints about empty redlines, and also this case isn't
   handled properly:

     f<delete start>o<redline start>o
     b<redline end>a<redline start>r
     b<redline end>a<delete end>z

So instead, let SplitNode create whatever frames it does, and fix it up
at the end manually on the start node's frames.

This necessitates delaying the creation of the frames on the moved nodes
until the end too.

Change-Id: I8ba2967659cc2ddbe6f7c40e0447d79601498ed6

... prev. Node to the second node, if the two were merged before the
Join.

Change-Id: I047b6008c5f0bb6e79c63421a4dba09ba8cf3320

Change-Id: I9933d8b8ee29bb4da74819d7d2350a5b2b04aa09

... needs to remove extents when it's called when moving nodes to
Undo-nodes-array.

Change-Id: I32cf38074d9f3d614d5f854979be6b0135d53914

Change-Id: I132ea43397b8990c5759db66f62749df8aaa45d5

SwNodes::CopyNodes calling MakeCopy() and then immediately DelFrames()
considered silly.

Apparently SwOLENode/SwGrfNode don't actually create frames anyway since
that is done via their SwFrameFormats, so they just ignore the parameter.

Change-Id: I8a8f52da1d25bb5689345e956a33aebd727e8fc7

If there are no items left that affect the frame (which is hard to
predict for merged frames, nCount only refers to the incoming item set),
skip calling SwContentFrame::Modify().

Change-Id: I10bdb6420bcff9b89e73b6d57ebb762aa43a0648

... in SwFootnoteFrame::GetRef()

Change-Id: I5cef7c2cea41a5b246268a541afd47945603ffed

To get the extents right, first invalidate old range with Remove,
then new range with Add.

Change-Id: If46954b9bb86680ae689de742ec878e0287f58d9

Add another new hint sw::RedlineUnDelText; the main use case is to send
it from  DocumentRedlineManager::DeleteRedline() so the view is updated
accordingly.

Change-Id: Ia490116588dc8d3c695ec83c0c2ce8497736f76e

Must not move WrongList indexes for redline ops, which do not actually
insert/delete characters.

Change-Id: I965c60dad691128125ef9cdacdb388b30c9d52f3

... and skip over the redline if the start position is at the beginning
of it.

Change-Id: Ib12b459b12d49e1443257ce398963ab3ec64f2a5

... even on nodes that have no extents any more because they were all
deleted while the redlines were hidden.

Change-Id: Id6595520b1d5db030c26905b62033db68969532c

If the document is edited while redlines are shown, the node merge flags
aren't updated because only CheckParaRedlineMerge() really updates the
flags.

But CheckParaRedlineMerge() knows what the last node of a merge is,
so we can conclude that the next node then isn't merged and needs to
have frames created for it.

Change-Id: Ie9e189a2d9251910c3f5ac98a46867bbe1d91c10

... first node as not merged when there are redlines but not spanning
nodes.

Change-Id: Ieb6a5775a1f6a22874e622b10b245b7e8d61a62c

Change-Id: I818a22f286f08a842295e362fa3e10fbcb37c728

Change-Id: I17cde9fab29cf54837904db3c6e64d609aed83b0

... and footnotes that are anchored in a node of a merged frame that
follows the one that is being split to the new frames of the existing
node when the existing frames are moved to the new (preceding) node.

Change-Id: I759718c14130e6a3809dc2ca55243f3ff2eec50b