polyglot-jones
commented
3 years ago What if the linter only promised to handle a small subset of AsciiDoc? -- i.e. it justs looks for the most common lint.
I've been thinking of putting forth the notion of establishing an "AsciiDoc-Lite" standard. I'm convinced that less than 5% of AsciiDoc notation handles more than 95% of the use cases out there. Having such a known-quantity specification could make life easier on everyone (developers and users). In this case, a linter developer could get away with targeting just AsciiDoc-Lite. Correspondingly, our syntax highlighting only promises to work on AsciiDoc-Lite. If someone (me) wants to develop an app that claims to use AsciiDoc as the underlying markup, then meeting the minimum AsciiDoc-Lite standard would justify that claim -- whether it's done with AsciiDoctor/Ruby, AsciiDoc/Python3, or something home-grown, it doesn't matter. And the documentation for all of these projects gets a lot simpler if it all only has to point to the one spec to answer the question of what it handled and not handled.
(Moved here from issue #10.)
@tajmone wrote:
When it comes to creating an AsciiDoc linter, I think the best approach would be to create a dedicated linter for an already existing linter package, like SublimeLinter, rather than include it in this package:
https://github.com/SublimeLinter/SublimeLinter http://www.sublimelinter.com/en/stable/ I'm convinced that it's very hard to handle the AsciiDoc syntax without a proper parser that creates an AST, and I think that the only viable solution would be to create a Language Server package for AsciiDoc, which would not only be portable across all editors that support LSP, but also allow tailoring all sorts of functionality into the package as well (linting, refactoring, etc.).
But that would be quite hard to achieve, for such an LSP package would have to be fast enough to allow real-time highlighting while editing, and also be a "fault tolerant" parser which can recover from incomplete constructs without breaking the whole document (which is the main problem with the current ST package, which often breaks up mid-document and is unable to properly highlight and index the rest of the doc).