i didn't even know that Vim allowed plugins!

Does Vim support this? --- making up a command "on the fly" by
mapping some keystrokes onto a single KEY... i guess that's what [map] does.

10 essential Vim plugins
https://medium.com/@huntie/10-essential-vim-plugins-for-2018-39957190b7a9

https://old.reddit.com/r/vim/comments/ulphgp/what_are_your_musthave_vimnvim_extensions/

Which is one of the most used text editors?

The Top 11 Text Editors (January 18, 2024)

1. UltraEdit. UltraEdit is a versatile and powerful text editor known for handling complex and large files with ease. ...

2. BBEdit. ...

3. Visual Studio Code. ...

4. Sublime Text. ...

5. WebStorm. ...

6. Notepad++ ...

7. CoffeeCup HTML Editor. ...

8. TextMate.

9. Espresso

10. Bluefish

11. Vim ------------ Wow!

On Sat, 2 Mar 2024 18:44:15 +0000, HenHanna wrote:
> Does Vim support this? --- making up a command "on the fly" by
> mapping some keystrokes onto a single KEY... i guess that's what [map] does.
>

Always nice to see someone find an answer to their own question,
though it _is_ rather faster than usual to do it before finishing the
paragraph that contains the question!

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 02.03.2024 23:23, Stan Brown wrote:
> On Sat, 2 Mar 2024 18:44:15 +0000, HenHanna wrote:
>> Does Vim support this? --- making up a command "on the fly" by
>> mapping some keystrokes onto a single KEY... i guess that's what [map] does.
>>
>
> Always nice to see someone find an answer to their own question, [...]

Not too surprising given that he's got the hint in his previous thread.
;-)

Janis

On Sat, 2 Mar 2024 18:44:15 +0000, HenHanna wrote:

> i didn't even know that Vim allowed plugins!

That depends on the vim though, doesn’t it? There are multiple
incompatible versions; there’s even one that supports Lua as an extension
language.

Den 2024-03-03 skrev Lawrence D'Oliveiro <ldo@nz.invalid>:
> On Sat, 2 Mar 2024 18:44:15 +0000, HenHanna wrote:
>
>> i didn't even know that Vim allowed plugins!
>
> That depends on the vim though, doesn’t it? There are multiple
> incompatible versions; there’s even one that supports Lua as an extension
> language.

Vim is vim, isn't it? Vim has support for plugins in at least lua,
perl and python as far as I know. Are you thinking of different clones
of vi?

On Sun, 3 Mar 2024 20:23:51 -0000 (UTC), Andreas Kempe wrote:

> Are you thinking of different clones of vi?

Aren’t they all called “vim” nowadays?

On 04.03.2024 00:32, Lawrence D'Oliveiro wrote:
> On Sun, 3 Mar 2024 20:23:51 -0000 (UTC), Andreas Kempe wrote:
>
>> Are you thinking of different clones of vi?
>
> Aren’t they all called “vim” nowadays?

No. Why should vi clones be called "vim"?

Vim is one (outstanding) vi clone.

Janis

On Mon, 4 Mar 2024 08:12:33 +0100, Janis Papanagnou wrote:

> Why should vi clones be called "vim"?

All with “vim” somewhere in their names:

https://vi.stackexchange.com/questions/24459/can-you-use-neovim-in-a-gui-like-mvim-or-gvim-mac-os-x
https://www.reddit.com/r/vim/comments/dct9ry/what_is_the_difference_between_vim_gvim_and_neovim/?rdt=38898
https://news.ycombinator.com/item?id=27291799

On 04.03.2024 23:00, Lawrence D'Oliveiro wrote:
> On Mon, 4 Mar 2024 08:12:33 +0100, Janis Papanagnou wrote:
>
>> Why should vi clones be called "vim"?
>
> All with “vim” somewhere in their names:

Why this red herring now? - In response to Andreas' hint about *Vi*
you had said: "Aren’t they all called “vim” nowadays?"

In case you are interested in the typical taxonomy[*]...
It started with ex/vi, then there were Vi-clones (own implementations
or approximations or extensions of Vi), Vim as being a prominent one.
There's were/are lot of Vi clones (stevie, elvis, vile, nvi, and more).
There's a Vim branch neovim (that might or might not get relevance in
future now that Bram had died), I don't know of mvim, and gvim is just
graphical Vim.

