https://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2020-04-10T21:06:08ZSaxonica Developer CommunitySaxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=152322020-04-10T21:06:08ZMichael Kaymike@saxonica.com
<ul></ul><p>We don't actually retain the form in which the filename was originally supplied; only the full absolute URI (and it would be a lot of effort to change this; in some cases, e.g. when the input is supplied as a <code>StreamSource</code> object, it's not even entirely under our control). The <code>StandardErrorReporter</code> abbreviates the absolute URI to the part after the last slash, because we reckon this is probably sufficient for users to easily recognise the file in the vast majority of cases, and outputting a full absolute URI would create too much visual clutter.</p>
<p>You can easily customise the StandardErrorReporter if you wish (you only need to override one method, <code>abbreviateLocationURI()</code>). Or if you want to access the information programmatically, rather than displaying it to users, it's all there in the <code>Location</code> object passed to the <code>ErrorReporter</code>.</p>
<p>Thanks for the suggestion, but I think I'm going to leave it as it is.</p> Saxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=152372020-04-13T16:06:30ZPhilip Fearonpgfearo@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/48946">problemEntries.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/48946/problemEntries.png">problemEntries.png</a> added</li></ul><p>OK, thanks for looking into this. The reason for this request was to allow any downloaded version of Saxon to integrate easily with the VSCode editor using an <a href="https://github.com/DeltaXML/vscode-xslt-tokenizer/wiki/XSLT-Tasks" class="external">extension TaskProvider</a> I'm working on without the need for an additional distributed command-line wrapper.</p>
<p>Right now, (as shown in screenshot) the command-line output from the XSLT processor provides VSCode with all the 'problem' data. The problem is that, if you click on the 'problem item', you would normally be shown the source XSLT with the problem highlighted, but when the source XSLT where the problem lies is in a different folder to the entry XSLT, an error message is shown instead. This message warns that the source file can't be found.</p>
<p><img src="https://saxonica.plan.io/attachments/download/48946/problemEntries.png" alt="screenshot"></p> Saxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=152442020-04-14T16:17:13ZMichael Kaymike@saxonica.com
<ul></ul><p>The error messages produced by default from the command line processor are designed to be read and interpreted by a human user, typically a reasonably knowledgeable developer. There are other interfaces that produce diagnostics more suitable for an application that is integrating Saxon processing into an IDE or into some other framework. Some of the customisation is also possible from applications based on the Saxon command line, for example by mechanisms including:</p>
<ul>
<li>
<p>the ability to supply a configuration file with -config</p>
</li>
<li>
<p>the ability to supply initialisation code with -init</p>
</li>
<li>
<p>the ability to nominate an error listener with --errorListenerClass (perhaps we should do the same with the new ErrorReporter)</p>
</li>
<li>
<p>the ability to write a subclass of net.sf.saxon.Transform</p>
</li>
</ul>
<p>I do think that if you're integrating with an IDE, you should be picking up error location information programmatically, rather than by parsing Saxon's formatted error messages, which are subject to change from one release to the next.</p> Saxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=152482020-04-15T14:33:16ZPhilip Fearonpgfearo@gmail.com
<ul></ul><p>Yes, on reflection and from what you say, I should look into other options. Specifying an errorListenerClass looks especially appealing, at least for the short-term. Longer term, a dedicated VSCode Language Server would provide much better integration (and potential for a debugger etc.)</p>
<p>Regarding configuration, I found it relatively easy to set up a JSON Schema for this using VSCode. Specifying the XSLT configuration using JSON provides reasonable flexibility while ensured data-integrity, possibly also allowing integration with other VSCode extensions.</p>
<p>Currently a VSCode ProblemMatcher is configured to parse the XSLT processor's stdout using two admittedly rough regexes (one for each error-message line). The ProblemMatcher configuration specifies the regex capture group numbers to use to map to the VSCode ProblemItem properties. The regexes work reasonably well with Saxon 9.9 and 10.0, perhaps it was a little too easy, and I'm sure they don't cover all cases. So, there is a very good case for going for a dedicated errorlistener...as soon as I get time to put this together.</p> Saxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=152502020-04-16T07:36:39ZReece Dunn
<ul></ul><p>Philip Fearon wrote:</p>
<blockquote>
<p>Yes, on reflection and from what you say, I should look into other options. Specifying an errorListenerClass looks especially appealing, at least for the short-term. Longer term, a dedicated VSCode Language Server would provide much better integration (and potential for a debugger etc.)</p>
</blockquote>
<p>The way I've approached this for IntelliJ is to use reflection to load the Saxon instance from a path. I've created API wrappers around the Saxon API so I can call those APIs from the plugin, while handling API differences between saxon 9.2 and 10.0. Those wrappers are then used to implement the IntelliJ APIs for integrating into the IDE (running, profiling, debugging, etc.) -- I'm doing this via a plugin API to allow me to support multiple vendors, but you could implement the VSCode integration APIs directly using the Saxon wrappers.</p>
<p>If you are interested, the Java code for the Saxon integration can be found at <a href="https://github.com/rhdunn/xquery-intellij-plugin/tree/master/src/plugin-saxon/main/uk/co/reecedunn/intellij/plugin/saxon/query/s9api" class="external">https://github.com/rhdunn/xquery-intellij-plugin/tree/master/src/plugin-saxon/main/uk/co/reecedunn/intellij/plugin/saxon/query/s9api</a>.</p> Saxon - Feature #4516: When using the command-line, errors/warnings to stdout give the XSLT give filename or source, but no pathhttps://saxonica.plan.io/issues/4516?journal_id=160082020-08-13T11:28:58ZMichael Kaymike@saxonica.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>Closing this as I think the questions have been answered.</p>