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

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

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

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

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