19 ms·

Vim9: An experimental fork of Vim to explore making Vim script faster and better

142 points by earenndil 7y ago

coldtea 7y ago
I've seen this posted 4-5 times (via the "past link") and 0 comments in all. Are the usual posts with comments (e.g. on some minor version release of a framework) on HN so much more interesting than a potential feature direction of a staple UNIX editor with a redesigned scripting language?
- Jeaye 7y ago
  I think the wording of the title is likely making people think this is "just another fork". However, this is made by Bram and he's looking to drastically optimize the way VimScript functions are called (as opposed to redesigning the scription language). Either way, I'm happy that I saw it 1 of the handful of times it's been posted. Being a NeoVim regular, though, I'm more interested about how/if this carries over and what the gains would be there.
- sojournerc 7y ago
  Seems like some impressive improvement in benchmarks, but for me vim already just works. I never feel like it's slowing me down, and I can get everything I need from it. Maybe it's a sign of vim's maturity that such news isn't received with much fanfare.
  - JadeNB 7y ago
    > Seems like some impressive improvement in benchmarks, but for me vim already just works. > I never feel like it's slowing me down, and I can get everything I need from it. I feel the same way personally, but do you do a lot of scripting of vim? I don't, and I get the impression that that is a lot of pain points for vimmers much more experienced than I, so that that may explain why people like us don't see the need for such optimisation.
CGamesPlay 7y ago
So, if the new language is fundamentally incompatible with the old VimScript, why keep using VimScript? Lua already seems pretty fast, why not just make a fork where Lua is the default scripting language? (Note, not considering JavaScript in the benchmarks seems like a pretty big oversight before making a conclusion of new default language.)
- layoutIfNeeded 7y ago
  Or emacs lisp!
  - bjoli 7y ago
    Unless you want to be in some way compatible with Emacs, elisp is not a language I would use. Anyone who has written any non-trivial amount of elisp knows this. There are other lispy languages, that are easier to embed without many of the warts of elisp. If you really want to have elisp, you have 3 ootions: * Implementing it yourself * Trying to break elisp and Emacs apart (not likely) * Using guile's elisp implementation. It is complete and all that, but then you should just use guile scheme instead.
    - wbl 7y ago
      There already is an editor that uses Emacs Lisp for scripting.
  - nathell 7y ago
    Or Guile.
    - earenndil 7y ago
      Guile doesn't work on windows.
      - bjoli 7y ago
        Sure it does. It is just unsupported :) I cross compiled 2.0 without much fuzz at all many moons ago without other changes than a small work-around for a bug in mingw. 2.2 should be about the same. 3.0 (or rather, the 2.9 beta) could possibly be quite a lot harder
wyclif 7y ago
Why would people want to adopt and use Vim9 instead of NeoVim, which eliminates a lot of cruft and uses Lua? Interested in knowledgeable responses from Vimmers and NeoVimmers.
- deleted 7y ago
  [deleted]
- weaksauce 7y ago
  I don’t know. Vimscript is and was a terrible language to program in. Lua is so much nicer.
  - city41 7y ago
    I also never want to learn a language for a single environment. With Lua and the like, I can use them in many other places, making learning them much more useful.
    - stewbrew 7y ago
      The language is only a very small and trivial part. Most time is spent with learning the API that necessarily is app specific.
      - kilburn 7y ago
        This is true only if what you're building is big enough. For something like vimscript, where most people are likely to script minor stuff, the marginal cost of learning the scripting language itself is non-trivial and increases the "barrier of entry" significantly.
        stewbrew 7y ago
        For minor stuff you spend most time on learing ex commands (i.e. VIM API). Also, vimscript is a rather simple language. It's not haskell, we're talking about.
csscrack 7y ago
While I am reading this I just compare Bram as a maintainer re pace, creativity and ideas before and after Neovim was born. People who more into that stuff are the Vim9 benchmarks not underwhelming compared to Lua or did I miss something?
- mixedCase 7y ago
  >are the Vim9 benchmarks not underwhelming compared to Lua or did I miss something? Apparently that's the case, Bram did not compare against LuaJIT making the benchmarks pointless. They would quickly point out that Vimscript 2 also is, if this Reddit comment thread is to be believed: https://www.reddit.com/r/vim/comments/ejfn57/vim9/fcxi99k/ https://www.reddit.com/r/vim/comments/ejfn57/vim9/fcxi99k/ where justinmk is one of the Neovim core devs. As an end user, Vim feels (IMO) like a dead-end. It's cool that Bram has started trying new things but he comes off as too protective of his creation, which is fine, but then it's normal for the community to move as well.
