#637 XML highlighting error

Bug
closed-fixed
Neil Hodgson
SciTE (619)
2
2013-06-12
2007-12-03
Anonymous
No

From Philippe.Berthault@Bull.net

If an XML file contains a tag named "script", then the highlighting after this tag is incorrect. It seems the "script" tag is handled as in HTML.

Here a small example:
<?xml version="1.0"?>
<domain>
<script path="vif-bridge"/>
<name>toto</name>
</domain>

All tags after "toto" are displayed as normal text. The
highlighting stops here.

Discussion

  • Neil Hodgson
    Neil Hodgson
    2007-12-03

    Logged In: YES
    user_id=12579
    Originator: NO

    I won't be working on this.

     
  • Neil Hodgson
    Neil Hodgson
    2007-12-03

    • milestone: --> Bug
    • priority: 5 --> 2
    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-wont-fix
     
  • Daniel Walker
    Daniel Walker
    2009-01-28

    Please fix this. I love using Scintilla, however this problem is very frustrating. I use large xml files with <script> tags and still need highlighting to work.

     
  • Kai Liu
    Kai Liu
    2009-02-02

    So if I understand this bug correctly, the problem is that the script state is not terminated if the tag is self-closed (if an explicit closing script tag is used, there is no problem). If this is the case, then one possible solution would be to not enter the script state if the tag is self-closing.

    I'm attaching a patch that fixes the problem. LexHTML.cxx is pretty big and complicated, and I haven't had a chance to fully explore all of its code paths, and thus this patch is probably not be the most efficient approach. I also noticed that this bug does not affect HTML--just XML.

    Also, on an unrelated note, this patch gets rid of the "s[0] == '/' ? s + 1 : s" check in classifyTagHTML because, due to the way s is populated earlier in the function, s is guaranteed to never contain the '/' character.

    Hmm... er, the SF tracker is not giving me the option to attach a file... (huh?)... so here is the patch:
    http://www.kailiu.com/temp/LexHTML_bug1843242.patch

     
  • Neil Hodgson
    Neil Hodgson
    2009-02-02

    The actual bug is that the poster wants all processing of script sections turned off for XML. I think this is too severe as some use the XML lexer for HTML files or where there are script sections in XML. A solution that provided a property to choose between allowing and disallowing scripts would be more widely applicable.

    > s is guaranteed to never contain the '/' character
    This is not obvious to me.

    Attachments are only allowed for the original author and you created this logged out.

     
  • Kai Liu
    Kai Liu
    2009-02-02

    > The actual bug is that the poster wants all processing of script sections
    > turned off for XML.

    That's one way to read the bug request, but the sample code provided suggests that this may not have been the intention of the reporter (perhaps the actual intent got lost in the translation?) since Scintilla's behavior with the sample code snippet (in which script highlighting continued even though the script tag was closed) is obviously incorrect. Regardless of whether this was the reporter's actual intent, I suppose we could agree that the current treatment of a self-closed script tag in XML is a legitimate bug.

    > This is not obvious to me.

    When populating s, a character is copied to s only if it is not '<' or '/', so it is impossible for '/' to exist in s.

    if ((ch != '<') && (ch != '/')) {
    s[i++] = caseSensitive ? ch : static_cast<char>(MakeLowerCase(ch));
    }

    > Attachments are only allowed for the original author
    > and you created this logged out.

    I was logged in. But I'm not the original author.

     
  • Neil Hodgson
    Neil Hodgson
    2009-02-15

    Committed patch from Kai Liu for self-closing but leaving open as I don't think that was the intent of the original poster.

     
  • Neil Hodgson
    Neil Hodgson
    2013-06-12

    • status: open-wont-fix --> closed-fixed
     
  • Neil Hodgson
    Neil Hodgson
    2013-06-12

    Original poster should reopen this if their intent differs from the patch authors.