Not sure whether is a real bug but Document::GetColumn() and Document::FindColumn() doesn't handle Unicode line endings. the upper for loop should be cb.LineEnd(line) or cb.LineEnd(line) + 1 instead of LengthNoExcept() + "\r\n".
GetColumn is also bounded by pos whch must be on the line. It doesn't appear to matter for the uses that that unicode line ends return +1 compared to common line ends. A cb.LineEnd can be added but it adds work.
Many of the GetColumn are >0 so really asking 'is this position after line start' which is cheaper to calculate with IsLineStartPosition.
FindColumn will loop too far with Unicode line ends but there will be no visual effect since the calculated position is outside the line so is benign for beyond edge colouring. The edge discovery calling code knows the line length so could pass that in.
The extra calculations in DelCharBack can be hoisted although the condition could also be reordered to avoid or minimizing calculations. Its also a candidate for moving to Document except for updating the selection.
GetColumn ... seems can be replaced with some form of pdoc->FindColumn
OK.
I did previously try to move some of Indent into Document since it only really interacts with Editor by updating one selection range but didn't commit as it also added complexity. Attached the work done on this.
Here's some unit tests for a changed GetColumn. ForceLineEndTypesAllowed is a testing only API that can turn on Unicode line ends with no check, The commented out REQUIRE calls are the result from the current GetColumn and the next line is from an updated version which changes the results for positions inside a character and thus inside a Unicode line end. It changes result for beyond end from 1 to 0 which seems reasonable to me.
The two
pdoc->GetColumn()insidevoid Editor::DelCharBack(bool allowLineStartDeletion)can be extracted.The
GetColumn()insidevoid Editor::Indent(bool forwards, bool lineIndent)seems can be replaced with some form ofpdoc->FindColumn(newColumn)?both
pdoc->GetColumn()andpdoc->GetLineIndentation(lineCurrentPos)can be extracted.GetColumnis also bounded byposwhch must be on the line. It doesn't appear to matter for the uses that that unicode line ends return +1 compared to common line ends. Acb.LineEndcan be added but it adds work.Many of the
GetColumnare>0so really asking 'is this position after line start' which is cheaper to calculate withIsLineStartPosition.FindColumnwill loop too far with Unicode line ends but there will be no visual effect since the calculated position is outside the line so is benign for beyond edge colouring. The edge discovery calling code knows the line length so could pass that in.The extra calculations in
DelCharBackcan be hoisted although the condition could also be reordered to avoid or minimizing calculations. Its also a candidate for moving toDocumentexcept for updating the selection.OK.
I did previously try to move some of
IndentintoDocumentsince it only really interacts withEditorby updating one selection range but didn't commit as it also added complexity. Attached the work done on this.Last edit: Neil Hodgson 2 days ago
for edge discovery, something like following might be enough (
edgePosition >= posLineStartis always true):void SciTEBase::GoMessage(int dir)(insideSciTEBuffers.cxx) could apply similar limit.edit: previous code for limiting column parameter is incorrect due to tab expanding.
Last edit: Zufu Liu 2 days ago
Here's some unit tests for a changed
GetColumn.ForceLineEndTypesAllowedis a testing only API that can turn on Unicode line ends with no check, The commented outREQUIREcalls are the result from the currentGetColumnand the next line is from an updated version which changes the results for positions inside a character and thus inside a Unicode line end. It changes result for beyond end from 1 to 0 which seems reasonable to me.}
I'm prefer to retain current truncation behavior:
Last edit: Zufu Liu 16 hours ago
That retains the original problem with the unexpected treatment of Unicode EOLs with different results from the positions inside the Unicode EOL.