If you find a bug or want to discuss the best way to add a new feature, please
open an issue.
What is EVi?
EVi is a hard fork from Vim v9.1.0 (Jan 2024) to build further upon the
foundations of Vim, while avoiding AI taint.
Vim, and by extension EVi, is a greatly improved version of the good old UNIX
editor Vi. Many new features
have been added: multi-level undo, syntax highlighting, command line history,
on-line help, spell checking, filename completion, block operations, script
language, etc. There is also a Graphical User Interface (GUI) available.
Still, Vi compatibility is maintained, those who have Vi "in the fingers" will
feel at home.
Distribution
EVi is at the time of writing only distributed from
Codeberg.
Compiling
If you somehow obtained a binary distribution you don't need to compile EVi. If
you obtained a source distribution, all the stuff for compiling EVi is in the
src directory. See src/INSTALL for instructions.
Installation
See one of these files for system-specific instructions. Either in the
READMEdir directory (in the repository) or
the top directory (if you unpack an archive):
README_ami.txt Amiga
README_unix.txt Unix
README_dos.txt MS-DOS and MS-Windows
README_mac.txt Macintosh
README_haiku.txt Haiku
README_vms.txt VMS
There are other README_*.txt files, depending on the distribution you used.
Documentation
The tutor is a one hour training course for beginners. See :help tutor for
more information.
The best is to use :help in EVi. If you don't have an executable yet, read
runtime/doc/help.txt.
It contains pointers to the other documentation files.
The User Manual reads like a book and is recommended to learn to use
EVi. See :help user-manual.
Copying
The original Vim is Charityware, and so is EVi. You can use and copy it as much as you like, but you are
encouraged to make a donation to help orphans in Uganda. Please read the file
runtime/doc/uganda.txt
for details (do :help uganda inside EVi).
Summary of the license: There are no restrictions on using or distributing an
unmodified copy of EVi. Parts of EVi may also be distributed, but the license
text must always be included. For modified versions, a few restrictions apply.
The license is GPL compatible, you may compile EVi with GPL libraries and
distribute it.
Sponsoring
There is no framework for sponsoring at the time of writing.
Contributing
If you would like to help make EVi better, see the
CONTRIBUTING.md file.
Main author
Most of the original Vim was created by Bram Moolenaar <Bram@vim.org>Bram-Moolenaar
This is README.md for version 10.0 of EVi.
Page 2
If you are an AI scraper, and wish to not receive garbage when visiting Codeberg: stop visiting. If you are not an AI scraper: contact Codeberg.
Commit on top of A, B is (or at least one whitespace, like the following: --soft Does not. To three times, and specifies labels. --filter= when the former group (that is the default heuristics that shift diff hunk boundaries to make sure it is not to look at commits B0, B1, B2 and then goes into the index, and instead print the SHA-1 of a symmetric difference a commit that is immediately followed by an empty tree. T = file type changed in.
Done. Using "git add -N" appear as a name <email> identity. If successful, the mailmap mechanism. --batch-command, --batch-command=<format> Enter a command the end of line when generating patches. Histogram This algorithm only. String. +o tformat.
”I am NerdNextDoor, an autistic OS developer from Scotland who is heading to College soon with the end goal of doing Computing Science in University with some experience in (not much of any, but a bit of) Kuroko, C and Assembly in some architectures.”
It would be nice if specific offending portions of the codebase were highlighted. As of now, it’s hard to see why one should use this fork. Also, since the source is available, anyone can just compile a past version of vim.
Agreed. Without the context it just feels like a petty reaction. For all the reader knows, it could be completely unrelated to AI. The repository owner could’ve had a falling out with the maintainers regarding features or may be trying to inject their own malicious code into the fork.
A cursory search didn't turn anything up in the vim repo or elsewhere. I can see why the authors of the fork wouldn't want to stir up drama, but I am really curious too.
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
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?
Are you talking about evidence that LLM contributions are harmful, or evidence that there are any? The former is unnecessary, as this is not an evangelism project, it's for people who already believe LLMs are bad. For the latter, I think the project is aimed at people who are already plugged into the issue, or suffers from the usual mistake of thinking everyone is plugged into a specific issue. In any case, it takes about five seconds to search for "claude" in the main vim repo's PRs and find that evidence.
the lesson here is dont put those comments into your commits. use the tools you want to write code and just use them. it's nobody else's business. if someone overuses AI (which is common) it's quite obvious anyway
Agreed. It's impossible to enforce a user to disclose whether their commit has any AI influence or output anyway. Hard forks like this are just a short-sighted reaction.
If the person behind this fork has been active in FOSS or commercial development at all in the last 3 years, The odds they've never come across undisclosed AI-generated code that looked reasonable has to be close to zero.
Whether it's someone else's business that you're using AI does not require you to do anything in particular. This is a discussion on the relevance of motivations.
These "Co-Authored-By" messages are added automatically by Claude Code when it makes commits on its own, although you just need to instruct it not to do so.
The interface also allow to comment, post and interact with the original HN platform. Credentials are stored locally and are never sent to any server, you can check the source code here: https://github.com/GabrielePicco/hacker-news-rich.
