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

EVi, a Hard-Fork of Vim

codeberg.org

Post reply on HN
Print view View original

51–60 of 67 posts

Re: EVi, a Hard-Fork of Vim

#51

Post by qalmakka »

latortuga wrote: post #27
qalmakka wrote: post #24

Honest question: why would anyone use Vim and not NeoVim nowadays? I've switched what, 12 years ago? And I've never had to look back. Just curious, to be honest. Especially since neovim is full of new features, while the Vim9 scripting language kind of tanked

I'll field this one as someone who has used regular ol' Vim for ~18 years and never switched. Why switch if your tool is working fine? I use vim literally every day all day long and it does everything I need it to do. Switching has a cost and there's no reason to pay it if it's working fine.

I originally switched because neovim was more polished, had better plugins and Lua config files. I then never had a reason to go back

Re: EVi, a Hard-Fork of Vim

#52

Post by bilekas »

fwip wrote: post #33
bilekas wrote: post #26

Earlier quoted context omitted.

So it's a fork based on principle ? I'm a slop hater as much as the next one but that really does seem petty.

Making a decision on principle is the opposite of petty, isn't it?

Yes, the location of the repo really doesn't mean much to me at all, complaining about it being hosted somewhere because of principle is certainly petty.

Re: EVi, a Hard-Fork of Vim

#53

Post by wat10000 »

freedomben wrote: post #41

The reason for the fork: > EVi is a hard fork from Vim v9.1.2073 (Jan 2026) to build further upon the foundations of Vim, while avoiding AI taint. I wish they would have included at least one example of the "taint" on vim. If it's "tainted" enough to justify a hard fork, then surely there's some evidence. Without that, it just rings like an ideological thing. Does anyone have some example(s) they can point to?

It is very much an ideological thing.

Re: EVi, a Hard-Fork of Vim

#54

Post by jmclnx »

johncoltrane wrote: post #50
jmclnx wrote: post #38

Very nice, will look into it myself. Now if only they can set the defaults back to what vim 6.x used I will be happy. The new defaults drive me crazy and I had to update ~/.vimrc to disable them. This is what I had to add, but once in great while a default will be reset which I have yet to figure out why that happens. :let no_man_maps=1 :let loaded_matchparen = 1 :set comments="" :set matchpairs="" :set mouse= :set n…

Assuming you already had a ~/.vimrc, the only non-defaults in that list are: :let no_man_maps=1 :let loaded_matchparen = 1 :set comments="" :set matchpairs="" :set paste All the other lines set options to their default value, which is pointless. The values for 'comments' and 'matchpairs' are incorrect, they should be: :set comments= :set matchpairs= Enabling 'paste' by default is a very bad idea, with lots of side-ef…

Thanks,I will have to revisit the settings. These are from the move to vim 7.0. 7.0 without these settings was a nightmare and if one was missing it would not work the way I wanted it to.

Re: EVi, a Hard-Fork of Vim

#55

Post by wat10000 »

lemonwaterlime wrote: post #48
wat10000 wrote: post #12

Earlier quoted context omitted.

It’s not about specific offending portions, it’s the principle of having any LLM contributions at all. There’s a group of people who are so opposed to this stuff that they object to its mere presence anywhere.

The issue with that stance, practically speaking, is that anyone could have hand-submitted generated code at any time, so why this January cutoff date? I would expect a decrease in code quality in a specific part of the repo or at least a quote/link to a changelog stating that generated code is being used as part of the fork making its case.

They're already talking about pushing it back farther, trying to revert/rewrite every commit from users suspected of ever using LLMs. Practicality doesn't really enter into it, this is an ideologically driven project that insists on getting rid of the "taint." https://codeberg.org/NerdNextDoor/evi/issues/19

Re: EVi, a Hard-Fork of Vim

#56

Post by GuestFAUniverse »

qalmakka wrote: post #24

Honest question: why would anyone use Vim and not NeoVim nowadays? I've switched what, 12 years ago? And I've never had to look back. Just curious, to be honest. Especially since neovim is full of new features, while the Vim9 scripting language kind of tanked

