Prabir Shrestha wrote:
> -1 for }. That is the most absurd syntax I have seen in any language that > only uses it for closing. OK, it appears nobody likes it. The whole idea of experimenting is to try out alternatives. > So I went and re-read the poll https://github.com/vim/vim/issues/3573. And > here is what I can think of reading it again in Jan 2020. > > Can we get more info on what does make vim-script faster mean? > > [image: Screen Shot 2020-01-04 at 3.53.13 PM.png] > > [image: Screen Shot 2020-01-04 at 4.04.27 PM.png] > > [image: Screen Shot 2020-01-04 at 4.05.36 PM.png] > > > > Second comment there says about syntax highlighting. So making vimscript > faster here won't help much because [tree-sitter]( > https://tree-sitter.github.io/tree-sitter/) will be lot faster than > vimscript, which means syntax highlighting in neovim will also be more > accurate and faster then vim. As I mentioned before, using an external tool is the main alternative. With channel support and text properties the pieces are already available today. > Instead of picking up non real world examples to demonstrate perf gains can > we pick some proper goals. > > Here are some of the examples I can think of: > > * Faster fuzzy finder. Currently there is 0 plugins that is fast in pure > vimscript. I would like to see an example of FuzzyFinder in vim9 that is > fast as https://github.com/liuchengxu/vim-clap and > https://github.com/junegunn/fzf.vim. Few requirements here: Searching large > number of nested directories and files, highlighting matches. Some of these > I elaborated in this comment > https://github.com/vim/vim/issues/3573#issuecomment-433730939. It's impossible to measure the speed of a whole plugin without implementing 99% of the compiling and execution. We'll have to start with simple examples to check if we are going in the right direction. Feel free to come up with some part that needs to be fast and is simple enough we could implement that part of the compilation/execution. > * vim9 syntax highlighting vs neovim tree-sitter syntax highlighting. We > should count speed as well as accuracy. As mentioned above, you can already do that. With Vim9 script the part inside Vim will be faster. By how much is hard to predict. > * Fuzzy search for auto complete popup menu. > > > I still think WASM is the way to go and not vimscript 9. This way I can > code in what ever language suits me and just ship the bytecode. I already explained that using an external tool allows you to do this. > For example: will vimscript 9 support generics/async,await/pattern > matching/threading or greenthreads/immutability? This list will keep going > on. Making it fast is just one issue it solves. A language gets attractive > not just for perf but many other features that come around it. We can add some more in Vim9, but it's not what plugin authors have been asking for. > Here is a new WASM runtime since I last mentioned which claims to be 15x > faster then other c wasm runtimes. https://github.com/wasm3/wasm3. I'm sure other languages like C and Go will be even faster. > As a plugin author I can then code in any languages I want that suits the > needed. For example a python dev might write in python, a JS dev might > right in Javascript or Typescript if they need typing. And they can still > write in go/rust/zig or even c if they need performance. And most languages > these days already support compiling to WASM. The point I made was that you can use any language you like, just run it as an external tool and communicate with Vim. I don't see how integrating any language interface inside Vim would work better. We do have enough evidence that the exising ones are not popular, adding another one is unlikely going to change that. -- "When I die, I want a tombstone that says "GAME OVER" - Ton Richters /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ 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/202001051308.005D8hBj011359%40masaka.moolenaar.net.
