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

101–110 of 272 posts

Re: Vim 9.0

#101

Post by moelf »

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…

IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes

Re: Vim 9.0

#102

Post by baobob »

hackerbrother wrote: post #92
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…

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…

Don't forget "set all&" to clear out hellish busted distro / local corp IT defaults

Re: Vim 9.0

#103

Post by Keyframe »

billti wrote: post #40
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…

Similar, but you can do most of those in one line! I also turn on line numbers and map "jk" to Escape in insert mode: set expandtab shiftwidth=4 softtabstop=4 tabstop=4 syntax on set number inoremap jk

Heh, jj for me and ji in visual mode since I might use jk there.

Re: Vim 9.0

#104

Post by omoikane »

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.

There is a Lua interface:

https://vimhelp.org/if_lua.txt.html#Lua

Re: Vim 9.0

#106

Post by mempko »

moelf wrote: post #101
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…

IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes

This is untrue. Tons of development is done by others.

Re: Vim 9.0

#107

Post by maxdamantus »

pbohun wrote: post #29
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…

Doesn't expandtab mess with creating/editing makefiles?

I really wish more systems would adopt the "copyindent" pattern, where indentation is simply copied from the existing line. I've primarily developed in vim for 15 years and have similarly minimal `vimrc`s (no plugins), but some of the first configurations are always:

  set autoindent
  set copyindent
  set preserveindent
This should be compatible with basically any language (other than some esolangs like "whitespace") and any tab/spaces scheme. There's no need to have per-file/project configuration, as long as you're okay with pressing space 4 times instead of tab in the projects that use 4-space indentation.

Re: Vim 9.0

#108

Post by margarina72 »

kzrdude wrote: post #85
deadbunny wrote: post #69

Earlier quoted context omitted.

And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.

We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.

open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible.

It is fully open source.

Open source does not mean the maintainer is under the obligation to add features, or integrate PRs.

[0]: https://opensource.org/osd

[1]: https://www.gnu.org/licenses/vim-license.txt

Re: Vim 9.0

#109

Post by mempko »

dvogel wrote: post #97
capableweb wrote: post #48

Earlier quoted context omitted.

> 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 proce…

Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.

Re: Vim 9.0

#110

Post by mempko »

Tyr42 wrote: post #47
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…

I mean all Bram had to do was accept the async patches instead of ignoring them. Then neovim wouldn't have got off the ground. Once they started building, they wanted to "cut the cruft" and just went from there

Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.
Post reply on HN