How to stop oxygen from making decision of inserting tag or text

[SmitaPatil]

Hi Team,
I am trying unwrap comment (I am deleting element completely nd then inserting just content of comment) here which is present in below screenshot.

image.png (49.4 KiB) Viewed 522 times

after deleting I want insert text to be at that caret position only and for that I am using below method
AuthorDocumentController.insertText(caretOffset, textContent);
But It is coming inside text.line

image.png (112.94 KiB) Viewed 522 times

Can you please tell how I can stop oxygen from doing this. How I can disable it?

Thanks & Regards,
Smita

[Bogdan Dumitru]

Hello Smita,

Assuming that our API does what it documents in the JavaDoc (see AuthorDocumentController.insertText documentation page) we recommend starting troubleshooting by verifying that the "caretOffset" parameter has the correct value.
Also, it might help you to write a unit test for your plugin, read the Writing Java Unit Tests for Plugin Code topic on how to build an AuthorDocumentModel from within a unit test.

[SmitaPatil]

Hi,
I have already verified whether its issue regarding caret offset but no.
Before deleting node caretoffset is as shown below

image.png (7.13 KiB) Viewed 510 times

and After deleting node acret offset is as shown below

image.png (5.17 KiB) Viewed 510 times

Code I am using to implement it is as follows :

int caretOffset = authorAccess.getEditorAccess().getCaretOffset();
logger.debug("caretoffset is : "+caretOffset);
String textContent=node.getTextContent();
docCtrl.deleteNode(node);
logger.debug("caretoffset after deleting node "+ caretOffset);
docCtrl.insertText(caretOffset, textContent);

I don't think so its issue with caretoffset. Can you please verify once?

Thanks & Regards,
Smita

[Bogdan Dumitru]

Hello Smita,

We double-checked the API and run some tests, and everything looks fine.

You store the caret offset in a variable called "caretOffset" before deleting the node by using (authorAccess.getEditorAccess().getCaretOffset()) when the caret is at position 26. The 26th position, at that point, is after the node that follows to be deleted. The variable with the offset doesn't change but the document does change because you delete the node. After deletion, the 26th position now points somewhere inside the element that follows the deleted one (the one called text.line).

Hope that the above makes sense to you. If you still consider that's a problem in our API, please write a unit test that captures the problem because otherwise, it's very difficult for us to imagine what's the problem when receiving chunks of pieces of information and without compelling proof, we sense that there is just a witch hunt request.

Also, please see the AuthorNode JavaDoc documentation where we talk about document offsets:

AuthorDocumentFragmentArchitecture.gif (6.82 KiB) Viewed 504 times

[SmitaPatil]

Hi Bogdan,
Issue is resolved.
Thank you so much !!