- runningskull 7y ago
  You’re right about Neovim’s effect on Vim improvements and lighting a fire in Bram. Even if neovim goes belly-up (unlikely), or totally diverges (slightly less unlikely), they’ve done a huge service to the vim community simply by existing and offering compelling, thoughtful enhancements while respecting the core spirit of vim - and being exceptionally mindful of practicality in how they approach changes. Probably one of the best-ever examples of a fork that is Doing It Right.
vikinghckr 7y ago
I find it quite impressive that Bram still finds time to not just maintain Vim but also adding drastic new features like this, while doing a full time job at Google at the same time.
Avi-D-coder 7y ago
I have the displeasure of knowing vimscript. I have a couple plugins and contribute to others. vimscript is terrible, it's unintuitive, neither fp nor oop, and fails to integrate any domain specific features. It could and should be replaced by any other fast scripting language. Kill vimscript adopt Lua for compatibly or Gluon for fp.
- stewbrew 7y ago
  Vimscript is a collection of ex commands (i.e., a DSL for editors) with a few functions bolted on that provide for a simple form of OOP. I don't think your argument is 100% fair.
  - Avi-D-coder 7y ago
    Being a collection of commands that can be entered in a repl does not make it a text centric DSL Text manipulation in vimscript is more verbose than Rust including all ownership syntax. What elements of vimscripts design make it good at parsing and manipulating text? I can imagine a beautiful text centric EDSL in Haskell or a lisp that integrates tree sitter to provide syntactic hooks. I don't blame vimscript for not having this modern integration, but I do blame it for being a poorly designed language and I condemn any attempts to prolong its life. Over in NeoVim land treesitter is being integrated. Once it lands someone should write a EDSL in the Lua lisp.
    - stewbrew 7y ago
      `:help :syntax`?
      - Avi-D-coder 7y ago
        I've written vim syntax files before. Syntax highlighting and an error tolerant syntax aware Text manipulation EDSL are very different.
  - hibbelig 7y ago
    To me those ex commands feel more like a standard library than a DSL. But I know very little about vimscript and I’m happy to be corrected.
enricozb 7y ago
Check out Kakoune[1] for a different take on an editor’s scripting language. It offloads as much as possible to existing Unix tools such as bash, sort, fmt, etc. It uses a clever system of string substitutions that’s a bit unintuitive at first, but not too difficult to grasp quickly. I spent two weeks trying to fix a bug in a Vim plugin that ended up being a 3 line change. After that I felt like I barely understood just a small section of vimscript. I ended up switching to Kakoune after trying it for a bit because I realized that in the two weeks of me exploring it I had entirely understood it’s “scripting language”, or at the very least understood how to use the onboard docs to write any plugin I wanted to. [1]: https://github.com/mawww/kakoune https://github.com/mawww/kakoune
- timeattack 7y ago
  Sorry, but I find this to be very bad design. Check this out [1]: kak script evaluating sh script which in turn call perl which constructs kak script commands and output them to stdout to be evaluated by kak. Or this one [2]: same, as before, but now it's calling awk, which calls `date` binary (so it's kak → shell → awk → date → kak). It seems that it's done this way because sh is not good programming language to use for manipulating text. Moreover, sh is not good programming language to write complicated programs, which later can be successfully maintained & tested. For me, kak approach is past the border of unmaintainability. Also, it raises question of why not to use embedded language like python or lua instead of creating such a limited editor-specific language. [1]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L114 https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c... [2]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L73 https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...
  - dmos62 7y ago
    I'm interested in seeing a response to this. I sympathize with wanting to use unix tool composition, but I've personally found shell languages inadequate for more interesting applications.
    - 7y ago
