Any update on this? On Saturday, April 15, 2023 at 12:00:54 PM UTC-4 Bram Moolenaar wrote:
> > [...] > > > > > - Tree sitter's AST allows other functionality. > > > > [nvim-treesitter-textobjects]( > https://github.com/nvim-treesitter/nvim-treesitter-textobjects) > > > > allows for key combinations like `daf` (delete around function) and > > > > motions like `ic` (inside class). I don't believe these are > impossible > > > > with Textmate grammars, but I can't find any precedent of this > either. > > > Isn't this a matter of naming rules properly? Just like we currently > > > have the convention that "fooComment" is used for comments in the "foo" > > > filetype. > > > > I'm not sure. If you have one function nested inside another, can you > > determine where the inner one beings and ends? > > This depends on how the result of parsing can be accessed. Currently we > only have synstack(), which is insufficient. It requires returning more > information about each syntax item. At least the start position. > Getting the end position would be nice, but it can be expensive if the > file was only partly parsed (to optimize performance). E.g. if the > window shows the start of a long file, which contains a class that takes > up the whole file, the text could be shown by only parsing a limited > number of lines (window height), while parsing until the end of the > class can be a hundred times slower. We probably need some option to > tell Vim whether speed is more important than complete information, or > the other way around. I believe treesitter implementations always > parse the whole file anyway. > > > > Just looking at the c/highlights.scm file, it seems that it's not just > > > translation, this also defines tokens such as "__attribute__". Does > > > this mean there is duplication between files? > > > > There's a few different ones. I'm not good at explaining what they > translate > > because I'm missing terminology with some internals here. Here are all > the > > queries for `C`: > > > > > https://github.com/nvim-treesitter/nvim-treesitter/tree/f499a711fa5c573b5ba0af09a3c9955a6c14b062/queries/c > > That's what I was referring to, the "highlights.scm" file in that > directory. > > > > > - Given that the above mentioned queries are only guaranteed to work > > > > with the same version of the parser for which they were written, the > > > > version of the query and the parsers needs to be kept in sync (neovim > > > > addresses this by downloading a pinned version of the parser). > > >And how does an end user find out what highlight group to use for an > > >item? Searching the files, what you can do with the current Vim syntax > > >plugins and a bit of guessing, seems too complicated. > > > > `highlights.scm` translate tree sitter nodes into capture groups. > > These capture groups map directly to well-known highlight groups. > > However, besides "tree sitter nodes" there are literal keywords here. > It looks like the syntax file has been split in two parts that carefully > need to be kept in sync. And errors will be quite hard to track down. > Would there be an error if the highlights.scm file uses a name that is > not a treesitter node? > > > I do think having support for multiple syntax sources is the best, > because a > > slow one can enhance the results of a fast one. There's also semantic > > highlighting on top of syntax highlighting. For example, an LSP can > > point out unused or deprecated tokens which can be highlighted as > > greyed-out and strikethrough respectively. > > I expect LSP to provide much more information, we don't intend to go > that way with syntax highlighting. E.g., a variable name could be > highlighted if recognized, but there is no reference to where it is > declared. LSP does provide that information. > > > On a separate note, some of the examples in this thread has proved > > that Vim's current APIs are sufficient to implement any kind of > > highlighter as a plugin; I don't think there's anything that needs to > > be done right now (aside from writing plugins and continuing refining > > on them). > > The two main goals I see are: > > 1. Add grammers that are used by other editors, to avoid having to > maintain a Vim-specific implementation. And the other way around: > a grammer written for Vim can also be used by other editors. > > 2. Provide a complete parsed syntax tree. The current implementation > has some caching, but synstack() returns very limited information and > can be quite slow. We would want something that allows for movement > commands, e.g. "jump to start of function". > > -- > BEDEVERE: Look! It's the old man from scene 24 - what's he Doing here? > ARTHUR: He is the keeper of the Bridge. He asks each traveler five > questions ... > GALAHAD: Three questions. > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > — > > > Reply to this email directly, view it on GitHub > <https://github.com/vim/vim/issues/9087#issuecomment-1509879728>. > > You are receiving this because you are subscribed to this thread.Message > ID: <vim/vim/issues/9087/[email protected]> > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/2231824f-ad97-418c-9fb9-0935d4aa8f5an%40googlegroups.com.