It should be obvious to name any clone according to the functional base
or code base the clone is comparing with or is based on.

Janis

>
> https://vi.stackexchange.com/questions/24459/can-you-use-neovim-in-a-gui-like-mvim-or-gvim-mac-os-x
> https://www.reddit.com/r/vim/comments/dct9ry/what_is_the_difference_between_vim_gvim_and_neovim/?rdt=38898
> https://news.ycombinator.com/item?id=27291799
>

[*] "typical", because no one can prevent anyone to name a tool myvi
or myvim with or without any reference to vi and vim respectively.

On Tue, 5 Mar 2024 02:25:15 +0100, Janis Papanagnou wrote:

> Why this red herring now? - In response to Andreas' hint about *Vi* you
> had said: "Aren’t they all called “vim” nowadays?"

Nobody seems to use any editor called “vi” any more.

On 05.03.2024 04:22, Lawrence D'Oliveiro wrote:
>
> Nobody seems to use any editor called “vi” any more.

You again seem to know everyones habits? (I don't.)
But I'm sure this is true for the most (all?) free
Unixes at least.

Personally I edit my files with "vi" on my system.
Since I am using Linux this "vi" is of course Vim.

But I wouldn't expect that commercial Unixes come
with Vim. (Please CMIIW; I have meanwhile decades
to work on commercial Unixes and maybe things have
changed. Anyone who knows?)

Anyway, the taxonomy should be made clear; it's a
*big* difference if you have a yet still powerful
but (in comparison to Vim) restricted Vi as the
functional base of a clone, or whether you have a
Vim.

BTW, to my knowledge there had been Vi clones on
Windows, too. In a document I wrote some decades
ago I find (besides the ones I mentioned upthread)
also calvin, elwin, lemmy, viper - some (or all?)
may be or have been available on Windows or DOS?

Janis

On Tue, 5 Mar 2024 06:42:01 +0100, Janis Papanagnou wrote:

> Personally I edit my files with "vi" on my system. Since I am using
> Linux this "vi" is of course Vim.

Like this?

ldo@theon:~> ls -l /usr/bin/vi
lrwxrwxrwx 1 root root 20 May 5 2023 /usr/bin/vi -> /etc/alternatives/vi
ldo@theon:~> ls -l /etc/alternatives/vi
lrwxrwxrwx 1 root root 17 May 5 2023 /etc/alternatives/vi -> /usr/bin/vim.tiny

So even when you think you’re using “vi”, you’re still actually using
“vim”...

On 05.03.2024 08:10, Lawrence D'Oliveiro wrote:
> On Tue, 5 Mar 2024 06:42:01 +0100, Janis Papanagnou wrote:
>
>> Personally I edit my files with "vi" on my system. Since I am using
>> Linux this "vi" is of course Vim.
>
> Like this?
>
> ldo@theon:~> ls -l /usr/bin/vi
> lrwxrwxrwx 1 root root 20 May 5 2023 /usr/bin/vi -> /etc/alternatives/vi
> ldo@theon:~> ls -l /etc/alternatives/vi
> lrwxrwxrwx 1 root root 17 May 5 2023 /etc/alternatives/vi -> /usr/bin/vim.tiny
>
> So even when you think you’re using “vi”, you’re still actually using
> “vim”...

Yes, exactly. This is possible because Vim is in practice a superset
of Vi, and having a program that implements Vi functionality called
"vi" is defined as part of the POSIX utilities.

Only that I don't think that I'm using Vi, as I said, only that it's
called "vi". But others may think so. Mind that it's a reply to what
you said: >>> Nobody seems to use any editor called “vi” any more.

But again, this is Linux and the commercial world had been different.
On Linux you have full Vim functionality available when using "vi".

Janis

Just noticed...

On 05.03.2024 08:10, Lawrence D'Oliveiro wrote:
> lrwxrwxrwx 1 root root 17 May 5 2023 /etc/alternatives/vi -> /usr/bin/vim.tiny

On my system it is: /etc/alternatives/vi -> /usr/bin/vim.gnome
This may be important if I inspect the file sizes...

2392032 /usr/bin/vim.gnome
777056 /usr/bin/vim.tiny

Not sure what the difference is; some restricted functionality in
the .tiny version or maybe some graphical support in .gnome?

Janis

On 2024-03-04 22:22, Lawrence D'Oliveiro wrote:
> On Tue, 5 Mar 2024 02:25:15 +0100, Janis Papanagnou wrote:
>
>> Why this red herring now? - In response to Andreas' hint about *Vi* you
>> had said: "Aren’t they all called “vim” nowadays?"
>
> Nobody seems to use any editor called “vi” any more.

I personally use a POSIX and historically compatible vi(1). Nvi by Keith Bostic
is proof of concept and faithful reproduction of Billy Joy's original vi(1).
Nvi comes stock (along with ed(1)) on every BSD I use (FreeBSD, NetBSD, OpenBSD,
GhostBSD). One of the first things I do with a new Linux box is uninstall Vim
and install Nvi (and ed) from package or source. So yes, I use a proper vi.

--
Anthony C Howe
achowe@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/

Janis Papanagnou wrote:

> On 05.03.2024 04:22, Lawrence D'Oliveiro wrote:
>>
>> Nobody seems to use any editor called “vi” any more.

> Personally I edit my files with "vi" on my system.
> Since I am using Linux this "vi" is of course Vim.

I am using Linux and the "vi" on my system(s) is not vim, it is nvi.

$ readlink /usr/bin/vi
/etc/alternatives/vi
$ readlink /etc/alternatives/vi
/usr/bin/nvi

> But I wouldn't expect that commercial Unixes come
> with Vim. (Please CMIIW; I have meanwhile decades
> to work on commercial Unixes and maybe things have
> changed. Anyone who knows?)

MacOS has vim as its POSIX conforming vi (certified conforming to
UNIX 03).

Solaris 11.4 has vim in addition to a "real" (SVR4-derived) vi.
Which one you get if you type "vi" depends on your PATH:

$ readlink /usr/bin/vi
vim
$ type vi
vi is a tracked alias for /usr/xpg7/bin/vi
$ getconf PATH # standards-conforming PATH
/usr/xpg7/bin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/bin:....

--
Geoff Clare <netnews@gclare.org.uk>

On 07.03.2024 14:40, Geoff Clare wrote:
>
> I am using Linux and the "vi" on my system(s) is not vim, it is nvi.

As I understand it nvi is just a reimplementation of classical vi.
I assume your Linux also supports vim. Is there a reason why you
prefer to use nvi?

(I'm really curious since there's so many fundamental and useful
features supported in vim that I surely don't want to miss them.
Even at times when I used both, vi and vim, in parallel depending
on the actual platform I was working on it wouldn't have occurred
to me to stay with vi (for consistency, or so) on a platform where
vim was available.)

Janis

In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 07.03.2024 14:40, Geoff Clare wrote:
> > I am using Linux and the "vi" on my system(s) is not vim, it is nvi.
> As I understand it nvi is just a reimplementation of classical vi.
> I assume your Linux also supports vim. Is there a reason why you
> prefer to use nvi?

Some people find vim does too much. I find I need to carefully pare back
some default configurations in vim to make it "sane" for me. With
settings like "scrolloff" set, I find it actually interferes with my
editing most of the time. But there are rare cases when I do want want
that. The same holds for syntax highlighting.

> (I'm really curious since there's so many fundamental and useful
> features supported in vim that I surely don't want to miss them.
> Even at times when I used both, vi and vim, in parallel depending
> on the actual platform I was working on it wouldn't have occurred
> to me to stay with vi (for consistency, or so) on a platform where
> vim was available.)

The default vi on Slackware has been elvis probably since the first
version of that distro. People who have been using that since forever
likely find vim quirky.

The default vi on alpine is the one in busybox. The only good thing I
can say about it is it's small. In a pinch, it beats editing with shell
tools (like cat, head, tail, grep, echo, and dd) but it has a lot of
issues as a "vi" clone.

I turned to vim in the 2.x era because my editing style uncovered bugs
in the true vi I used on Solaris and HP-UX. I'm still using it now, but
the vim-isms I use are very slim compared to the vi original things I
use.

Elijah
------
the biggest bug was vi forgetting marks sometimes

On 2024-03-07 09:08, Janis Papanagnou wrote:
> On 07.03.2024 14:40, Geoff Clare wrote:
>>
>> I am using Linux and the "vi" on my system(s) is not vim, it is nvi.
>
> As I understand it nvi is just a reimplementation of classical vi.
> I assume your Linux also supports vim. Is there a reason why you
> prefer to use nvi?

* Nvi historically accurate for the most part. Keith Bostic worked on the
POSIX.2 drafts for vi. To that end they needed an independent version of vi as
a frame of reference for vendors. I was with MKS balloting POSIX.2 / XOpen and
maintaining conformance of their vi for DOS. Keith and I corresponded WRT vi
and Curses.

* Nvi's extensions do not conflict with historical/POSIX behaviour. In
particular undo/redo in vim is a pet peeve of mine, because it never works the
way I expect it to work and I have lots of muscle memory WRT vi. Keith's
solution was more elegant IMO.

* 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.

* 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).

