Vimscript isn't even consistent in this, as many functions are UpperCamelCase 
(EG, commands).

I'm concerned that people are going to start pulling in NPM libraries much more 
often. if Vim's ES6 implementation attempts to stay consistent with Vimscript, 
then JS libraries and VimScript are going to have feel super cumbersome to jump 
between.

Code will read messier, as there will be a jumble of different code styles, and 
it'll ultimately lead to difficulty with linting files. I can not stress too 
much how important linting and prettifying is for languages like JavaScript.

As for lookups, they can easily check for the camelCase version and look up 
snake_case if it fails. I'm not sure if it's worth harming the developer 
experience to avoid a single lookup for an action that is driven by a 
user-interaction anyway? This would also provide the ability for developers to 
document their usage and APIs separately, which may improve manual readability 
for users who don't want all the extra bits.

Instead of maintaining a legacy pattern simply because there's a legacy 
pattern, sticking with ES6 syntax seems to be more reasonable for the future 
consistency, readability, reliability, and maintainability of Vim. if Vim is 
adopting ES6 as a means to embrace a highly familiar language, why would we not 
also want to embrace the already familiar syntax?


Apr 1, 2019, 12:46 PM by [email protected]:

>> On 1 Apr 2019, at 11.04, David Demelier <>> [email protected] 
>> <mailto:[email protected]>>> > wrote:
>>
>> Given that ECMAScript use camelCase I'd suggest to rename the low level API. 
>> E.g. read_blob -> readBlob.
>>
>
> In this case read_blob is a low-level API that directly mirrors the 
> corresponding C function in Vim. In general, I think the benefits of being 
> consistent with Vim or VimScript notation trump ES community conventions. 
> Also, we have for example win_screenpos and winbufnr, that would either 
> become winScreenpos and winbufnr or winScreenPos and winBufNr. In the latter 
> case you wouldn’t be able to uniquely map back to vim functions, e.g. for 
> looking things up with :help (although there are only 1 or 2 examples like 
> that, _ is mostly used for namespacing of builtins).
>
> Best,
> Bob
>
>
>
> --
>  -- 
>  You received this message from the "vim_use" 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 
> <http://www.vim.org/maillist.php>
>  
>  --- 
>  You received this message because you are subscribed to the Google Groups 
> "vim_use" group.
>  To unsubscribe from this group and stop receiving emails from it, send an 
> email to > [email protected] 
> <mailto:[email protected]>> .
>  For more options, visit > https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>> .
>

-- 
-- 
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to