You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been doing a fair bit of document and email writing recently, and using flymake-vale more than normal, and that had me thinking about Vale's code parsing abilities in relation to Emacs master's recently merged Treesitter functionality.
It would be useful to have flymake-vale use Treesitter to determine which parts of a file to send to Vale for review - it would allow us to support more languages than Vale on its own! I think the treesitter-grammar-specific implementations for defining comments or function names, etc should probably be left out of scope, with initial focus just on accepting an arbitrary treesitter pattern-matching query as the definition of scope that flymake-vale operates in within a buffer. Obviously if the query was undefined then instead the current logic of passing the whole document to vale would be triggered.
Some really nice targetting could be achieved by using tree-sitter-comment on the comments themselves, filtering out tags like TODO and NOTE-BUG (stsewd): (playground).
On potential challenges involved - I note that currently, the entire buffer is sent to the process in one go. If we had to communicate with Vale many times per buffer (say after opening a huge Java library file, with 3,000 docblocks above each function, all full of spelling mistakes), how drastically might that affect performance, given increased chatter back and forth with the Vale process? Could we somehow send all comments in one go and get a parseable response back?
I'd love to hear other thoughts!
The text was updated successfully, but these errors were encountered:
From my understanding there would be two ways to implement this:
defining a grammar to identify comments
leveraging the already identified comments in the various grammars available
The first, I agree, is out of scope of this package and would not be an efficient approach. The second would require us to maintain queries for all of the language grammars we offer to support, which I am not particularly keen on doing, but not fully against.
However, I don't really see a strong enough benefit over the current capabilities of vale. It supports linting comments in 18 languages (C, C#, C++, CSS, Go, Haskell, Java, JavaScript, LESS, Lua, Perl, PHP, Python, R, Ruby, Sass, Scala, Swift). Does this not provide what you are suggesting?
Hi there,
I've been doing a fair bit of document and email writing recently, and using flymake-vale more than normal, and that had me thinking about Vale's code parsing abilities in relation to Emacs master's recently merged Treesitter functionality.
It would be useful to have flymake-vale use Treesitter to determine which parts of a file to send to Vale for review - it would allow us to support more languages than Vale on its own! I think the treesitter-grammar-specific implementations for defining comments or function names, etc should probably be left out of scope, with initial focus just on accepting an arbitrary treesitter pattern-matching query as the definition of scope that flymake-vale operates in within a buffer. Obviously if the query was undefined then instead the current logic of passing the whole document to vale would be triggered.
Some really nice targetting could be achieved by using tree-sitter-comment on the comments themselves, filtering out tags like
TODO
andNOTE-BUG (stsewd):
(playground).On potential challenges involved - I note that currently, the entire buffer is sent to the process in one go. If we had to communicate with Vale many times per buffer (say after opening a huge Java library file, with 3,000 docblocks above each function, all full of spelling mistakes), how drastically might that affect performance, given increased chatter back and forth with the Vale process? Could we somehow send all comments in one go and get a parseable response back?
I'd love to hear other thoughts!
The text was updated successfully, but these errors were encountered: