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

181–190 of 272 posts

Re: Vim 9.0

#181

Post by mkh »

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…

I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.

FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.

That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.

Re: Vim 9.0

#182

Post by wirrbel »

j16sdiz wrote: post #163
anonydsfsfs wrote: post #140

Earlier quoted context omitted.

I just checked the repo[0], and it says Bram has authored 95% of all commits to Vim. To say "the community owns Vim" when they've done ~5% of the work reminds me of group projects in school where one person does all the work and everyone else claims credit. [0] https://github.com/vim/vim

for a long time vim do send patch over email, and the git history did not preserve the original author info

Understandable in SVN times, but lack of Attribution in git times

Re: Vim 9.0

#183

Post by BaculumMeumEst »

undoware wrote: post #98
BaculumMeumEst wrote: post #55

Earlier quoted context omitted.

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

I don't often code in python either, but it's a considerable red flag that one of the largest languages in the world has been completely broken for this long. It makes me not want to invest time building muscle memory for the editor. Sometimes I need to code in python, and when I do, I don't want a lot of inconsistencies and jank.

That's what I mean by niche layered on niche- the editor itself is a niche project that leverages another niche project (tree-sitter) to do indentation, and when contributions on either aren't up to par it kind of falls apart.

I have used the editor a decent amount and it's quite nice when it works. I don't even mind the lack of plugin extensibility because there's not really anything I needed that wasn't built in.

Re: Vim 9.0

#184

Post by davidatbu »

dromtrund wrote: post #179
davidatbu wrote: post #174

Earlier quoted context omitted.

I would be very interested in a write up of why you prefer VSCode, if you can spare the time!

I'm someone else, but I did the same thing 5 years ago. For me, the most productive environment for writing and reading code is an editor with rich language support. Text editing ergonomics and startup time are completely trivial aspects of the user experience compared to proper language support. Although vim is improving, its plugin system, configuration mechanisms and plugin ecosystem is an afterthought and require…

Thanks for the writeup! Others, please feel free to keep them coming!

Re: Vim 9.0

#185

Post by sodapopcan »

bluenose69 wrote: post #43
bayindirh wrote: post #12

Earlier quoted context omitted.

It is already present on the lower right by default. Why lose a column?

I like line numbers because when I'm editing code in a remote meeting, I or someone else can refer to lines by number. The current line is not the only one that matters. I use relative line numbers because I like doing e.g. 9k or whatever. Others on a remote call often refer to other parts of the code with "9 up" or "9 down" (since "9k" and "9j" sound too alike in a noisy call).

When I started pairing every day at work, I used to do:

  if $WORK_COMPUTER
    set number
  endif
But then I came to like line numbers and just have 'em on all the time now.

Re: Vim 9.0

#187

Post by TotempaaltJ »

mempko wrote: post #109
dvogel wrote: post #97

Earlier quoted context omitted.

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.

As above[0], these are different people than the author's of neovim

[0]https://news.ycombinator.com/item?id=31942444

Re: Vim 9.0

#188

Post by sodapopcan »

alex_smart wrote: post #37
bcrescimanno wrote: post #9

Earlier quoted context omitted.

This comment thread on the previous conversation has a lot of good replies: https://news.ycombinator.com/item?id=31908731 A few highlights: * "If it ain't broke, don't fix it" * People don't like Lua (or just simply prefer VimScript) * Divergence over time means that they are not still compatible.

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

I prefer vimscript when scripting vim.

Re: Vim 9.0

#190

Post by wirrbel »

dvogel wrote: post #127
layer8 wrote: post #93

Earlier quoted context omitted.

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

Last time I touched lua support on neovim it really was not as easy as i hoped as an api. As compared to let’s say eMacs lisp.
Post reply on HN