U++: Issueshttps://www.ultimatepp.org/redmine/https://www.ultimatepp.org/redmine/redmine/favicon.ico2011-06-27T19:38:34ZRedmine
Redmine Bug #63 (Rejected): Peculiar behaviour of RichEdit when text begins with a tablehttps://www.ultimatepp.org/redmine/issues/632011-06-27T19:38:34ZTomas Rylekrylek@volny.cz
<p>RichEdit exhibits strange behaviour when the text begins with a table. It is impossible to select the whole text, the table cannot be deleted using clipboard operations (select & delete / cut).</p>
<p>Apparent reasons: 1) in RichEdit, the internal mechanism switching between "in-table" selection and "cross-table" selection fails for an initial table; cursor position 0 (beginning of text) has a non-zero table nesting level and RichEdit::FinishNF automatically switches to "in-table" selection where the selection is naturally limited to a single table.</p>
<p>2) In RichText, RichTxt::Paint switches between "in-table" and "cross-table" selection display by comparing text position range within the table with active selection range; cross-table selection display is activated only when selection begins <em>before</em> start text position for the table. Naturally, when a table starts at position 0, there are no text positions before the table.</p>
<p>Recommended action: 1) I believe the current selection mechanism using linear text positions can be kept intact with only slight extensions of its semantics. Selection manipulation functions should always operate on the "table level" corresponding to the lowest nesting level over all characters within the selection; to make things simple, such a selection should not start or end in the middle of a nested table - within the RichTxt object corresponding to the lowest nesting level within the selection, initial and final selection positions must correspond either to beginnings of individual parts or they must point into a RichPara-part of the RichTxt object. In fact it shouldn't be very difficult to relax even this rule, i.e. to allow selection to contain portions of initial and final tables, but implementation of the selection operations would have to be a little more tricky.</p>
<p>2) With this extension, it should be easy to patch RichTxt::Paint to correctly highlight a cross-table selection starting at first position in the table.</p>
<p>3) RichEdit::FinishNF must be patched to detect cross-table selection (currently the selection is automatically marked as in-table whenever the anchor position corresponds to a table, except the peculiar case when cursor text position corresponds to a deeper table nesting than the anchor, btw. I don't get this) and to adjust selection boundaries in correspondence with the above rule.</p>
<p>4) RichEdit cursor movement functions should be extended to allow switching from the "in-table" to "cross-table" selection when the whole table is selected and the user moves the cursor right or down from the rightmost cell while holding the Shift key (RichEdit::SelCell). The opposite direction should be also allowed (cross-table selection beginning at the start of a table should change to "in-table" when the selection span gets limited to the initial table object).</p>
<p>5) It is questionable whether the situation couldn't be improved by introducing another special pseudo-character which would correspond to the beginning of a table. This would allow to distinguish between the position just before the table and at the beginning of its first cell and could remove some of the current irregularities like inserting a paragraph before the table at text beginning. Also, in-table and cross-table selection would be easy to distinguish (cross-table selection would start before the "table beginning" character whereas in-table selection starting with first cell would start after it) and RichTxt::Paint wouldn't have to be patched at all.</p>