> On 7/7/22 2:21 PM, Bram Moolenaar wrote: > >>>> Other than that, I don't see support of Tree-Sitter, which could be > >>>> useful for things like: > >>>> - syntax highlighting > >>>> - folding > >>>> - text objects defined by syntax (to e.g. select or move by > >>>> function/class/string/statement...) > >>>> - and probably other things (e.g. being able to show syntax info) > >>> There was a discussion about what engine to use for parsing, and > >>> tree-sitter was considered old and difficult to use. Let's leave out > >>> the name and just say "fast syntax parser". > >>> > >> When I read one long vim thread about additional parser system. I came > >> away with the impression that it was TextMate that was old and > >> difficult, and TreeSitter that was more modern(of course, could be > >> wrong); in particular it is actually a language parser rather than regex > >> based. I bring this up not to start a flame war in this thread, but to > >> mention that accuracy is another dimension, not just speed. > > It's easy to mix up different parsers. TextMate is also considered a > > problem in this discussion: https://github.com/microsoft/vscode/issues/50140 > > > > Perhaps there is a third alternative? > > > >> It might be heresy, but it would be cool if a separate thread could > >> dynamically calculate syntax/folding/... info; it is at least > >> conceivable if the parsing system is independent from vim, doesn't use > >> vim functions. > > Yes, but multi-threading is very tricky to get right in C. And > > debugging problems very time consuming. Using a separate process might > > work better. > > Yeah, it might. I was thinking that the parser would only read > vim-buffers, and that vim would only read parser results, and vim would > message the parser about where the buffer is changed, fairly simple > interaction model. I've never used, or considered, C multi-threading, so > I don't know of any special issues; there is needing to use the > threading versions of the libs. Thinking of separate process, which > seems safer, it seemed like data sharing is more expensive or more of a > hassle, unless all of vim-buffers could be in shared memory segments.
Well, that sounds simple, but it's actually the start of where things go wrong. The current low-level buffer implementation keeps only one line available. If another thread requests a different line it would cause the current line to be released, while it might be in use. Thus this can only be allowed when Vim is waiting for a character to be typed. And then it may cause file I/O to the swap file. We already have taken care of asynchronous I/O for channels, better use that intead of adding another tricky mechanism. One could use channels between threads, I suppose. -- ASCII stupid question, get a stupid ANSI. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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/20220708084749.8DF021C08DA%40moolenaar.net.
