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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In comp.editors, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 07.03.2024 23:58, Eli the Bearded wrote:

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

The shipped plugins slow down startup time and sometimes in the name of friendliness do things I don't want. Automatic decompression of files
with a .gz suffix for example, which produces noisy error messages if a
file has a .gz suffix but isn't a gzip file. These sorts of things
matter to me because I'm more prone to have odd suffixes on files.

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

The vim online help is very detailed including differences from vi.

'scrolloff' 'so' number (default 0, set to 5 in |defaults.vim|)
global or local to window |global-local|
...
NOTE: This option is set to 0 when 'compatible' is set.

Among other things that makes my use of vi(m) special is frequent use,
mostly just as a file reader or edit without saving interactive viewer,
is using it on a lot of systems with no user config files leaving me
prone to compiled in / distro defaults. (Hence, say, my familiarity with busybox vi on Alpine.)

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

Delete (backspace) works differently. It has default settings that do
not redisplay the line as you delete. The -o commandline option is
hugely different in ways that can be destructive to files.

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

Vim worked hard to become more vi-compatible (albeit hidden behind
":set compatible") between versions 3 and 7.

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.

I like many features of vim that are not in vi, but I am good at
adapting to the features available and not overly reliant on the new.

Elijah
------
composed this reply in elvis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08.03.2024 11:30, G wrote:

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.

Please correct me if I am wrong but I seem to recall that I've done
that with Vi already in the 1990's (before I got my hands on a Vim).
(Faint memories suggest that there were three commands supporting
the edit, compile, fix cycle in Vi. Don't know whether Vim still use
these or whether it has extended them.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08.03.2024 14:28, Geoff Clare wrote:

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

In Vim you have that possibility as well and another simple one
in addition...

If you type ':' to enter an 'ex' command you just use the arrow
keys for navigation in the history; Arrow-Up will show you the
last command (and so on) and that way you navigate up and down in
the history. Then type either 'Enter' to re-execute it or use the Arrow-Left/-Right keys to navigate in one 'ex' command to change
it if desired. All that happens in the bottom "ex-line".

The other option works exactly like the one you described for Nvi.
You enter that second split window in command mode by 'q:', do your
vi moves and changes in that window, and type 'Enter' to execute it.
(Nvi's 'Esc' typing is not necessary here.)

BTW, these two options for the 'ex' commands are available also for
the search history. Type '/' to search and then use the Arrow-Keys
navigation as above. Or type 'q/' in command mode to get the split
window and operate on it like with the 'ex' commands window above.

It's consistent, intuitive, and very easy to use.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08.03.2024 12:48, Anthony Howe wrote:

On 2024-03-07 22:59, Janis Papanagnou wrote:

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.

I see.

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.

I associated that term with undos and new text repeatedly applied
so that a simple linear stack structure would not suffice to get
any intermediate change back.

But if one is so chaotic in writing and undoing text I wonder how
he would use that feature and still keeping his mind to navigate
such an undo tree. (Never needed it myself but maybe it's of use
to someone.)

* vi macros. [...]

Oh, interesting and good to know. Have you any details what exactly
was the problem?

Ugh. That was like 1993. [...]

Nevermind.

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.

Yep. I agree.

I want to add that the habit was likely also influenced by the
fact that we printed source code on paper in B/W, so there was
a strong incentive to not rely on colors.

[...] Huge number of options is not
a uniquely vi issue. It plagues software in general and being able to satisfy many tastes, [...]

I agree.

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.

You know the more recent roguelike variants (mostly also based
on Nethack)? - Nethack was still overseeable compared to some
of these. ;-)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 08.03.2024 11:30, G wrote:

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.

Please correct me if I am wrong but I seem to recall that I've done that
with Vi already in the 1990's (before I got my hands on a Vim). (Faint memories suggest that there were three commands supporting the edit,
compile, fix cycle in Vi. Don't know whether Vim still use these or whether it has extended them.)

I don't know, I discovered this after I started using vim so I never used it
in vi. I remember you could execute an external prog from vi (":!prog" maybe) so you could do that with "make", I suppose, but I never used makefiles.

G

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)