Have you ever called neovim inside a venv? Didn't work for me (or maybe I'm too lazy to jump hoops, if vim is working out of the box).

Re: EVi, a Hard-Fork of Vim

#57

Post by lemonwaterlime »

wat10000 wrote: post #55
lemonwaterlime wrote: post #48

Earlier quoted context omitted.

The issue with that stance, practically speaking, is that anyone could have hand-submitted generated code at any time, so why this January cutoff date? I would expect a decrease in code quality in a specific part of the repo or at least a quote/link to a changelog stating that generated code is being used as part of the fork making its case.

They're already talking about pushing it back farther, trying to revert/rewrite every commit from users suspected of ever using LLMs. Practicality doesn't really enter into it, this is an ideologically driven project that insists on getting rid of the "taint." https://codeberg.org/NerdNextDoor/evi/issues/19

I understand it is an ideological project. My point is that given their intent, there are things they should do to make their case. They should provide the evidence in the README etc.

If they are correct and things must be done, they aren’t providing the evidence. That’s not the same as saying there’s no evidence or reason to take this stance. Do you see the distinction I am making?

Re: EVi, a Hard-Fork of Vim

#58

Post by opan »

latortuga wrote: post #27
qalmakka wrote: post #24

Honest question: why would anyone use Vim and not NeoVim nowadays? I've switched what, 12 years ago? And I've never had to look back. Just curious, to be honest. Especially since neovim is full of new features, while the Vim9 scripting language kind of tanked

I'll field this one as someone who has used regular ol' Vim for ~18 years and never switched. Why switch if your tool is working fine? I use vim literally every day all day long and it does everything I need it to do. Switching has a cost and there's no reason to pay it if it's working fine.

I think I first switched because neovim supported the XDG config location, I could have ~/.config/nvim/init.vim instead of ~/.vimrc.

Re: EVi, a Hard-Fork of Vim

#59

Post by opan »

mmooss wrote: post #32
qalmakka wrote: post #24

Honest question: why would anyone use Vim and not NeoVim nowadays? I've switched what, 12 years ago? And I've never had to look back. Just curious, to be honest. Especially since neovim is full of new features, while the Vim9 scripting language kind of tanked

One reason might be how off-putting the Neovim community is, hijacking Vim discussions to denigrate an all-time-great, beloved work of technology and its creator (who did decades of work for free, gave it to the world, and gave any money to actual orphans) all for Neovim users'/devs' own egos, promotion, and obsession. Almost all of Neovim was made by Moolenaar, from concept to execution, and I don't know that I've e…

Can't say I really interact with the "community", I installed the program and I use it a lot. I am grateful for the existence of vi and vim. I now use neovim where I can. vim or vi as needed.

Re: EVi, a Hard-Fork of Vim

#60

Post by opan »

johncoltrane wrote: post #50
jmclnx wrote: post #38

Very nice, will look into it myself. Now if only they can set the defaults back to what vim 6.x used I will be happy. The new defaults drive me crazy and I had to update ~/.vimrc to disable them. This is what I had to add, but once in great while a default will be reset which I have yet to figure out why that happens. :let no_man_maps=1 :let loaded_matchparen = 1 :set comments="" :set matchpairs="" :set mouse= :set n…

Assuming you already had a ~/.vimrc, the only non-defaults in that list are: :let no_man_maps=1 :let loaded_matchparen = 1 :set comments="" :set matchpairs="" :set paste All the other lines set options to their default value, which is pointless. The values for 'comments' and 'matchpairs' are incorrect, they should be: :set comments= :set matchpairs= Enabling 'paste' by default is a very bad idea, with lots of side-ef…

>All the other lines set options to their default value, which is pointless.

I kinda like doing this for some programs, both as a way to see the current settings at a glance, and to avoid issues if defaults change in an update. At least twice mpv has changed default behavior and ruined my day. Once when they made scrolling vertically change volume instead of seeking (trying to match VLC?), and once when they disabled subtitles if the language matched the audio. Both easy to fix in the config file, both cases where I liked the default until they changed it.

Post reply on HN