Refactor the generic resolver
Closed this issue · 5 comments
First, thank you for SublimeHyperClick! @aziz I'd like some feedback about a potential PR.
Additions
I've added support for some new languages (CSS, Pug, SugarSS, SugarML, Nunjucks, Jinja2, Twig) to my fork.
All those languages share the same resolver, so instead of having a different resolver for each syntax, I decided to use a single GenericPathResolver in path_generic_resolver.py.
Why?
This generic resolver is also applicable to PHP, HTML, Less and Stylus.
There's already a GenericSubfolderResolver which is meant for references without an extension. GenericPathResolver does what the Less resolver currently does: first try to match the imported filename literally, then try to match the filename with one of its valid extensions (for languages that allow for shorthand references). I think this would be a better generic default.
PR
Should I
- open a PR with these structural modifications, or
- just bring the new languages as separate resolvers, each with an specific file, not modifying the current structure?
Re: GenericPathResolver, should I name it GenericSubfolderResolver, and rename the current GenericSubfolderResolver to something else?
Hi @cristianl, do you want to be a collaborator on this repo and help us maintain it?
I'm busy with other stuff at the moment and can't work on this any more.
Yes, I'd like to help maintain it. It's surprisingly important to my workflow.
I'll tidy up the changes in my fork before bringing them in.
That's great. just added you.