deleted 7y ago
[deleted]
kzrdude 7y ago
Why not have it as an incremental improvement? Similar to javascript engines, jit the easily executable code and fall back to the slow path if any of the listed slow features are encountered. Incrementalism is powerful, even if it also takes a lot of work; breaking changes in Vim script are probably not worth it for anyone.
xvilka 7y ago
Reminds me of early attempts[1] by NeoVim developers to make VimL to Lua translator. [1] https://github.com/neovim/neovim/pull/243 https://github.com/neovim/neovim/pull/243
bachmeier 7y ago
Many of the comments here appear to have been made without reading the full post. Maybe because I'm not a Vim user it made sense to read the post in its entirety. From the post: "Attempts have been made to implement functionality with built-in script languages such as Python, Perl, Lua, Tcl and Ruby. This never gained much foothold, for various reasons. Instead of using script language support in Vim: Encourage implementing external tools in any language and communicate with them. The job and channel support already makes this possible. Really any language can be used, also Java and Go, which are not available built-in. Phase out the built-in language interfaces, make maintenance a bit easier and executables easier to build. They will be kept for backwards compatibility, no new features. Improve the Vim script language, so that it can be used when an external tool is undesired. All together this creates a clear situation: Vim with the +eval feature will be sufficient for most plugins, while some plugins require installing a tool that can be written in any language. No confusion about having Vim but the plugin not working because some specific language is missing. This is a good long term goal." So, as I read this, his argument is that it makes sense to offer both external language support and Vimscript.
eddhead 7y ago
Oh no, it's only been half an hour since the last Vim related article. Can write a few more please? Cmon HN, write some more. Use Vim, you'll write them faster too!
- marmada 7y ago
  This one is actually very interesting, it's not just a Vim tutorial.
  - eddhead 7y ago
    Doesn't matter, Vim is a diminishing editor with very niche use cases and used by people who refuse to move on to more productive editors like VS code. It's annoying that half of HN articles are about this.
    - majewsky 7y ago
      I want to edit a file in an Alpine container somewhere on the other side of the world. Where's your god now?
      - eddhead 7y ago
        Yes, Vim is for you. But for ANYBODY else it's pointless.
mutant 7y ago
I thought this was the goal of neovim as well.

142 points by earenndil 7y ago

I've seen this posted 4-5 times (via the "past link") and 0 comments in all. Are the usual posts with comments (e.g. on some minor version release of a framework) on HN so much more interesting than a potential feature direction of a staple UNIX editor with a redesigned scripting language?

Jeaye 7y ago
I think the wording of the title is likely making people think this is "just another fork". However, this is made by Bram and he's looking to drastically optimize the way VimScript functions are called (as opposed to redesigning the scription language). Either way, I'm happy that I saw it 1 of the handful of times it's been posted. Being a NeoVim regular, though, I'm more interested about how/if this carries over and what the gains would be there.
sojournerc 7y ago
Seems like some impressive improvement in benchmarks, but for me vim already just works. I never feel like it's slowing me down, and I can get everything I need from it. Maybe it's a sign of vim's maturity that such news isn't received with much fanfare.
- JadeNB 7y ago
  > Seems like some impressive improvement in benchmarks, but for me vim already just works. > I never feel like it's slowing me down, and I can get everything I need from it. I feel the same way personally, but do you do a lot of scripting of vim? I don't, and I get the impression that that is a lot of pain points for vimmers much more experienced than I, so that that may explain why people like us don't see the need for such optimisation.

CGamesPlay 7y ago

So, if the new language is fundamentally incompatible with the old VimScript, why keep using VimScript? Lua already seems pretty fast, why not just make a fork where Lua is the default scripting language? (Note, not considering JavaScript in the benchmarks seems like a pretty big oversight before making a conclusion of new default language.)

layoutIfNeeded 7y ago
Or emacs lisp!
- bjoli 7y ago
  Unless you want to be in some way compatible with Emacs, elisp is not a language I would use. Anyone who has written any non-trivial amount of elisp knows this. There are other lispy languages, that are easier to embed without many of the warts of elisp. If you really want to have elisp, you have 3 ootions: * Implementing it yourself * Trying to break elisp and Emacs apart (not likely) * Using guile's elisp implementation. It is complete and all that, but then you should just use guile scheme instead.
  - wbl 7y ago
    There already is an editor that uses Emacs Lisp for scripting.
