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 place
FWIW, 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]"
My understanding is that Lua has "tables", not arrays, which have no inherent order and that it is the standard library that uses one-based indexing for historical reasons.
You are right! It works exactly like JavaScript where an array is just an object with sequential numerical keys (though there are nuances in Lua there when it comes to having "holes" in your table).
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.
0-based indexing is because of the original methods you would use to access sequential data. If you wanted to create an array with 100 1-byte integers you would literally just take 100 bytes of memory and call it an array. To access the first item in that array, you would read 1 byte at memory location `array_start + offset` and for the 1st item you would have an offset of 0 bytes. For the 2nd item, it would be accessed at an offset of 1 bytes.
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.
Zero-indexing doesn't just mean that the pointer to the first item in the block is the same as the pointer to the block itself, it also means that pointers to strides within the block have the same property.
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.
Whoa! 20 years in the game and I never thought about this—of course you want zero indexing when you have a 2D (or more) graph! I'll forgive myself, though, since I'm a web developer who has only ever had to do the most basic math.
A question for those of you still using vim. Why do you use it over Neovim (if you have heard of it)? 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).
I can't quite think of a good reason to keep using vim over Neovim, but I was curious if anyone had a reason.
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.
Neovim doesn't solve any problem I might have with Vim.
> 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.
I've switched to Neovim, but I am considering the switch back now that core vim has incorporated the async process stuff and the terminal support.
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.
> A question for those of you still using vim. Why do you use it over Neovim (if you have heard of 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 use vim for a living. I need it to work. Always. Neovim in my experience hasn't been as stable, not by a longshot. Neovim adds things I don't care about (lua, lsp, treesitter) while taking away things that are essential to me (gvim, rock solid stability).
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)
I prefer the DSL-like nature of viml over Lua. Yes, everyone likes to rag on viml, but just like any language with a lot of weird cruft in it (including some very popular ones millions of people use), once you learn it, it's not bad at all. That said, the new changes in 9.0 are welcome.
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 don't like getting used to stuff that I won't have on machines at work. There are a number of boxes where I have to work and don't have permission to install packages, so there's just vim.
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.
Everything you've offered enables switching but doesn't compel it, with the exception of lua. I don't write lua, nor have I found a lua plugin to interest me. The dictator hasn't gone anywhere (new major release). Vim still works.
> I don't write lua, nor have I found a lua plugin to interest me
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?
Vim is a tool by itself. There isn't the same large functionally independent body of work like a language has. I would compare it more to the BDFL for X-Chat that was forked as Hexchat.
Neovim might even fill that role when the time comes.
It's has a more recent version in Linux distributions. And it still has quirks like spewing garbage into my terminal after :wq. Vim dorsn't do that, nor require 5 additional libraries.
I've been using neovim for maybe 6 months now, but as of yesterday I'm gonna switch back.
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.
> What's making me move back is I just opened a huge CSV file in vimr, and it hung forever
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.
Well, I guess this is also under the umbrella of "why I'm switching back": GUI clients are kind of a mixed bag. Mostly, their colors are oversaturated and are unmaintained:
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)
I've heard of neovim, tried it out when it first came around, and decided that trying to cobble together a new set of plugins and adapt my configs ain't worth it.
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
> - Lua arrays are now one-based, they used to be zero-based.
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]"