Vim 9.0 Released
vim.org
vim.org
> - Lua arrays are now one-based, they used to be zero-based.
Lua 5.4.4 Copyright (C) 1994-2022 Lua.org, PUC-Rio
> t = {"hello"}
> print(#t)
1
> t[0]
nil
> t[1]
hello
well, I'm sure that won't cause one of the most famous hard things in computer science. Then again, maybe vim9 pre-releases were "we can change things until release," so in that way I'm super glad they fixed it before it became a very widespread problem but I wonder how they chose to use the C-style default in the first placeFWIW, I tried to find the authoritative answer to whether lua was specified as 1-indexed or 0-indexed in the fine manual <https://www.lua.org/manual/5.4/manual.html#2.1> but it chose to just say that that tables are associative arrays with almost any values as keys, so with that language "t[0]" is no more special than "t[3.1415]"
As for 1-based indexing, you could say it's for historical reasons but essentially it was to make Lua more friendly as a beginner-friendly scripting language. Whether or not that makes any sense is up to you :) My source is this talk by the creator of the language [1]. Sorry I don't have a timestamp handy.
Using an index of 0 to represent the first item is one of the most ridiculous conventions in programming (nulls being another).
Which is what you're saying, but yeah— I think zero indexing is one of those things that's like... a bit sucky, but the alternative is enough-worse that it makes sense to just get used to it.
Here is an example of a 10-byte array with 1-byte items starting at address "5":
array cells xx xx xx xx xx xx xx xx xx xx
item number 1 2 3 4 5 6 7 8 9 10
mem offset 0 1 2 3 4 5 6 7 8 9
mem address 5 6 7 8 9 10 11 12 13 14
To get the 1st item, just take "5 + 0" to get the address to read from, and etc.It's mostly because it was easier to just think in offsets starting from 0 rather than think in item numbers and have to always remember to use the "item number - 1" as the memory offset for that item.
I can't quite think of a good reason to keep using vim over Neovim, but I was curious if anyone had a reason.
When I say it uses lua for scripting, I mean that it makes lua a first class configuration language for the platform as an alternative to vimscript.
> The dictator hasn't gone anywhere
When I say benevolent dictator I mean in it in the same way that Guido van Rossum was the benevolent dictator for python. Is there a plan for what happens to vim when the maintainer gets hit by a bus?
Nothing public, at least, and that's OK.
Why should there be? All code is freely available; anyone can do anything they want with it.
Neovim might even fill that role when the time comes.
The new Vim language for me is a major draw -- I have always found Lua to be a poor choice for Neovim, especially since it exists side-by-side with the existing language. The tight integration of VimL with the editor mechanics has made it attractive for development in vim, and I'm excited to see it moved forward.
I don't know if I'll make the switch back, but I think I'll at least give it a shot.
$ nvim -g
nvim: Unknown option argument: "-g"
It seems from reading the issues their approach is "build one yourself from some other projects," so no thanks> Neovim is backwards compatible with existing vim packages
It's not. Vim development was going strong at the time Neovim was forked and it has been going strong ever since so the two have diverged in noticeable ways. Neovim may be compatible with most <7.4 plugins but a lot happened since then.
> and has a better looking future as far as longevity (multiple maintainers vs benevolent dictator)
Neovim wouldn't even be a running executable without the decades of hard work by that "benevolent dictator" and hundreds of contributors so, we will see when we get there.
> using lua for scripting (there's still support for vim script)
Well, Vimscript is fine. I have written a number of plugins with it and I have nothing to complain about. FWIW, Vim has had a Lua interface for 10 or so years so, if you really love Lua, go for it.
Vim has a minimal set which you can install.
> Neovim is backwards compatible with existing vim packages, and has a better looking future as far as longevity (multiple maintainers vs benevolent dictator) along with using lua for scripting (there's still support for vim script).
Lua is a red flag. My editor shall not have any dependencies. Especially those who can give strange errors and you cannot fix them because " lua has its own build system".
> I can't quite think of a good reason to keep using vim over Neovim, but I was curious if anyone had a reason.
I prefer non bloated programs.
Except that it's not, and that features were changed or even outright removed.
I use the crypt feature in Vim, and Neovim removed that. It's "secure enough" security for my purposes (and now that it uses libsodium it's actually just "secure") and much easier than the alternatives. Removal of the integrated X11 clipboard support is also annoying.
I like the attention to compatibility; I can update from any version to any other version and be confident that Vim will "just work". Arguably, Vim is compatible to a fault; for example the defaults are not so great, but on the other hand changing a default also means changing people's Vim when it updates, so there's no easy decision. I do think some should probably be updated though; defaults.vim was a mistake). Neovim, on the other hand, gave me a bunch of errors, sometimes quite confusing ones that made no sense at all, and some defaults actually don't work all that great for me.
I prefer VimScript over Lua; if I see some of the verbose stuff people write in Lua then meh. I also don't think Lua is that great of a language to start with: no error on undefined variables, no continue. I mean, it's okay, but it's not great either. I'll go a step further and say I actually like Vimscript; yes, there are warts and annoyances, but a DSL like VimScript is much easier for interfacing with an editor than something like Lua. VimScript9 also fixes most of the issues. VimScript still works in Neovim of course, but it's a second-class citizen, and VimScript9 support seems unlikely.
As far as I know, there are no changes or features in Neovim has that I really want. Integrated LSP is nice, but vim-lsc works well enough. The nicer commandline completion menu was nice too, but Vim added something similar a few months ago and it wasn't a big deal in the first place. Lua is not something I especially like, as mentioned, and looking at :help nvim-features there isn't really anything else that catches my interest.
It's the same reason my vimrc is <10 lines long. I don't want it to be so long I couldn't just type out the critical parts from memory.
Vim works fine and is consistently being updated with all sorts of features stemming from Neovim's development. I think it's great to have competition but I won't bother unless Vim ceases development, something I don't think will happen anytime soon yet.
Why should I? I only miss tree-sitter syntax highlighting and hope Vim integrates it sometime in future. Other than that, the built-in LSP of neovim does not appeal to me since I've already "gave-in" to node-js and coc ecosystem
I don't like how they changed the config. It's more modern, sure, but it now means I can't just send my vimrc to a server.
I used nvim briefly then switched back. The only thing that makes me want to ditch vim is Bram's reaction to the initial PRs that spawned nvim in the first place. But, like, I can be crusty too, and I like that nvim is serving as competition to move Vim along faster.
I had plugins that didn't work and had to look for neovim equivalents.
I felt lost in figuring out how to adapt my configuration to the neovim way of things
I tried some features (treesitter?) and had crashes
Maybe its something about the switch nerd sniped me into re-doing all of my config (whether LSP, treesitter, lua, etc related) which bogged me down.
I'm odd and prefer a GUI but the GUI ecosystem for neovim is too fractured. Instead of people coordinating to get one polished enough, everyone goes and writes there own. I also had to take the time to research it.
In general, it felt like a major change that required a lot of research when I just want sane defaults out of the box (and not some bespoke config layer that just adds yet another thing I need to learn)
Python and Linux also have a benevolent dictator and they seem to be doing fine btw.
I think I've tried neovim at some point but as long as vim does the job I see no reason to make it harder than it needs to be.
Even my use of vim is quite limited, no package manager, no distro, just vim and a few syntax files and ftplugins.
First, I was shocked that they changed the behavior of Y. That was bananas to me. But I discovered that really early on and powered through.
What's making me move back is I just opened a huge CSV file in vimr, and it hung forever. Usually you can ^C to make vim quit counting lines, but no dice. That's a non-starter for me, unfortunately. I was really into the Lua support, but so be it.
Isn't this an issue with VimR and not NeoVim? I've used terminal NeoVim since it started and literally never had it choke on anything, ever. VimR is just a GUI wrapper, and while a neat project, it has tons of problems.
neovide: colors oversaturated and seemingly always antialiases, even when you try and turn it off [0]. It also crashes on "set guifont=ProggySquare:h11".
goneovim: colors oversaturated
neovim-qt: colors oversaturated
gnvim: looks unmaintained, no macos package (probably easy to build, but why)
neovim-gtk: looks unmaintained