* 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.

* 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.

--
Anthony C Howe
achowe@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/

Thanks for your post and insights.

I'd like to ask about some details that are not obvious to me...

On 07.03.2024 23:58, Eli the Bearded wrote:
> In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> As I understand it nvi is just a reimplementation of classical vi.
>> I assume your Linux also supports vim. Is there a reason why you
>> prefer to use nvi?
>
> Some people find vim does too much. I find I need to carefully pare back
> some default configurations in vim to make it "sane" for me. With
> settings like "scrolloff" set, I find it actually interferes with my
> editing most of the time. But there are rare cases when I do want want
> that. The same holds for syntax highlighting.

It's unclear to me what you mean by "too much". I'm aware that Vim
has a lot of new features but if I start it without changes I seem
to get a behavior like Vi; the only difference I recall is the 'u'
behavior to undo a single change (and toggle) in Vi, and to have
multiple undo-levels in Vim (that I certainly don't want to miss).

I can't say anything WRT the 'scrolloff' setting; its default value
is '0' on my system and that's how I recall Vi to behave. (I don't
recall that Vi had such an option in the first place, but my memory
on that setting detail is faint.)

>
>
>> (I'm really curious since there's so many fundamental and useful
>> features supported in vim that I surely don't want to miss them.
>> Even at times when I used both, vi and vim, in parallel depending
>> on the actual platform I was working on it wouldn't have occurred
>> to me to stay with vi (for consistency, or so) on a platform where
>> vim was available.)
>
> The default vi on Slackware has been elvis probably since the first
> version of that distro. People who have been using that since forever
> likely find vim quirky.

