Page 1 of 1

Author actions when cursor is in a comment

Posted: Mon Sep 20, 2021 7:50 pm
by whyme
Hi,

I've tried a simple Author MoveCaretOperation to move the cursor to ancestor-or-self::*[1]. It works fine, except when the cursor is currently in a comment or processing instruction. In those cases the action does not start. I've found some other author actions that seem not to respond when the cursor is in a comment or processing instruction. Is this a feature or a bug? Are there workarounds? (I had hoped a simple MoveCaretOperation would be provide that workaround.)

Re: Author actions when cursor is in a comment

Posted: Tue Sep 21, 2021 11:29 am
by adrian_sorop
Hi!

Try to use node():

Code: Select all

ancestor-or-self::node()[1]
* matches only element nodes.
node() matches comments, processing instructions and text nodes.

Hope it helps,
Adrian S.

Re: Author actions when cursor is in a comment

Posted: Wed Sep 22, 2021 10:38 am
by adrian_sorop
Hi again.

Now I sow that you had other issue:
It works fine, except when the cursor is currently in a comment or processing instruction. In those cases the action does not start.
I suppose the action it's not enabled for processing intructions.

The simplest way is to force the action be te enabled all the time: go to action's dialog box and set operation's Activation Xpath to "true()".

Regards,
Adrian S

Re: Author actions when cursor is in a comment

Posted: Tue Sep 28, 2021 7:51 pm
by whyme
Hm, this is strange.

In a dummy project file, I have my cursor in a comment, XPath /root/a/b/comment(). I have a simple author action, to move to the current parent. I've adopted your suggested ancestor-or-self::node()[1] (though I'm not sure why I need to make this change -- ancestor-or-self::*[1] works fine in the Oxygen XPath/XQuery Builder when the context is a comment). I've added the XPath activation true(). (That feels like a hack -- shouldn't a blank value allow the action to be applicable whenever, wherever?)

Those settings finally get a response, but it selects the root element, not the parent! Same thing happens when [last()] is substituted for [1]. When the cursor is in an element or text node the behavior is as expected.

Re: Author actions when cursor is in a comment

Posted: Wed Sep 29, 2021 3:07 pm
by adrian_sorop
So,
I've adopted your suggested ancestor-or-self::node()[1] (though I'm not sure why I need to make this change -- ancestor-or-self::*[1] works fine in the Oxygen XPath/XQuery Builder[...]
The MoveCaretOperation uses the following API ro.sync.ecss.extensions.api.AuthorDocumentController.findNodesByXPath(String, boolean, boolean, boolean) to detect the nodes from the xpath.

Code: Select all

/**
 *Finds the author nodes selected by the given XPath 2.0 expression.
 *
 * @param xpathExpression The XPath expression. If the XPath expression is relative, it will be computed in the context of the current caret position.
   * @param ignoreTexts If <code>true</code> Author text nodes will not be returned.
   * @param ignoreCData If <code>true</code> Author CDATA sections will not be returned.
   * @param ignoreComments If <code>true</code> Author comments will not be returned.
*/
AuthorNode[] findNodesByXPath(String xpathExpression, boolean ignoreTexts, boolean ignoreCData, boolean ignoreComments) 
In the code of the operation, this metod si called with all the boolean parameters on true. This means that comments, text nodes and CData are ignored.
I've logged an issue to reconsider this behaviour
I've added the XPath activation true(). (That feels like a hack -- shouldn't a blank value allow the action to be applicable whenever, wherever?)
The Activation XPath is documented as
An XPath 2.0 expression that applies to elements and attributes.
. This means that it takes into account elements only.
The XPath expression equivalent of the empty field is:

Code: Select all

boolean(self::*)
.
If you want, you can change the Activation XPath to something like

Code: Select all

boolean(self::node())
but I don't like, that's why I recommanded the true() funtion. The result should be the same.
Same thing happens when [last()] is substituted for [1]. When the cursor is in an element or text node the behavior is as expected.
I don't think I fully understand this case. Perhaps a small example would be usefull.
Anyways, as far as I understood, I think that ancestor axe should not be used with last(). You can try something like self::node()[last()]

Re: Author actions when cursor is in a comment

Posted: Wed Oct 27, 2021 10:30 pm
by whyme
So given the following author action, "move_to_parent"...

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<a:authorAction xmlns:a="http://www.oxygenxml.com/ns/author/external-action"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.oxygenxml.com/ns/author/external-action http://www.oxygenxml.com/ns/author/external-action/authorAction.xsd"
  id="move-to-parent">
  <a:name>move to parent</a:name>
  <a:description>Move to parent element</a:description>
  <a:operations>
    <a:operation id="MoveCaretOperation">
      <a:xpathCondition>true()</a:xpathCondition>
      <a:arguments>
        <a:argument name="selection">Element</a:argument>
        <a:argument name="xpathLocation">ancestor-or-self::node()[1]</a:argument>
      </a:arguments>
    </a:operation>
  </a:operations>
  <a:accelerator>M3 5</a:accelerator>
  <a:enabledInReadOnlyContext>false</a:enabledInReadOnlyContext>
</a:authorAction>
...and given the following XML...

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<a>text
   <b>text
      <!-- comment --><?test?><![CDATA[test]]>
   </b>
</a>
...when in Oxygen Author the cursor is in the text node of <b> or in the processing-instruction or in the CDATA, then each time "move_to_parent" is run <b> is selected, as expected. But when the cursor is in the comment and "move_to_parent" is run, <a> is selected, which is of course unexpected.

Re: Author actions when cursor is in a comment

Posted: Fri Oct 29, 2021 10:00 am
by adrian_sorop
Yes, you're right.
I've added your feedback to the issue.
This behaviour will be fixed in the following release.
Thanks!