[add] My change-set for merging with restrictive completion, mixed namespaces, import support and linting etc.
AndersMad opened this issue · 8 comments
Hi @rogalmic,
Here my submit of the "massive change-set" that I hope you like like an merge in! :)
Again, I'm sorry that I did not do this a bunch of git commits and a pull request - but the my pet project kinda grew out of control and it was done on monaco (not vscode) where some types are different, loaders are bad etc.
On top of my head here is what I did/added:
- only shows allowed tags in context (up one level - not complete tree but ok for far the most cases I'd reckon)
- import from xsd load other xsd
- mix of namespaces element on insert - blank/default namespace will insert without namespace prefix - rest will be with
- mix of namespaces for attributes - allow attributes from groups from imported xsd
- stricter linting via above and better highlighting of error (e.g. highlights the whole attribute culprit)
- more strict annotation match and markdown documentation list with attribute enumeration values
- auto-complete on attribute values: enumeration values (with documentation) or boolean values
- linting of attribute values
- inserting a tag now insert both open and closing tag
- snippets per namespace (via schema settings) and optionally only show snippets for when parent tag is in a [list]
- root snippets for xml declaration or start of a root element with all the namespaces
- quick tag snippet: CTRL + SPACE + ENTER, type name, TAB
I have only tested it on my setup - but thats a pwetty complicated scenario as its 2 XSDs - HTML5 and a XSLT'ish clone that circular references each other via import, elements and attributes. So the auto-complete on html element will show <div id=".." myNs:myAttr=".." works with only showing allowed and lint triggers to if not allowed. I have also eliminated optimistic lookups for with/without name space to be more restrictive now that there are multiple XSD loaded at the same time with possible naming conflicts / bad matches - should also be faster like that now its possible.
I did a few renames like base to baseAttributes as i added baseElements. All monaco should be easily changed to vscode and maybe IRange to Range etc. and just completely ignore the classes and main functions like provideCompletionItems - they are very monaco styled and extending my base class stuff that is not here (and not needed). Besides that I think kept perfectly in line with your base (I hope) and kept most intact with not-to-many renames - but I did change types like string to classes if needed, added interfaces etc.
Btw. you can now enable "noImplicitAny": true, in tsconfig.json - I strongly recommend that :)
Source is here: xml.zip
Thanks for your work :).
I will take it from here and keep all related stuff in this topic/issue.
Sounds like these are all great features. I wonder why the branch has not been merged...
Well, because it is not done yet. It turned out it was not so easy to merge this...
I have pretty much finished this since last post - added some more but mainly fixes.. let me know if you need an update some day - seems to work ok for the rather complex XSD that I have.. but yes - a lot of changes and addition almost everywhere and it's for monaco - not the vscode extension
@AndersMad : Is your code available somewhere in github?
@rogalmic nope - hoping you or I got/get the time to merge it in you proj. - don't wanna fork you.. I haven't been following your changes - but before it was mainly about vscode stuff.. I can make a new zip with the files in - I won't be dev.ing on it anymore (possible bug fixing but it seems ok stable).. but ye - it's like a factor 2-3 on the code so it will take time - but I think I kept in line with your "style"/basis..
The PR uses the older version of the zip. @AndersMad Can you please just attach the new one here, ideally specifying the initial version that was changed? Do you only have the two zip files or any intermediate ones? With those amount of changes I guess you've used some kind of vcs (local git/svn/whatever), didn't you?
To inspect the changes and possibly get them in it seems more reasonable to create a branch that was created from the used starting point (=no conflicts) and then merge the changes that were done in the meantime to master into this branch, then create a final PR to master.