I recall to have used Elvis decades ago for only a short period of
time. Have you an example for the "quirky feeling"? (I am certainly
wondering about it; was it so different from _Vi_? And given that I
read in the Wikipedia that _Vim_ was influenced by it I'd expected
that even adopted non-Vi features would have similarities then.)

But okay, whenever one is used to a tool any differing behavior can
be a nuisance.

> [...]
>
> I turned to vim in the 2.x era because my editing style uncovered bugs
> in the true vi I used on Solaris and HP-UX. I'm still using it now, but
> the vim-isms I use are very slim compared to the vi original things I
> use.

Yes, this is understandable.

Myself I consider the basic power of the Vi concept/philosophy already
as the primary incentive to use Vi. One difference on my part is that
over time I had constantly used more and more features of Vim (and Vi).
Yet still only a fraction of what Vim provides.

Amongst the new (non-Vi) features that I _often_ use in Vim are...
- Using control keys (arrow keys, etc.) in Insert-mode[*]
- Using control keys for page navigation
- Visual mode commands (as an option in specific editing cases)
- Search history
- Ex command history
- Multiple undos/redos
- screen splitting
- syntax highlighting
- Forward keyword search[**]
- Navigation on wrapped lines (gj, gk)
- Extended word positioning (ge, gE)
- Internal formatting (gq)
- the more consistent 'z' commands (zt, zz, zb)
- a couple of useful ex commands[***] (:last, ...)

There's some more I only occasionally use, and I probably forgot some.

Janis

[*] That never worked with ordinary Vi for me.

[**] The original Vi I recall to have used long ago did only support
the backward keyword search '#'.

[**] I don't recall anymore what Vi provided (but I recall that the
list had been rather short), so I abstain from listing more examples.

