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

91–100 of 272 posts

Re: Vim 9.0

#91

Post by wruza »

capableweb wrote: post #20

As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're…

My opinion must be marginal, but in my view neovim community took an IDE route anyway so maybe it is a good thing if they separate, provided there is a way to switch. Because when you have a function in bigpkg.tgz, no incentive exists to dedicate a smaller package to it, and that changes the entire landscape dramatically and may create political issues in it. I actually liked simple little plugins vim had back in the day and not these coc/lsp/ycm things which compete in size with the editor itself, if not outright an order of magnitude larger. I tried to go neovim at least three times and it seems to be focusing on these big things, while e.g. having long standing issues in gui functionality on windows, namely gui mode (qt-nvim) resizes, window updates, file associations. With vim9 I’ll maybe finally learn to script it as I wish.

Re: Vim 9.0

#92

Post by hackerbrother »

Diederich wrote: post #6
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?

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…

I have a simple one too--

    set number
    setlocal cm=blowfish2
    set noswapfile
    set nobackup
    set nowritebackup
    set viminfo=
    set tabstop=4
    set softtabstop=0 noexpandtab
    set shiftwidth=4
    set noundofile
    set backspace=indent,eol,start
    set autoindent
    set smartindent
    set cindent
    autocmd BufRead,BufNewFile *.vue setfiletype html
    colorscheme morning
    
    map Q 
    map q 
    noremap x "_x
    
    let &t_ut=''
    
    if has("gui_running")
     :set guifont=Cascadia_Mono:h16:cANSI:qDRAFT
    endif

Re: Vim 9.0

#93

Post by layer8 »

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 dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.

Re: Vim 9.0

#94

Post by sbf501 »

Diederich wrote: post #6
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?

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…

   " My vimrc from 1994 to about 2000
   set et
   set ts=4
   " Added this circa 2000
   syntax on
   " Added this ~2013
   let g:solarized_termcolors=256
   set background=light
   colorscheme solarized

Re: Vim 9.0

#95

Post by kbumsik »

> to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java.

So...they make a new language to fix that? Couldn't they just use an existing language?

Re: Vim 9.0

#96

Post by layer8 »

the_duke wrote: post #3

I'm curious how many users are now using vim versus neovim. I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.

Debian switched back from Neovim to Vim as the default “vim” in Buster(?), so I switched back along with it.

Re: Vim 9.0

#97

Post by dvogel »

capableweb wrote: post #48
tomtomtom777 wrote: post #39

Earlier quoted context omitted.

Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with. In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult…

> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. > Couldn't they not convince Bram Moolenaar of proposed changes I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaa…

This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2...

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*
The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:

    Bram,
    I happy to see there is still some hope for this patch getting merged.
Then shortly afterward the other author gave Bram an ultimatum:

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.
Considering where the patch started, iterative feedback seems appropriate.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.
The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

Re: Vim 9.0

#98

Post by undoware »

BaculumMeumEst wrote: post #55
undoware wrote: post #25

I loved vi for decades, but I don't miss it. Neovim is my current go-to but even this feels stodgy these days. Helix Editor is probably my future -- it manages to have just the right features, but with saner defaults and syntax -- but it will take a while for me to work up the nerve to let go of the investment in muscle memory.

I don't think going all in on treesitter is very practical, considering basic python indentation has not been functional for over a year. I think Helix is a little bit too much of niche layered on niche, and Kakoune is much better all around in my experience. https://github.com/nvim-treesitter/nvim-treesitter/issues/80...

that sounds hard but I... don't often code in python?

I can see bolting a fallback regex mode for the few languages that have features which ts cannot (yet) accommodate.

And 'niche layered on niche' is -- well, it leaves me wondering how much you've actually used hx. The experience is nominal, the installation is sane, and it was way faster to get to 'genuinely pleasant' than nvim ever was.

As a plus, nix home-manager also handles helix config, which, as a nixos user, puts it over the top for me.

(home-manager also does nvim, but this is mostly mooted by my need for an elaborate (and turing-complete) Packer configuration, which has me using a separate git repo for nvim specifically)

Re: Vim 9.0

#99

Post by layer8 »

oblio wrote: post #83
azangru wrote: post #72

Earlier quoted context omitted.

Arrays start at 1?

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...

Re: Vim 9.0

#100

Post by moelf »

kbumsik wrote: post #95

> to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java. So...they make a new language to fix that? Couldn't they just use an existing language?

maybe... Lua? /s
Post reply on HN