Community
Participate
Working Groups
Source editors currently have matching brackets feature, where matching <>(){} are all highlighted. It would be nice if ""'' were also added.
Amy, I'll take a look at this.
Amy, exactly which editors are you looking for this functionality? Are you looking for it as a default in the SSE editor in general, or are there particular editors where this would be helpful.
From what I can tell here, it should be a simple matter of adding DOMRegionContext.XML_TAG_ATTRIBUTE_VALUE to the region to check, unless there is another of the attribute constants that should be added instead. I tried the XML_TAG_ATTRIBUTE_VALUE and it didn't seem to make any difference in the XMLDocumentRegionEdgeMatcher. Is there a better constant to use?
Alright...yes another comment. I think there is going to be a potential problem with getting the ' and " added as RegionEndMatchers. The problem is that the quote and apostrophe are currently included in the XML_TAG_ATTRIBUTE_VALUE scope. You can see this as being true as when this tag is used by the LineStyle provider to italicize something in the source editor, the quotes/apostrophes are also italized not just the content between them. So unless there is a way to change the scope and make the region for the XML_TAG_ATTRIBUTE_VALUE not include the apostrophe and quote then we can't scope the begining and end of the region correctly.
I was thinking for all source editors.
I'm not sure about the answers to your other questions, but offhand, I'd say part of the reason why we haven't fixed this bug sooner is probably because we ran into the same problems you're running into now. Rather than trying to use the DocumentRegionEdgeMatcher, maybe it'd be easier to just use the default edge matcher and just straight up match quotes to quotes rather than trying to be way smart about it? If you use the DocumentRegionEdgeMatcher, would it have matched quotes if they were used in tag content like <tag>i am using "airquotes"</tag>?
(In reply to comment #6) > I'm not sure about the answers to your other questions, but offhand, I'd say > part of the reason why we haven't fixed this bug sooner is probably because we > ran into the same problems you're running into now. > > Rather than trying to use the DocumentRegionEdgeMatcher, maybe it'd be easier > to just use the default edge matcher and just straight up match quotes to > quotes rather than trying to be way smart about it? If you use the > DocumentRegionEdgeMatcher, would it have matched quotes if they were used in > tag content like <tag>i am using "airquotes"</tag>? > If we use the Default matcher, it'll match where ever those appear, I believe. Which isn't what we want. We really only want it to match within the scope of an attribute declaration value. Unfortunately it appears that to do this, the Lexical Tokenizer Parser would need to be redone as well, as possibly the structured text editor. The key here is clearly specifying a token for the start and end regions of the attributes.
The current matcher just checks the document region's reported type and if it falls within the given list and the cursor is at one of that document region's "edges", reports a match. It's not really even looking at the text, so it would never match quotes within XML content as shown in comment 6. I don't think this feature is quite important enough to justify the memory increase from breaking attribute values into separate tokens. Even as an in-place region container it would more than triple the size of an attribute value region. As the attribute value region contains a textLength integer indicating the last non-whitespace character, it should be possible to check the character at that index and the first character of the value to see if they're the same. That, or orchestrate things so that the matcher being used calls the DocumentRegionEdgeMatcher, and when no match is found there, falls back upon the platform's implementation.
This seems to be working in Web Tools 3.0 RC 1
reassigning to inbox
(In reply to comment #9) > This seems to be working in Web Tools 3.0 RC 1 This works for me as well in WTP 3.2. Time to close.
Looks like this has been implemented over time or as the result of another fix.
