I recently came across docsify and find it great to work with. I suggest opening a repo on Github on the sublimehq userspace.
Authoring in HTML isn’t a hindrance on our current workflow, so I wouldn’t want to add more work to our limited team for something that isn’t a pain point.
I have in mind to discuss with Jon putting the docs on Github for contributions, but it isn’t high on (relative) priority list at the moment.
Would be nice to have these on Github for sending patches
The color scheme, other than Monokai, are effectively deprecated at this point. The community has made hundreds, if not thousands of colors schemes. The current ones in the default color scheme package woefully under-utilize the syntaxes we’ve been improving.
The theme isn’t open source, and I don’t think that is an area where the community involvement would make significant improvements. We want a reasonable out-of-box experience, otherwise the community is doing a great job of exploring the aesthetic that they like.
The Default package handles a decent amount of core functionality. Accepting patches on that isn’t something that would be as useful as work on the syntaxes or good bug reports. The other factor here is that backwards compatibility is a big concern. Package authors tend to tie into Python code from the Default package, so the APIs are effectively frozen once released. This prevents refactoring and other changes that aren’t strict bug fixes.
Where do we send patches? The lists keeps getting longer…
Deciding what is highest priority in terms of what we are working on is no simple task. Sending patches isn’t as useful as concise, well-written bug reports.
Sending patches would likely just lead to a disconnect in expectation. Patches will likely have unforeseen affects since the vast majority of the codebase is closed source, then the patch has to be rewritten taking into account all of the use-cases and edge cases that aren’t obvious. I’ve tried to grab a few patches, however they ended up having to be almost completely rewritten to handle situations that weren’t obvious, plus to match our style and linting setup (which isn’t public). In the end, the patches didn’t really save any time, but instead required that I try to interpret why the author was changing what they were.
There has been plenty of activity going on behind the scenes, as it typical with most development that isn’t open source. Once the next build is out, I’ll be visiting the issue tracker and closing everything that was addressed.
And yes, I understand people are eager to see the next build. I’m excited for everyone to get their hands on it also!