+2010-06-11 Jonathan Pryor <jpryor@novell.com>
+
+ * Monodoc/ecma-provider.cs: Reduce memory requirements when assembling
+ ECMA documentation. The problem was that we parse all the XML files
+ in order to extract //summary and //remarks members, and then stored
+ the XmlNodes for these members. XmlNode keeps a ref to the creating
+ XmlDocument, thus keeping the XmlNode around requires keeping the
+ entire XmlDocument around; result: ~350+MB RAM is needed to assemble
+ netdocs.zip (in ../../docs). To fix, import the XmlNodes that we
+ actually care about into an otherwise empty XmlDocument, so that we
+ only save the nodes we need. Result: ~32MB RAM is needed.
+ Fixes #602560.
+
+2010-04-25 Jonathan Pryor <jpryor@novell.com>
+
+ * Monodoc/ecma-provider.cs: Support the full set of possible operator
+ names within EcmaHelpSource.MakeOperatorSignature() (where "full" is
+ "whatever is included in ECMA-335 §10.3.1 through §10.3.3").
+ Fixes InvalidOperationException reported to mono-docs-list.
+
+2010-02-28 Jonathan Pryor <jpryor@novell.com>
+
+ * Monodoc/provider.cs: Add
+ RootTree.LoadTree(string,string,IEnumerable) for compatibility with
+ Mono 2.6's monodoc.dll.
+
+2010-02-26 Jonathan Pryor <jpryor@novell.com>
+
+ * Makefile: Add a System.Core.dll reference; embed monodoc.xml as a
+ resource.
+ * Monodoc/provider.cs: Add a
+ RootTree.LoadTree(string,XmlDocument,IEnumerable<string>) method.
+ This is so 'mdoc export-html-webdoc' doesn't need to rely on the
+ system-wide .source files (allowing execution w/o changing/replacing
+ the system-wide .source files) and so MonoDevelop can support
+ multiple .source files spread throughout the system sanely.
+ * Monodoc/ecma-provider.cs: Always add the extension methods contained
+ in the current EcmaHelpSource, instead of implicitly requiring that
+ the current EcmaHelpSource also be contained within
+ RootTree.HelpSources. This simplifies logic in 'mdoc'.
+
+2010-01-13 Jonathan Pryor <jpryor@novell.com>
+
+ * Monodoc/provider.cs, Monodoc/ecma-provider.cs: Improve cache support
+ by having EcmaHelpSource.GetTextFromUrl() look for cached contents.
+ This greatly speeds up type member listings (e.g. T:...List`1/*),
+ e.g. from ~2.0s to 0.06s.
+
+2010-01-13 Jonathan Pryor <jpryor@novell.com>
+
+ * Mono.Documentation/XmlDocUtils.cs: XmlDocUtils.AddExtensionMethods()
+ wasn't adding extension methods which matched *interfaces* of base
+ classes. Result: Mono.Options.OptionSet (which inherits
+ System.Collections.ObjectModel.KeyedCollection`2 which inherits from
+ System.Collections.ObjectModel.Collection`1 which implements
+ System.Collections.Generic.IEnumerable`1) wasn't getting any of the
+ LINQ extension methods (which is bad). Fix this.
+
+2010-01-13 Jonathan Pryor <jpryor@novell.com>
+
+ * Resources/mdoc-html-utils.xsl: Fix regression caused by 2009-12-02
+ commit adding GetLinkTargetHtml(). The problem was that when
+ running within ASP.NET/monodoc ~all extension method links would be
+ 'javascript:alert("...")M:Foo.Method(...)', which is clearly wrong.
+ This occurred because $linkid's generation would always call
+ GetLinkTargetHtml() with a $cref value of '', thus the monodoc
+ GetLinkTarget() would return '', so GetLinkTargetHtml() would return
+ the javascript "not found" alert. Thus, we can't expect
+ GetLinkTargetHtml() with $cref='' to work under monodoc, but it's
+ ~required to work sanely under 'mdoc export-html'.
+ Solution is to not call GetLinkTargetHtml() here UNLESS we're doing
+ 'mdoc export-html' generation, which we assume to be the case if
+ $html-anchor is true.
+
2009-12-30 Jonathan Pryor <jpryor@novell.com>
* Lucene.Net/Lucene.Net/QueryParser/QueryParser.cs: Fix crash when