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?
> 
> The “usual" expression operators behave differently (when not suffixed
> with # or ?) depending on `ignorecase`, right. As in: if x ==
> “CaseSensitiveMatch?” Depends on ignorecase.
> 
> Examples from :help expr4:
> 
> "abc" ==# "Abc"         evaluates to 0
> "abc" ==? "Abc"         evaluates to 1
> "abc" == "Abc"          evaluates to 1 if 'ignorecase' is set, 0 otherwise
> 
> I think this is one of those things you just have to know (like using
> === in javascirpt). Would be fewer accidental bugs if `==` worked
> consistently I guess.

I have already made it work like that, 'ignorecase' is not used.

> > 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.
> 
> I guess the javascript idiom here is to have an anonymous function that’s 
> immediately called:
> 
> ( def ( args ) : return type
>     Code
> enddef )()
> 
> But that’s hardly art. 

I like to take the good parts of JavaScript, not the weird parts :-).
It's very easy to miss the "()" at the end, especially if the function
takes up most of the file.
 
> >> * 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 personally like the python approach: a def inside a function is a local 
> variable of function type. As in:
> 
>   let myFunc = function( … ) { … body }
> 
> Would be written simply as
> 
>   def myFunc( … ):
>     … body
> 
> In vimscript we could do the same, having a nested ‘def’ always
> declare a local Funcref by name, but have a ‘real’ name that’s hidden
> from the user (like a lambda). In the above example, that would create
> a local variable ‘myFunc’ which is a Funcref to an (unnamed?) function
> with ( … ) args and  … body. Again, not sure how practical that is,
> but it _feels_ smiler to how lambdas currently work.

It can also made to work so that the function is defined normally, and
when using that name without () it will be a funcref, as if using
"function('FuncName')".  Then it also works for global functions, with
"g:" prepended.
 
> >> * provide a interface to a debug adapter to allow debugging of vimscript 
> >> executing in a Vim instance (i.e. Vim Debug Adapter)
> > 
> > Sure.
> 
> Woo \o/. Debugging vimscript with vimspector would be very kickass.
> I’m more than willing to put in hard graft to make this happen.

It's not really related to Vim9 script, could be an independend project.

-- 
BRIDGEKEEPER: What is your favorite colour?
GAWAIN:       Blue ...  No yelloooooww!
                 "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/202001052210.005MArOE019561%40masaka.moolenaar.net.

Raspunde prin e-mail lui