Bug 590933 - Code highlighting breaks on a hard return inside an attribute and with an ellipsis in a Java programlisting
Summary: Code highlighting breaks on a hard return inside an attribute and with an ell...
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 1.6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Fearn 🐞
QA Contact: Fedora Extras Quality Assurance
: 602008 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-11 02:01 UTC by Ruediger Landmann
Modified: 2010-11-24 04:19 UTC (History)
5 users (show)

Fixed In Version: 2.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-05 04:14:42 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
CPAN 58326 0 None None None Never

Description Ruediger Landmann 2010-05-11 02:01:59 UTC
Description of problem:
Code highlighting breaks under the following conditions:
* a hard return inside an attribute in an XML programlisting, for example:

<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"

* an ellipsis inside a Java programlisting, for example:

      PortletRequestDispatcher prd = getPortletContext().getRequestDispatcher("/jsp/edit.jsp");
      prd.include(rRequest, rResponse);

and with an ellipsis in a Java programlisting

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Include either of the above conditions in a book
2. run publican build
Actual results:
Build fails during code highlighting

Expected results:
Build succeeds and code highlighted.

Comment 1 Jeff Fearn 🐞 2010-05-11 03:23:22 UTC
keyword tags with line wraps were causing problems. Added code to detect line wraps and split tags where required.

Comment 2 Ruediger Landmann 2010-05-11 04:36:45 UTC
Fix verified in 1.6.2.t169 -- neither of these scenarios stops a build any longer.

Comment 3 Ruediger Landmann 2010-06-09 10:57:49 UTC
*** Bug 602008 has been marked as a duplicate of this bug. ***

Comment 4 Ruediger Landmann 2010-06-10 05:09:04 UTC
This is still failing on 1.99.t90 when the xi:included code includes a hard return between the name of the element and the first attribute on that element.

This is the code:

	<area id="index1" coords="2 45"/>
	<area id="index2" coords="3 45"/>
    <programlisting language="XML" role="XML"><xi:include parse="text" href="extras/collection_mapping/default107.xml" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
	<callout arearefs="index1">
		<literal>column_name</literal> (required): the name of the column holding the
		collection index values.
	<callout arearefs="index1">
		<literal>base</literal> (optional - defaults to <literal>0</literal>): the value
		of the index column that corresponds to the first element of the list or array.

And this is the content of: extras/collection_mapping/default107.xml


which fails. Changing that to:

<list-index column="column_name"

allows it to build

Comment 5 Jeff Fearn 🐞 2010-06-10 06:37:53 UTC
(In reply to comment #4)
> And this is the content of: extras/collection_mapping/default107.xml
> <list-index 
>         column="column_name"
>         base="0|1|..."/>

The problem is being triggered by the white space after list-index, removing it avoids this trigger.

This trailing white space is causing Syntax-Highlight-Engine-Kate to have a tag open across two lines, this triggers what I believe is a bug in the XSL parser.

There are newer versions of Kate upstream, so I will look to see if one of them fixes the white space issue, if not I'll open a bug upstream.

I'm also not sure why having an opening/closing tag pair across two lines causes the XSL parser to die. I'll see if I can debug that.

FWIW I checked in a work around for this particular trigger in to the 1.6. branch; there are no doubt many other triggers though so I'd like to pursue a better solution.

Worked around in build: 1.6.3-0.t104

Comment 6 Jeff Fearn 🐞 2010-06-11 00:57:50 UTC
I've opened a bug for Kate, still looking in to why the XSLT process dies on the new line.

Comment 7 Jeff Fearn 🐞 2010-06-11 04:56:42 UTC
Ah ha!

The real problem here was that because we have to process the call outs line by line to insert the image nodes in the correct place, tags that cross line boundaries are "broken" as far as the parser can tell, since it only sees one line at a time.

I modified the highlighting XSL to split tags when they cross lines, so the call out code never gets multi-line tags, and thus it won't blow up. This should be more robust.

While I was in there I added support for LineColumn coords, since we only supported Line number. I did make it ignore the column if it's less than the actual line length though. Currently the column defaults to the greater of 45 or the width of the widest line + 4.

Fixed in build: 1.6.3-0.t113

Note You need to log in before you can comment on or make changes to this bug.