Post by Janis PapanagnouHmm.., okay.
Myself I had always been annoyed by Vi's single undo toggling. Vim's
multiple undo (and redo) is exactly what I want.
In Nvi multiple undo /redo is possible, it just extends historical behaviour in
a way that doesn't conflict :
u . . . u . Undo 4 back, redo 2 forward.
So the historical behaviour of `u` is maintained and the historical `.` (repeat)
is extended to apply to `u`.
Post by Janis PapanagnouI've read somewhere that Vim even allows to navigate undo trees, but
that's something I never looked into.
Never understood what an undo tree is vs a linear undo/redo would look like.
Linear undo history makes sense and just about every editor supports it.
Post by Janis PapanagnouPost by Anthony Howe* vi macros. At the time of the POSIX standards, people had macros they
relied on that needed to be portable. I had collected for MKS's testing
some interesting macro sets: vi solving a maze; Turing test; Towers Of
Hanoi, maybe others. vim broke these macros.
Oh, interesting and good to know. Have you any details what exactly
was the problem?
Ugh. That was like 1993. I'd have to compare the POSIX.2 D12 July 1992 (I
still have in print on a shelf) against SUS 2018 vi (which is pretty much
Keith's updated version based on his research and some of my feedback).
I would suspect that the behaviour of `d` and `p/P` behaviour when
cutting/pasting lines or character regions was the issue, since historical vi
cursor position varied depending on what and how text was cut/put and from
either from a named/unnamed/numbered buffers. Some of it seems inconsistent,
but then Bill Joy might have been `seeing the world differently` back then.
Reading the revised detailed description of vi is a little mind bending
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
Comparing the original maze macros vs the modified versions for Vim would
probably show up the differences. I've been trying to find the original
unmodified macros.
Post by Janis PapanagnouPost by Anthony Howe* Don't need plugins or syntax highlighting or what ever else vim adds
to the bloat. I worked without those features for years. For that
there are plenty of other editors to try that are not Vim (or Emacs).
I worked also colorless in the past for a long time; my stance was
that programs and data should be well structured and formatted and
legibly written so that syntax colors are not really necessary. I
Yep. I agree.
Post by Janis Papanagnoucertainly changed my habit and value that feature (and especially
in the implemented form using external syntax specification files
instead of builtin syntaxes, which contributes to non-bloat, IMO).
Syntax highlighting can be nice and on Windows I use TextPad (since 1996) which
has syntax highlighting. The visual cues like matching parens, braces, and
brackets is nice combined with the `%` find-matching. Syntax highlighting is a
little like using a car's back-up camera vs doing it the classic way of look
back and around in the mirrors; being able to reverse a car when the camera
breaks is useful skill.
Post by Janis PapanagnouI also don't use Vim plugins.
Post by Anthony Howe* Vi already had lots of options; Vim seemed to go off the deep end.
Too many knobs means you're forever tweaking more than getting the job
done.
Okay, but you don't have to use them. I certainly use only a dozen
of all the options I can set. But whenever I missed a feature I
look into the docs and find a new one that's there to support me.
The huge list of options can certainly be frightening, I'm sure.
vi has enough, I twiddle like 4 of them. Huge number of options is not a
uniquely vi issue. It plagues software in general and being able to satisfy
many tastes, which I had to come to terms with when developing BarricadeMX.
@ed1conf often boasts of how there is no configuration to using ed(1) (actually
only one configuration, the prompt, eg. ed -p:).
Post by Janis PapanagnouPost by Anthony Howe* Pretty sure Nvi is smaller (depending on build options) than a full
Vim install. Yes I still care about size, despite lots of memory and
disk with modern machines.
Yes, fair enough. That's certainly yet more an argument if you're
comparing Vi with Emacs whose executable was ever in the 8-10 MB
range where Vi, Vi-clones, and Vi-improvements were much smaller.
I think if you're going to clone an editor, you have to keep the historical
aspect of it, even if it is not perfect. Some extensions might be nice,
sometimes one goes a little overboard, kinda like how "NetHack" has everything
and the kitchen sink (it has sinks) in a rogue game.
At some point you might be safer to name it something uniquely different to
reflect the break from the original. This might be why the debate of vi vs vim
exists because vim claims to be something its really not, yet has enough
similarities to be confusing. The-vi-that-is-not-vi (tvitinvi) (hmm doesn't
roll off the tongue), not-exactly-vi (nevi) (better). I'm sure the `m` in `vim`
means something, but I just think of a bathroom cleaner though.
Post by Janis PapanagnouThanks for the insights and your preferences explained.
NP. Reasoned discussion is good (vs the flame wars of yore); present arguments,
let people make their own choice.
--
Anthony C Howe
***@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/