On 7/8/22 1:47 AM, Bram Moolenaar wrote:
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,
The first clue that that I didn't know enough about the problem space.
With care and foresight, an implementation using channels and a separate
process could be easily (another one of those danger words) migrated a
thread solution if the IPC overhead was too high.
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.
--
--
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/d6f2f910-f2c5-67e3-c50f-f3c946edb67a%40raelity.com.