- nathell 7y ago
  Or Guile.
  - earenndil 7y ago
    Guile doesn't work on windows.
    - bjoli 7y ago
      Sure it does. It is just unsupported :) I cross compiled 2.0 without much fuzz at all many moons ago without other changes than a small work-around for a bug in mingw. 2.2 should be about the same. 3.0 (or rather, the 2.9 beta) could possibly be quite a lot harder

wyclif 7y ago

Why would people want to adopt and use Vim9 instead of NeoVim, which eliminates a lot of cruft and uses Lua? Interested in knowledgeable responses from Vimmers and NeoVimmers.

deleted 7y ago
[deleted]
weaksauce 7y ago
I don’t know. Vimscript is and was a terrible language to program in. Lua is so much nicer.
- city41 7y ago
  I also never want to learn a language for a single environment. With Lua and the like, I can use them in many other places, making learning them much more useful.
  - stewbrew 7y ago
    The language is only a very small and trivial part. Most time is spent with learning the API that necessarily is app specific.
    - kilburn 7y ago
      This is true only if what you're building is big enough. For something like vimscript, where most people are likely to script minor stuff, the marginal cost of learning the scripting language itself is non-trivial and increases the "barrier of entry" significantly.
      - stewbrew 7y ago
        For minor stuff you spend most time on learing ex commands (i.e. VIM API). Also, vimscript is a rather simple language. It's not haskell, we're talking about.

csscrack 7y ago

While I am reading this I just compare Bram as a maintainer re pace, creativity and ideas before and after Neovim was born. People who more into that stuff are the Vim9 benchmarks not underwhelming compared to Lua or did I miss something?

mixedCase 7y ago
>are the Vim9 benchmarks not underwhelming compared to Lua or did I miss something? Apparently that's the case, Bram did not compare against LuaJIT making the benchmarks pointless. They would quickly point out that Vimscript 2 also is, if this Reddit comment thread is to be believed: https://www.reddit.com/r/vim/comments/ejfn57/vim9/fcxi99k/ https://www.reddit.com/r/vim/comments/ejfn57/vim9/fcxi99k/ where justinmk is one of the Neovim core devs. As an end user, Vim feels (IMO) like a dead-end. It's cool that Bram has started trying new things but he comes off as too protective of his creation, which is fine, but then it's normal for the community to move as well.
runningskull 7y ago
You’re right about Neovim’s effect on Vim improvements and lighting a fire in Bram. Even if neovim goes belly-up (unlikely), or totally diverges (slightly less unlikely), they’ve done a huge service to the vim community simply by existing and offering compelling, thoughtful enhancements while respecting the core spirit of vim - and being exceptionally mindful of practicality in how they approach changes. Probably one of the best-ever examples of a fork that is Doing It Right.

vikinghckr 7y ago

I find it quite impressive that Bram still finds time to not just maintain Vim but also adding drastic new features like this, while doing a full time job at Google at the same time.

Avi-D-coder 7y ago

I have the displeasure of knowing vimscript. I have a couple plugins and contribute to others. vimscript is terrible, it's unintuitive, neither fp nor oop, and fails to integrate any domain specific features. It could and should be replaced by any other fast scripting language. Kill vimscript adopt Lua for compatibly or Gluon for fp.

stewbrew 7y ago
Vimscript is a collection of ex commands (i.e., a DSL for editors) with a few functions bolted on that provide for a simple form of OOP. I don't think your argument is 100% fair.
- Avi-D-coder 7y ago
  Being a collection of commands that can be entered in a repl does not make it a text centric DSL Text manipulation in vimscript is more verbose than Rust including all ownership syntax. What elements of vimscripts design make it good at parsing and manipulating text? I can imagine a beautiful text centric EDSL in Haskell or a lisp that integrates tree sitter to provide syntactic hooks. I don't blame vimscript for not having this modern integration, but I do blame it for being a poorly designed language and I condemn any attempts to prolong its life. Over in NeoVim land treesitter is being integrated. Once it lands someone should write a EDSL in the Lua lisp.
  - stewbrew 7y ago
    `:help :syntax`?
    - Avi-D-coder 7y ago
      I've written vim syntax files before. Syntax highlighting and an error tolerant syntax aware Text manipulation EDSL are very different.
