Rename Vim → Evi in much documentation #35

Hopefully this will be a start. I'm sure I missed a few and some errors may have snuck in.

Initially I tried making appropriate replacements in the foreign language text, but on reflection decided that was probably a bad idea given that I don't speak the languages in question.

I also excluded various OS-specific files for OSs I don't have (Windows), ones that aren't supported any more (DOS) and ones that probably aren't supported (Win32? Haiku?)

I renamed vimtutor to evitutor since it's just a script.

I wasn't able to run all of the tests due to lack of glibtool on macOS, but the ones up until that point passed, and since I only changed documentation hopefully I didn't break any. Apologies if I did.

Ref: #33

Wait wait wait, how did you readd our commits?

@NerdNextDoor wrote in NerdNextDoor/evi#35 (comment):

Wait wait wait, how did you readd our commits?

Probably he didn ́t squashed the commits, or something similar.

I don't remember if it is a setting we can control.
I would say that if the files touched are the same, we should be fine.

The only thing I see that we should check is why:
image

Is that rendering wrong only on github?
The idea I think should be to keep the text aligned, and based on centered between the two lines.

What do you think guys?

@dreamos82 wrote in NerdNextDoor/evi#35 (comment):

The only thing I see that we should check is why: image

Is that rendering wrong only on github? The idea I think should be to keep the text aligned, and based on centered between the two lines.

What do you think guys?

It seems the first line has tabs for indentation while the following 2 have spaces, so anyone looking at the file with tabstop=2 would see it all lined up

It should probably all be tabs like in the original.

@dreamos82 wrote in NerdNextDoor/evi#35 (comment):

Probably he didn ́t squashed the commits, or something similar.

Ideally I'd have rebased the first commit from my PR onto the latest commit from the main Evi repo, then implemented the second round of changes onto that and committed. Instead I just pulled in the commits from the main repo to make sure my changes were compatible with those.

When you merge, Git should just skip over the commits it has already seen, so the extra commits in the PR are harmless, just a bit messy because they clutter up the PR. I could redo the PR from scratch if necessary.

I'll take a look at the tabs vs spaces situation.

@meta wrote in NerdNextDoor/evi#35 (comment):

@dreamos82 wrote in #35 (comment):
I'll take a look at the tabs vs spaces situation.

The standard used in the titles in all the help files I've checked seems to be 2 tabs followed by 2 spaces at the start, then 1 tab and 2 spaces between the title and the author

While oddly specific, I'd say we keep that for consistency's sake

Hopefully that's the whitespace fixed. I made the "based on" be 2 tabs 4 spaces in, so it's 2 spaces indented from the "EVI REFERENCE MANUAL".

I think that looks good. Though there still are some files that are indented with spaces instead of following the original's format like gui_w32.txt and gui.txt (I know I'm sounding way too pedantic with this but mixed indents like that cause all sorts of inconsistencies where it renders one way on one person's config and a different way on another person's config)

OK, I did what I should have done in the first place, and wrote a quick Ruby script to scan through all the files and check for ones with the wrong whitespace in those lines, and I fixed those.

Did a quick scrool and it looks ok to me. @NerdNextDoor @Reiddragon are we ready to merge it?

looks good to me

Yup, should be fine.

Just only now realising that the extra commits have duplicated in our commit history. Git didn't skip over them. Weirdly enough however, only some.

image

@NerdNextDoor wrote in NerdNextDoor/evi#35 (comment):

Just only now realising that the extra commits have duplicated in our commit history. Git didn't skip over them. Weirdly enough however, only some.

It might help to look at git log --oneline --graph --decorate --all origin/master so you can see the tree-like structure of the merge history. Web forges like Codeberg typically don't show that in a commit list, but when several merges are happening, it helps explain cases like this. You'll see that the duplicated commits are on different history lines that eventually join up at the current master branch.

So, I think it's correct, just confusing. If you wanted to avoid this, you could enforce that PRs rebase onto master before merging.

MAybe we can squash the commits when merging? It can be selected as default option in the settings.

MAybe we can squash the commits when merging?

Squashing does a different thing - if the PR author makes multiple commits of their own, it will squash them down into one, but it doesn't affect the commits from other PRs, so it wouldn't prevent what we saw here.

(Squashing is a matter of convention/taste; I personally think PR authors should squash commits if they tend to do time-based or "cleanup" commits, so that the repo history is clearer, with each commit being a single intended change to behavior. If a repo forces squashing, I think it can do harm, because authors can no longer keep separate changes in separate commits, or are forced to do more trivial PRs.)

Enforcing rebasing fixes the issue because rebasing creates a linear history. It can make PRs more difficult, though, requiring authors to do the rebasing, or repo owners to go outside the system to rebase and push manually with git.