> > > * provide a interface to a debug adapter to allow debugging of vimscript > > executing in a Vim instance (i.e. Vim Debug Adapter) > Sure.
+1 for this. This is always the first function I write in a plugin. It would be good to either support chrome devtools debugg protocol or language server debug protocol. https://code.visualstudio.com/blogs/2018/08/07/debug-adapter-protocol-website But I'm not in hurry to have this. function! asyncomplete#log(...) abort if !empty(g:asyncomplete_log_file) call writefile([json_encode(a:000)], g:asyncomplete_log_file, 'a') endif endfunction * Scoped functions or lambdas containing ex-commands (or better, def > function bodies). When combined with try/finally, this would allow > constructs that take a "block" of code, such as "WithCurrentBuffer( buf, { > => block of code/commands, maybe split across lines } )" or something like > this when working with external tools `SendMessageToTool( message, then = { > => some block of ex commands } ). This can currently be done with Funcref, > but I think that you have to do 'function ...' and then 'delfiunc' as all > functions are currently global. Maybe the new scoping rules could be > extended to allow this. This was was something I mentioned before in a different post about vim9. It would really be good to allow multiple lines in lambda or functions.Frankly this is one of the biggest pain point I have with vimscript currently when dealing with async code. call job_start({ \ 'out_cb': {job, data-> \ if data != '' \ echom data \ endif \ } \ }) call job_start({ \ 'out_cb': function(job, data) abort \ if data != '' \ echom data \ endif \ endfunction \ }) I don't think WASM helps at all with syntax highlighting. The good old > Vim syntax highlighting depends on regexp patterns. I have already > optimized the speed of that, I don't think it can be improved much more. > The main alternative now is to use an external parser or language server > and communicate with it. Such as the govim plugin does. You an now use > text properties to highlight the text. I was hoping for vim to support WASM + WASM threads, so we can do most of the expensive functions in a thread. The biggest problem with having external jobs is that how do the users get the external binary that works in their OS. Languages such as rust and go having a single static binary has made it easy but this still suffers from compilation in some OS and the IT department allowing the random binary. Or might be what we need is "vim --server --script=server.vim" which can read and write to stdio/stdout/stderr or sockets. This way we can do heavy lifting in vimscript in a different process. https://github.com/prabirshrestha/vim-lsp/issues/633 - Semantic highlight slows down editing In vim-lsp we implemented semantic highlighting if langserver supports it using text_props, but then the protocol currently returns the entire document highlighting which we need to compute in vimscript, making it very slow. For now we have disabled this feature by default. The only way I can think of improving this is by using python threads or different process. FUNCTIONS SORTED ON SELF TIME count total (s) self (s) function 10004 2.192760 lsp#utils#base64_decode() 10004 2.202340 1.375972 <SNR>87_add_highlight() 10004 3.162274 0.504508 <SNR>87_tokens_to_hl_info() 30024 0.465006 <SNR>87_octets_to_number() 10005 0.351520 0.286610 lsp#capabilities#has_semantic_highlight() 100053 0.251802 <SNR>87_get_textprop_name() 1 5.561511 0.196170 lsp#ui#vim#semantic#handle_semantic() 10005 0.574658 0.169267 lsp#ui#vim#semantic#get_scopes() 20011 0.118792 lsp#get_server_capabilities() > Basically in strict mode it would still use a:name as the variable name > but > > it is no longer a dictionary. This way all new vimscript is 100% > compatible > > with old vimscript < 9 > I don't see that. If a: is no longer available as a dictionary it won't > be 100% compatible. There are other subtle assumptions, e.g. about how > error messages are handled. It will work like "abort" was present. This is why it is an explicit opt in using " use strict. By default it treats a:0 as a dictionary but if "use strict is turned on, it treats a:0 as a variable and not a dict. On Sunday, January 5, 2020 at 10:56:03 AM UTC-8, Bram Moolenaar wrote: > > > Ben Jackson wrote: > > > Hi Bram, thanks for sharing. Looks really promising. > > > > Regarding https://github.com/brammool/vim9#3-better-vim-script, I have > a > > few ideas for your consideration: > > > > * Execution often relies on user configuration (ignorecase, magic, etc.) > > and there is common boilerplate required in many scripts to set/restore > > cpo. Could we say that when `scriptversion` is `vim9`, we always execute > as > > if `set cpo&vim` ? > > For :def functions those will be parsed as if 'nocompatible' is set. > > For 'ignorecase' and 'magic' we can ignore those for the =~ and !~ > operators. What else? > > Not sure yet what will happen at the script level. No changes are > needed for speed. If needed the file can be put inside :def/:enddef > and then calling that function. Not ideal, but at least it's possible. > > > > * Line continuation. I know this is probably hard to change, but could > we > > look at a line-continuation scheme that's more familiar ? As we don't > have > > line termination, Perhaps something more like python's e.g. if a line > ends > > with an unbalanced parenthesis (or a `<backslash><newline>`), then > assume > > the next line is a continuation? I think the `<newline><backslash>` > syntax > > is unfamiliar to a lot of people. > > It will be difficult to implement, and we'll still need the old way of > line continuation in some places. Putting the backslash at the end of > the line isn't nice anyway, too easy to make mistakes, we should > probably not add it. Mixing the two is probably worse. > If we can have some statements continue on the next line without a > backslash remains to be seen. > > > * Scoped functions or lambdas containing ex-commands (or better, def > > function bodies). When combined with try/finally, this would allow > > constructs that take a "block" of code, such as "WithCurrentBuffer( buf, > { > > => block of code/commands, maybe split across lines } )" or something > like > > this when working with external tools `SendMessageToTool( message, then > = { > > => some block of ex commands } ). This can currently be done with > Funcref, > > but I think that you have to do 'function ...' and then 'delfiunc' as > all > > functions are currently global. Maybe the new scoping rules could be > > extended to allow this. > > That a function declared locally in a function becomes a global function > is indeed unexpected. We can at least make them local inside a :def > function, unless prefixed with g:, just like with variables. > > Defining a function and creating a funcref in one step would also be > useful. Not sure about the syntax. TypeScript does something like > this: > let ref = function(arg: type): rettype { ... body }; > > Perhaps we can do: > let ref = def(arg: type): rettype > ... body > enddef > > > I already mentioned elsewhere that the other barrier to entry for vim > > scripting is tooling and debugging. Hopefully with a these changes we > can > > consider how to: > > > > * extract the parser so that an external tool can parse and do code > > comprehension, go-to, refactor, etc., think Vim Language Server (there > is > > one, but it's not canonical) > > It's a lot easier to make an independent parser. Trying to share a > parser will make things very complicated. > > > * provide a interface to a debug adapter to allow debugging of vimscript > > executing in a Vim instance (i.e. Vim Debug Adapter) > > Sure. > > > * provide better source/line information for stack traces (so that we > can > > reliably jump to location of assertions e.g. test failures using cnext). > I > > saw a recent patch which improves sourcing_lineno and uses a proper > stack. > > I was planning to work on a patch to store source/line info when > debugging > > is enabled, but might hold off while vim 9 shakes down, as this is > likely > > required for the above debugger interface (assuming that's a goal). > > Yes, I started improving the execution stack. Currently it only tracks a > sequence of function calls, it does not continue with a :source command > or executing autocommands, and it's a string without file/line info. > This can be greatly improved. > > -- > ROBIN: (warily) And if you get a question wrong? > ARTHUR: You are cast into the Gorge of Eternal Peril. > ROBIN: Oh ... wacho! > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES > LTD > > /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/38ea6744-17e5-4e71-b953-a54e203434e2%40googlegroups.com.
