${caret} ends up at wrong position

<oXygen/> general issues.
Martin de la Iglesia
Posts: 10
Joined: Tue Aug 22, 2017 5:43 pm

${caret} ends up at wrong position

Post by Martin de la Iglesia » Tue Aug 22, 2017 6:02 pm

Hi,

I'm new to the Author mode so I'm probably missing something obvious, but:
I've created an InsertFragmentOperation Action with the fragment

Code: Select all

<ab>
<lb/>${caret}
</ab>
However, when I execute this Action, after the fragment is inserted, the cursor is now positioned before the <lb/> tag. How do I configure the Action so that the cursor is directly after the <lb/>?

sorin_carbunaru
Site Admin
Posts: 228
Joined: Mon May 09, 2016 9:37 am

Re: ${caret} ends up at wrong position

Post by sorin_carbunaru » Wed Aug 23, 2017 10:09 am

Hello Martin,

What version of oXygen are you using? I have tried on the 19.0 that I have installed and the caret was placed after "lb" in the Author page, as expected. However, when I switched to the Text page I noticed that the caret was indeed moved before "lb" (probably a bug). Is this what happens to you too, or does the caret end up in the wrong place even in the Author page?

Best wishes,
Sorin Carbunaru
oXygen XML

Martin de la Iglesia
Posts: 10
Joined: Tue Aug 22, 2017 5:43 pm

Re: ${caret} ends up at wrong position

Post by Martin de la Iglesia » Wed Aug 23, 2017 10:41 am

Thank you for looking into this, Sorin.
I'm using v. 17.1 and now that I've checked, I can confirm that it is indeed as you say: when I stay in Author mode, the caret is at the correct position; only when I switch to Text mode, the caret 'jumps' 5 characters to the left. So this problem isn't as bad as I thought and I can keep working in Author mode, but it's still weird.

sorin_carbunaru
Site Admin
Posts: 228
Joined: Mon May 09, 2016 9:37 am

Re: ${caret} ends up at wrong position

Post by sorin_carbunaru » Wed Aug 23, 2017 10:51 am

Yes, it's weird. I recorded an issue for this.

inormann
Posts: 2
Joined: Fri Jun 07, 2019 10:17 pm

Re: ${caret} ends up at wrong position

Post by inormann » Mon Jun 10, 2019 11:22 pm

InsertFragmentOperation does not behave as expected

Hi,

InsertFragmentOperation allows to insert an element at a position specified by an XPath. However, after insertion the caret is not as specified, but somewhere else. Related issues seemed to be reported already in this forum and sometimes regarded as bug - e.g. in 2017 for version 19.0 s. post43836.html#p43836

I am running version 21.0.

In my example I specify <note xmlns="http://www.tei-c.org/ns/1.0">${caret}</note> as the fragment to inserted at insertLocation /TEI/text/body with insertPosition "inside as last child"

Now, consider this little example document where "|" stands for the caret when the action is executed:

Code: Select all

<TEI xmlns="http://www.tei-c.org/ns/1.0">
		<!-- teiHeader here -->
    <text>
        <body>
            <lg>
                <head>
                    <title>A Poem</title>
                </head>
                <lg>
                		<l>first verse</l>
                		<l>second| verse</l>
                </lg>
            </lg>
        </body>
    </text>
</TEI>
After execution I get this result document:

Code: Select all

<TEI xmlns="http://www.tei-c.org/ns/1.0">
		<!-- teiHeader here -->
    <text>
        <body>
            <lg>
                <head>
                    <title>A Poem</title>
                </head>
                <lg>
                		<l>first verse</l>
                		<l>second verse</l>
                </lg>|
            </lg>
            <note/>
        </body>
    </text>
</TEI>
I observe that the note element is at the correct position, yet the caret isn't: It should be inside the note element, but it is right after the closing lg element. This looks like a bug to me. Or am I missing a point here?

Best
Immanuel

sorin_carbunaru
Site Admin
Posts: 228
Joined: Mon May 09, 2016 9:37 am

Re: ${caret} ends up at wrong position

Post by sorin_carbunaru » Tue Jun 11, 2019 12:54 pm

Hello Immanuel,

The related issue was indeed a bug, and it is already fixed for the next version (22.0, scheduled for February 2020 or so).

Unfortunately, I didn't manage to reproduce your issue on my side with oXygen 21.0. If you desire, I can send you a private e-mail with a link to a nightly kit of oXygen XML Editor 22, just for you to try and see if the problem you reported will be solved on your side in that version. If this sounds OK to you, please write us at support@oxygenxml.com.

Best wishes,
Sorin Carbunaru
oXygen XML

Post Reply