- hibbelig 7y ago
  To me those ex commands feel more like a standard library than a DSL. But I know very little about vimscript and I’m happy to be corrected.

enricozb 7y ago

Check out Kakoune[1] for a different take on an editor’s scripting language. It offloads as much as possible to existing Unix tools such as bash, sort, fmt, etc. It uses a clever system of string substitutions that’s a bit unintuitive at first, but not too difficult to grasp quickly. I spent two weeks trying to fix a bug in a Vim plugin that ended up being a 3 line change. After that I felt like I barely understood just a small section of vimscript. I ended up switching to Kakoune after trying it for a bit because I realized that in the two weeks of me exploring it I had entirely understood it’s “scripting language”, or at the very least understood how to use the onboard docs to write any plugin I wanted to. [1]: https://github.com/mawww/kakoune https://github.com/mawww/kakoune

timeattack 7y ago
Sorry, but I find this to be very bad design. Check this out [1]: kak script evaluating sh script which in turn call perl which constructs kak script commands and output them to stdout to be evaluated by kak. Or this one [2]: same, as before, but now it's calling awk, which calls `date` binary (so it's kak → shell → awk → date → kak). It seems that it's done this way because sh is not good programming language to use for manipulating text. Moreover, sh is not good programming language to write complicated programs, which later can be successfully maintained & tested. For me, kak approach is past the border of unmaintainability. Also, it raises question of why not to use embedded language like python or lua instead of creating such a limited editor-specific language. [1]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L114 https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c... [2]: https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92cb0da5347b7fef04436/rc/tools/git.kak#L73 https://github.com/mawww/kakoune/blob/25429a905b717d29bdf92c...
- dmos62 7y ago
  I'm interested in seeing a response to this. I sympathize with wanting to use unix tool composition, but I've personally found shell languages inadequate for more interesting applications.
  - 7y ago

deleted 7y ago

[deleted]

kzrdude 7y ago

Why not have it as an incremental improvement? Similar to javascript engines, jit the easily executable code and fall back to the slow path if any of the listed slow features are encountered. Incrementalism is powerful, even if it also takes a lot of work; breaking changes in Vim script are probably not worth it for anyone.

xvilka 7y ago

Reminds me of early attempts[1] by NeoVim developers to make VimL to Lua translator. [1] https://github.com/neovim/neovim/pull/243 https://github.com/neovim/neovim/pull/243

bachmeier 7y ago

Many of the comments here appear to have been made without reading the full post. Maybe because I'm not a Vim user it made sense to read the post in its entirety. From the post: "Attempts have been made to implement functionality with built-in script languages such as Python, Perl, Lua, Tcl and Ruby. This never gained much foothold, for various reasons. Instead of using script language support in Vim: Encourage implementing external tools in any language and communicate with them. The job and channel support already makes this possible. Really any language can be used, also Java and Go, which are not available built-in. Phase out the built-in language interfaces, make maintenance a bit easier and executables easier to build. They will be kept for backwards compatibility, no new features. Improve the Vim script language, so that it can be used when an external tool is undesired. All together this creates a clear situation: Vim with the +eval feature will be sufficient for most plugins, while some plugins require installing a tool that can be written in any language. No confusion about having Vim but the plugin not working because some specific language is missing. This is a good long term goal." So, as I read this, his argument is that it makes sense to offer both external language support and Vimscript.

eddhead 7y ago

Oh no, it's only been half an hour since the last Vim related article. Can write a few more please? Cmon HN, write some more. Use Vim, you'll write them faster too!

marmada 7y ago
This one is actually very interesting, it's not just a Vim tutorial.
- eddhead 7y ago
  Doesn't matter, Vim is a diminishing editor with very niche use cases and used by people who refuse to move on to more productive editors like VS code. It's annoying that half of HN articles are about this.
  - majewsky 7y ago
    I want to edit a file in an Alpine container somewhere on the other side of the world. Where's your god now?
    - eddhead 7y ago
      Yes, Vim is for you. But for ANYBODY else it's pointless.

mutant 7y ago

I thought this was the goal of neovim as well.