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 -- [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/202001051855.005ItqOB012938%40masaka.moolenaar.net.
