🚀 go-pugleaf

Hi Stanislav,

This is indeed a quirk with structured documents. What happens is that the element boundaries (tags or brackets) are included in the text range, even if they are hidden. In your case, when you delete everything except the title element, there are two element boundaries to the left and right of the title paragraph (show the boundaries to see them). So, the actual offset of the paragraph text is 2-13, not 0-11 as in an unstructured document.

I do not know any way to prevent this behavior. In my work with structured documents, I have avoided this problem by working strictly with element ranges, only converting to text ranges when necessary. For example, if I want to select the contents of your title element, I might do something like the following:

er.beg.parentId = er.end.parentId = F_ApiGetId(docId, elemId, FP_ParentElement);

er.beg.childId = elemId;

er.end.childId = F_ApiGetId(docId, elemId, FP_NextSiblingElement);

if(!er.end.childId) er.end.childId = 0;

er.beg.offset = er.end.offset = 0;

...where "er" is an F_ElementRangeT structure. Then, if I need to convert it to an F_TextRangeT, I can do something like:

F_ApiSetElementRange(docId, elemId, FP_ElementSelection, &er);
tr = F_ApiGetTextRange(FV_SessionId, docId, FP_TextSelection);

...or, you can do it without actually selecting the text with something like:

tr.beg = F_ApiElementLocToTextLoc(docId, &er.beg);
tr.end = F_ApiElementLocToTextLoc(docId, &er.end);

Maybe this isn't the best solution for you, and maybe there is an easier way. In any case, I have found it best to always use element ranges to navigate and set text ranges while working in a structured doc. If there truly is no way to avoid the inclusion of element boundaries in text range offsets, it seems a very difficult proposition indeed to guess where the boundaries will be. Working with element ranges first, you can avoid that guesswork.

Russ