Observed behaviour:
Nothing is folded, the following error message is displayed:
Tried to construct a node where the children overlap or are not distinct regions: ([227 260 12 t ([244 260 16 t nil #<overlay from 260 to 260 in nested_indentation.txt>]) #<overlay from 239 to 260 in nested_indentation.txt>] [257 269 12 t nil #<overlay from 265 to 265 in nested_indentation.txt>])
Expected behaviour:
Nodes get folded.
Fix
The origami-indent-parser calls origami-get-positions with a regex that will match from line beginning to end, including the newline at the end. In origami-get-positions the default position correction, when no fnc-pos is passed, was to go to the start of the match in Greg's original variant. Now it will move less, by substracting only (length (string-trim match)).
The intent behind string-trim is likely to move the start of the node to the first non-whitespace char of the match. I think it should be string-trim-left then, in case whitespace also exists at the end of the match, which would move the start too far to the right.
This still not fixes the indent-parser though, as it uses the untrimmed match length for determining the end, and with the changed starting positions things start to overlap. As it makes sense to have the node start at the line beginning here, I just added a fnc-pos that prevents the trimming.
Description
I encountered an error with indentation folding in a plain text file.
Reproduction
origami-modeorigami-toggle-nodeanywhereObserved behaviour: Nothing is folded, the following error message is displayed:
Tried to construct a node where the children overlap or are not distinct regions: ([227 260 12 t ([244 260 16 t nil #<overlay from 260 to 260 in nested_indentation.txt>]) #<overlay from 239 to 260 in nested_indentation.txt>] [257 269 12 t nil #<overlay from 265 to 265 in nested_indentation.txt>])Expected behaviour: Nodes get folded.
Fix
The
origami-indent-parsercallsorigami-get-positionswith a regex that will match from line beginning to end, including the newline at the end. Inorigami-get-positionsthe default position correction, when nofnc-posis passed, was to go to the start of the match in Greg's original variant. Now it will move less, by substracting only(length (string-trim match)).The intent behind string-trim is likely to move the start of the node to the first non-whitespace char of the match. I think it should be
string-trim-leftthen, in case whitespace also exists at the end of the match, which would move the start too far to the right.This still not fixes the indent-parser though, as it uses the untrimmed match length for determining the end, and with the changed starting positions things start to overlap. As it makes sense to have the node start at the line beginning here, I just added a fnc-pos that prevents the trimming.