On 08.03.2024 00:54, Anthony Howe wrote:
> On 2024-03-07 09:08, Janis Papanagnou wrote:
>> As I understand it nvi is just a reimplementation of classical vi.
>> I assume your Linux also supports vim. Is there a reason why you
>> prefer to use nvi?
>
> * Nvi historically accurate for the most part. [...]
>
> * Nvi's extensions do not conflict with historical/POSIX behaviour. In
> particular undo/redo in vim is a pet peeve of mine, because it never
> works the way I expect it to work and I have lots of muscle memory WRT
> vi. Keith's solution was more elegant IMO.

Hmm.., okay.

Myself I had always been annoyed by Vi's single undo toggling. Vim's
multiple undo (and redo) is exactly what I want.

I've read somewhere that Vim even allows to navigate undo trees, but
that's something I never looked into.

>
> * 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?

>
> * 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
certainly 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).

I also don't use Vim plugins.

>
> * 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.

>
> * 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.

Thanks for the insights and your preferences explained.

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 08.03.2024 00:54, Anthony Howe wrote:
>> On 2024-03-07 09:08, Janis Papanagnou wrote:
>>> As I understand it nvi is just a reimplementation of classical vi.
>>> I assume your Linux also supports vim. Is there a reason why you
>>> prefer to use nvi?
>>
>> * Nvi historically accurate for the most part. [...]
>>
>> * Nvi's extensions do not conflict with historical/POSIX behaviour. In
>> particular undo/redo in vim is a pet peeve of mine, because it never
>> works the way I expect it to work and I have lots of muscle memory WRT
>> vi. Keith's solution was more elegant IMO.
>
> Hmm.., okay.
>
> Myself I had always been annoyed by Vi's single undo toggling. Vim's
> multiple undo (and redo) is exactly what I want.
>
> I've read somewhere that Vim even allows to navigate undo trees, but
> that's something I never looked into.
>
>>
>> * 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?
>
>>
>> * 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
> certainly 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).
>
> I also don't use Vim plugins.
>
>>
>> * 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.
>
>>
>> * 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.
>
> Thanks for the insights and your preferences explained.
>
> Janis

Personally, as I use vim mostly for programming, the best feature is the
ability to compile from inside vim and then automatically go to the errors to
correct them.

G

On 2024-03-07 22:59, Janis Papanagnou wrote:
> Hmm.., 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`.

> I'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.

>> * 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.

>> * 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.

> certainly 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.

> I also don't use Vim plugins.
>
>>
>> * 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:).

>> * 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.

> Thanks 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
achowe@snert.com BarricadeMX & Milters
http://nanozen.snert.com/ http://software.snert.com/

Janis Papanagnou wrote:

> On 07.03.2024 14:40, Geoff Clare wrote:
>>
>> I am using Linux and the "vi" on my system(s) is not vim, it is nvi.
>
> As I understand it nvi is just a reimplementation of classical vi.

It adds some features too. Anthony has mentioned some of them.
I use split-screen editing of multiple files, unlimited undo, and
command-line editing a lot; the others not so much.

I'm not sure how command-line editing works in vim, but in nvi it's
wonderfully simple - after pressing : to get a command line, I just
press Esc and a small window opens at the bottom of the screen
containing the commands I've typed (with the cursor on the most
recent, at the bottom). I can use all the normal vi editing commands
in that window, except that Return executes the command on the current
line (and closes the window).

> I assume your Linux also supports vim. Is there a reason why you
> prefer to use nvi?

When I switched from Unixware 2 to Linux on my work PC around 1999/2000,
having been a vi user for 17 years, I evaluated the vi clones available
and was instantly at home in nvi, whereas vim felt quite alien (things
in my muscle memory didn't work the same, some of my macros didn't work,
etc.) These days I occasionally have to edit files on a system that
doesn't have nvi and vim still feels "wrong" somehow, even with
"set compatible" and "syn off".

--
Geoff Clare <netnews@gclare.org.uk>

In comp.editors, Anthony Howe <achowe@snert.com> wrote:
> * 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.

Your other comments seem fine, but I will have to challenge you on this.
I am very skilled at macros and have found no compatibility issues. My
macroset to play Conway's Game of Life in vi was written on Sun
workstation with the Solaris vi and it ships with vim as a macro
example. Still working. (I am told neovim breaks it, but I don't use
that fork.)

Elijah
------
tends to write macros on the fly rather than have premade ones now