Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim 9.0

vim.org

Post reply on HN
Print view View original

121–130 of 272 posts

Re: Vim 9.0

#121

Post by Beltalowda »

mikl wrote: post #73

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

> This will give vimscript a Python 3 moment

Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible".

You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter.

> I wish he’d have embraced Lua like Neovim

Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.

Re: Vim 9.0

#122

Post by quasarj »

jcranmer wrote: post #18
Diederich wrote: post #6

Earlier quoted context omitted.

I've been using vi/vim on a near daily basis for 34 years now and this is the only thing I put in ~/.vimrc: set tabstop=4 set expandtab set shiftwidth=4 " or 2 or whatever set shiftround syntax on EDIT: Just for some fun archeology, I google searched on the 3rd line, 'set shiftwidth=4 " or 2 or whatever' because I very dimly recall copying most of my standard set (minus the syntax on bit) from someone else a long lon…

TIL about set shiftround... that would definitely help with > commands...

Me too, dang.

Re: Vim 9.0

#123

Post by iso1631 »

Vim 8 changed a lot of defaults - it enabled things like search as you type, scrolling as the cursor moves down the page rather than at the last line, etc.

A vimrc could revert this to standard behaviour, but that means having to have a vimrc file.

I was disappointed in those decisions.

Re: Vim 9.0

#124

Post by nicce »

wyclif wrote: post #117
jonaustin wrote: post #115

Earlier quoted context omitted.

Worth noting that one of the 5 listed NeoVim Non-Goals is "Turn Vim into an IDE" https://neovim.io/charter/

Yep, "neovim taking the IDE route" is a bad take.

What it means in this context? Creation of GUI? Vim is basically IDE at this point, if you configure it well and install plugins.

Re: Vim 9.0

#125

Post by ggm »

I kinda miss Bill Joy VI and Keith Bostic NVI. In saying that, I know nvi owes Elvis more than a little.

Vim is sort-of the defacto reality in my life now, but if two or three things around tab expansion and tab-to-space got fixed, I'd stick to nvi compiled and installed from pkg/ports/homebrew over anything else.

Re: Vim 9.0

#126

Post by dvogel »

Beltalowda wrote: post #121
mikl wrote: post #73

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

> This will give vimscript a Python 3 moment Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible". You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any…

This is all correct. To quote from the official description of vim9script:

    Vim9 script and legacy Vim script can be mixed.  There is no requirement to
    rewrite old scripts, they keep working as before.  You may want to use a few
    :def functions for code that needs to be fast.
So entirely the opposite of the python3 split.

Re: Vim 9.0

#127

Post by dvogel »

layer8 wrote: post #93
mikl wrote: post #73

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces. I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the…

I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor.

My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).

Re: Vim 9.0

#128

Post by dvogel »

givemeethekeys wrote: post #4

I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?

    $ du -s -h .vim
    22M .vim
A lot of that is git submodule history.

Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).

Re: Vim 9.0

#129

Post by dvogel »

Beltalowda wrote: post #63
alex_smart wrote: post #37

Earlier quoted context omitted.

> People don't like Lua (or just simply prefer VimScript) :shock:

I prefer VimScript over Lua. VimScript is really not that bad of a language and I think its deficiencies have been greatly exaggerated, and Vim9Script fixed most of the oddities that were in there (e.g. '1' == 1 and such, JS/PHP-style). Lua, on the other hand, won't give me an error if I mistype a variable name, and the ecosystem doesn't really have good static analysis tools to catch these kind of silly errors. Ther…

I feel the same way. Legacy vimscript certainly had some warts but vim9script has been much nicer IME than lua. Elsewhere I've likened vim9script to typescript 1.0. It has just enough types to be useful but not enough to let you go down a rabbit hole. That's sort of the sweet spot when scripting another application.

Re: Vim 9.0

#130

Post by int_19h »

layer8 wrote: post #99
oblio wrote: post #83

Earlier quoted context omitted.

Just like in math, and Lua doesn't do manual memory management so aligning stuff with memory addresses is not needed. They're both valid options and it's just about preference.

There are good reasons for zero-based indexing outside of pointer arithmetics: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

It's a well-known argument. It's also widely recognized as highly subjective, starting with the notion that upper bound must be exclusive.
Post reply on HN