mhutch / monodevelop.xml Goto Github PK

When parsing this XML I see XProcessingInstruction node start at -1:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<X>
  <n:T></n:T>
  <X/>
  <A.B></A.B>
  <A B="a"></A>
  <A>&#x03C0;</A>
  <A>a &lt;</A>
  <A><![CDATA[bar]]></A>
  <!-- comment -->
</X>

Is it by design that calling XmlDomExtensions.GetNodesIntersectingRange and passing it a range of a subelement doesn't include the parent element?

E.g.

<A>
<B>
</B>
</A>

passing the range of B only returns B, but A's range isn't considered intersecting it?

This location expects a tagger of tag type NavigableHighlightTag:

But the corresponding tagger doesn't implement it, it implements ITextMarkerTag:

Parse <<

Results in diagnostic with start offset -1 Error at (-1-0): Incomplete tag opening; encountered unexpected '<'.

I'll fix this soon.

Toggle Comment should first comment the whole element if it's not commented.

Currently it first uncomments all descendants, which is not what we usually want.

<x>text</x>

Place the caret after > and before text and press Enter.

Expected: should indent:

<x>
    text</x>

Actual: doesn't indent:

<x>
text</x>

When parsing <x : I get an assert:

https://github.com/KirillOsenkov/MonoDevelop.Xml/blob/523dcc1f207bf432dd865b9874ab85172e3b6722/Core/Parser/XmlNameState.cs#L48

MonoDevelop.Xml.Parser.XmlNameState.PushChar Line 73
MonoDevelop.Xml.Parser.XmlParser.Push Line 90

I'm not sure that it's a bug per se, as the parser seems to be able to recover, but in general I think the parser should be able to handle any inputs. Curious what you think.

Here's a test:

		[Test]
		public void BadOpeningTagWithNamespace ()
		{
			var parser = new XmlTreeParser (CreateRootState ());
			parser.Parse ("<x :");
			parser.AssertErrorCount (2);
		}

Parse this code:

<X>
  <n:
  T></n:T>
  <X/>
</X>

System.InvalidOperationException: Invalid state
   at XmlParserState MonoDevelop.Xml.Parser.XmlNameState.PushChar(char c, XmlParserContext context, ref string rollback) in C:/MonoDevelop.Xml/Core/Parser/XmlNameState.cs:line 46
   at void MonoDevelop.Xml.Parser.XmlParser.Push(char c) in C:/MonoDevelop.Xml/Core/Parser/XmlParser.cs:line 90
   at Task<XmlParseResult> MonoDevelop.Xml.Editor.Completion.XmlBackgroundParser.StartOperationAsync(ITextSnapshot input, XmlParseResult previousOutput, ITextSnapshot previousInput, CancellationToken token)+() => { } in C:/MonoDevelop.Xml/Editor/Parsing/XmlBackgroundParser.cs:line 39
   at void System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at bool System.Threading.ThreadPoolWorkQueue.Dispatch()
   at bool System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

< :
when expecting a name but getting a whitespace followed by : we assert here:

Think about how to recover from this and report the right errors

In a large XML file, type <a a="a" and then type the closing >

The closing tag is likely not inserted. This is because at the time when the command handler runs the parse tree for the new snapshot that has the > that was just inserted is not yet available, so a call to GetSpineParser is recovered from the previous tree that doesn't have the closing >.

Since in the previous tree the > is not there, the element under caret is not IsEnded and the condition here bails:

It is noteworthy how even though the text and the parse tree is identical up to the caret position, the shape of the parse tree after the caret position is different and thus impacting whether the current element is ended or not. For small files the latest parse tree is usually available at that point, and in that tree the element is Ended, so the command handler executes.

This patch fixes it by always forcing the full tree for the latest snapshot:

However this totally kills perf as it forces a synchronous parse of the latest snapshot immediately on typing. I'm not sure what's the best thing to do here, perhaps some heuristic to make just this particular case work.

Opening a large malformed file with thousands of unclosed tags crashes with StackOverflow as we use simple recursion and run out of stack

<a>
    <b>x<c>
    </c>y</b>
</a>

There should only be two tags for the above XML, but there are three, and two of them start and end on the same line, which is unnecessary

If you're typing out a new element and type =" it auto-inserts the closing = and lets you overtype it.

If you want to add an attribute to an existing element though it doesn't auto-insert the quotes and there is no overtype.