Re: [TUHS] screen editors

Re: [TUHS] screen editors

[Rudi Blom]

>Date: Tue, 07 Jan 2020 14:57:40 -0500.
>From: Doug McIlroy <>
>To: tuhs@tuhs.org, thomas.paulsen@firemail.de
>Subject: Re: [TUHS] screen editors
>Message-ID: <202001071957.007JveQu169574@coolidge.cs.dartmouth.edu>
>Content-Type: text/plain; charset=us-ascii

.. snip ..

>% wc -c /bin/vi bin/sam bin/samterm
>1706152 /bin/vi
> 112208 bin/sam
> 153624 bin/samterm
>These mumbers are from Red Hat Linux.
>The 6:1 discrepancy is understated because
>vi is stripped and the sam files are not.
>All are 64-bit, dynamically linked.

That's a real big vi in RHL. Looking at a few (commercial) unixes I get

SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
 - /usr/bin/vi: iAPX 386 executable
Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
 - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
sticky executable or object module stripped - version 3.13-14
HP-UX 11.31 748996 Aug 28 2009 /bin/vi
 -- /bin/vi: ELF-32 executable object file - IA64

Re: [TUHS] screen editors

[Chet Ramey]

On 1/8/20 4:46 AM, Rudi Blom wrote:

> That's a real big vi in RHL. 

It's vim.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Re: [TUHS] screen editors

[Nemo Nusquam]

On 01/08/20 04:46, Rudi Blom wrote:
> That's a real big vi in RHL. Looking at a few (commercial) unixes I get
> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
>   - /usr/bin/vi: iAPX 386 executable
> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
>   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
> sticky executable or object module stripped - version 3.13-14
> HP-UX 11.31 748996 Aug 28 2009 /bin/vi
>   -- /bin/vi: ELF-32 executable object file - IA64

Solaris 10 on Ultrasparc 239828
   /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1, 
dynamically linked, stripped

Any others?

N.

Re: [TUHS] screen editors

[Steffen Nurpmeso]

Chet Ramey wrote in <bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>:
 |On 1/8/20 4:46 AM, Rudi Blom wrote:
 |> That's a real big vi in RHL. 
 |
 |It's vim.

It is a tremendous effort of Bram Moolenaar and the vim
contributors to maintain this codebase that can be configured in
uncountable ways, just looking at the pre-configured feature sets
that exist lead to tiny, small, normal, big and huge.
As far as i know it has real support for languages of the world,
which is a different thing than being UTF-8 all through the
engine.  (But i think emacs is better here, i see one markable
emacs developer taking care on the Unicode list, regarding real
BiDi support, for example.)

With all my sympathy for pico at first and for long, then mg / ee
/ nano / jupp etc., and with my repeated tries to switch over to
vile, in the last two decades i always came back home to vim, for
the one thing or the other.  Two endless loops in all this time.
I only use the smallest thinkable subsets of features, though.
(Only lumberjack-style editing here, anyway.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] screen editors

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, 8 Jan 2020 at 10:20, Nemo Nusquam <cym224@gmail.com> wrote:

> On 01/08/20 04:46, Rudi Blom wrote:
> > That's a real big vi in RHL. Looking at a few (commercial) unixes I get
> > SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
> >   - /usr/bin/vi: iAPX 386 executable
> > Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
> >   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
> > sticky executable or object module stripped - version 3.13-14
> > HP-UX 11.31 748996 Aug 28 2009 /bin/vi
> >   -- /bin/vi: ELF-32 executable object file - IA64
>
> Solaris 10 on Ultrasparc 239828
>    /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1,
> dynamically linked, stripped
>
> Any others?
>

I was somewhat surprised by this, on IRIX 4.0.5H:
/usr/bin/vi:    symbolic link to ex
-rwxr-xr-t 1 root sys 229376 2016-04-17 01:07 /usr/bin/ex
/usr/bin/ex:    mipseb demand paged stripped - version 2.10
% what /usr/bin/ex
/usr/bin/ex:
         printf.c:2.2 6/5/79

-Henry

[-- Attachment #2: Type: text/html, Size: 1443 bytes --]

Re: [TUHS] screen editors

[Steve Mynott]

On 08/01/2020, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> It is a tremendous effort of Bram Moolenaar and the vim
> contributors to maintain this codebase that can be configured in
> uncountable ways, just looking at the pre-configured feature sets
> that exist lead to tiny, small, normal, big and huge.

Indeed. It's larger because it does a lot more!

Small isn't necessarily beautiful and all those tiny old vendor vi
binaries are probably full of bugs since they were never actively
maintained.

The last time I used Solaris vi it didn't handle long lines properly
and the more recent classic Joy vi open source forks are full of bug
fixes (often for quite serious problems).

If you want a tiny vi compile one of those up or use nvi.  If you want
features use vim.

-- 
Steve Mynott <steve.mynott@gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

Re: [TUHS] screen editors

[Steffen Nurpmeso]

U'll Be King of the Stars wrote in <68b3d6df-94f6-625d-39bf-6149b4c177c9\
@andrewnesbit.org>:
 |On 08/01/2020 15:15, Steffen Nurpmeso wrote:
 |> (But i think emacs is better here, i see one markable
 |> emacs developer taking care on the Unicode list, regarding real
 |> BiDi support, for example.)
 |
 |I have been following the emacs-devel mailing list out of interest for 
 |many years.  From this, I think the person you are referring to in your 
 |comment, is Eli Zaretskii.  Is that right?

Yep.  Then again i have to say it was a lot of a mistake, because
the OSS man who i referred to and who is known for questions deep
in the material is indeed Karl Williamson of i think Perl.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] screen editors

[Dave Horsfall]

On Wed, 8 Jan 2020, Chet Ramey wrote:

>> That's a real big vi in RHL. 
>
> It's vim.

It's also VIM on the Mac.

-- Dave

Re: [TUHS] screen editors

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 8 Jan 2020, Chet Ramey wrote:
>
> >> That's a real big vi in RHL.
> >
> > It's vim.
>
> It's also VIM on the Mac.
>

Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
default for vi.

Warner

>

[-- Attachment #2: Type: text/html, Size: 884 bytes --]

Re: [TUHS] screen editors

[Larry McVoy]

On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote:
> 
> > On Wed, 8 Jan 2020, Chet Ramey wrote:
> >
> > >> That's a real big vi in RHL.
> > >
> > > It's vim.
> >
> > It's also VIM on the Mac.
> >
> 
> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
> default for vi.

I was gonna stay out of this thread (it has the feel of old folks somehow)
but 2 comments:

Keith did nvi (I can't remember why?  licensing or something) and he did
a pretty faithful bug for bug compatible job.  I've always wondered why.
I like Keith but it seemed like a waste.  There were other people taking
vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap
the file and had a whole string library that treated \n like NULL) and
I think vim was coming along.  So doing a compat vi felt like a step
backward for me.

For all the vim haters, come on.  Vim is awesome, it gave me the one
thing that I wanted from emacs, multiple windows.  I use that all the
time.  It's got piles of stuff that I don't use, probably should, but
it is every bit as good of a vi as the original and then it added more.
I'm super grateful that vim came along.

Re: [TUHS] screen editors

[Bakul Shah]

On Jan 8, 2020, at 5:28 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
>> On Wed, Jan 8, 2020, 4:22 PM Dave Horsfall <dave@horsfall.org> wrote:
>> 
>>> On Wed, 8 Jan 2020, Chet Ramey wrote:
>>> 
>>>>> That's a real big vi in RHL.
>>>> 
>>>> It's vim.
>>> 
>>> It's also VIM on the Mac.
>>> 
>> 
>> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
>> default for vi.
> 
> I was gonna stay out of this thread (it has the feel of old folks somehow)
> but 2 comments:
> 
> Keith did nvi (I can't remember why?  licensing or something) and he did
> a pretty faithful bug for bug compatible job.  I've always wondered why.
> I like Keith but it seemed like a waste.  There were other people taking
> vi forward, elvis, xvi (I hacked the crap out of that one, made it mmap
> the file and had a whole string library that treated \n like NULL) and
> I think vim was coming along.  So doing a compat vi felt like a step
> backward for me.
> 
> For all the vim haters, come on.  Vim is awesome, it gave me the one
> thing that I wanted from emacs, multiple windows.  I use that all the
> time.  It's got piles of stuff that I don't use, probably should, but
> it is every bit as good of a vi as the original and then it added more.
> I'm super grateful that vim came along.

The first thing I do on a new machine is to install nvi. Very grateful to
Keith Bostic for implementing it. I do use multiple windows — only
horizontal splits but that is good enough for me as all my terminal
windows are 80 chars wide. Not a vim hater but never saw the need.

Re: [TUHS] screen editors

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:

> The first thing I do on a new machine is to install nvi. Very grateful to
> Keith Bostic for implementing it. I do use multiple windows — only
> horizontal splits but that is good enough for me as all my terminal
> windows are 80 chars wide. Not a vim hater but never saw the need.

I pretty much do the same thing. I think what I hate about vim is that it's
almost, vi but not the same. My fingers screw up when I use it.  For
instance, he 'fixed' undo.   I guess I learned my lesson from my time at
UCB.  Henry Spencer once said, "BSD 4.2 is just like UNIX, only different."  I
rather see something new and completely different than changing behavior
that people rely upon.

[-- Attachment #2: Type: text/html, Size: 1432 bytes --]

Re: [TUHS] screen editors

[Larry McVoy]

On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
> 
> > The first thing I do on a new machine is to install nvi. Very grateful to
> > Keith Bostic for implementing it. I do use multiple windows ??? only
> > horizontal splits but that is good enough for me as all my terminal
> > windows are 80 chars wide. Not a vim hater but never saw the need.
> 
> I pretty much do the same thing. I think what I hate about vim is that it's
> almost, vi but not the same. My fingers screw up when I use it.  For
> instance, he 'fixed' undo.   

Holy crap Clem, you need to embrace that.  His undo goes back forever.
And you can undo the undo and go forward forever.  

Not liking that puts you in the "get off my lawn" old guy camp.  Which
is fine if that's who you want to be (sometimes I'm that guy).

Re: [TUHS] screen editors

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

make a new command, don't break the old one....  maybe offer a way to map
the new one over the old -- but don't make it the default.
and my lawn was lush and green before the snow came ;-)



On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
> >
> > > The first thing I do on a new machine is to install nvi. Very grateful
> to
> > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > horizontal splits but that is good enough for me as all my terminal
> > > windows are 80 chars wide. Not a vim hater but never saw the need.
> >
> > I pretty much do the same thing. I think what I hate about vim is that
> it's
> > almost, vi but not the same. My fingers screw up when I use it.  For
> > instance, he 'fixed' undo.
>
> Holy crap Clem, you need to embrace that.  His undo goes back forever.
> And you can undo the undo and go forward forever.
>
> Not liking that puts you in the "get off my lawn" old guy camp.  Which
> is fine if that's who you want to be (sometimes I'm that guy).
>

[-- Attachment #2: Type: text/html, Size: 1962 bytes --]

Re: [TUHS] screen editors

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On Wednesday,  8 January 2020 at 17:28:30 -0800, Larry McVoy wrote:
> On Wed, Jan 08, 2020 at 05:08:59PM -0700, Warner Losh wrote:
>> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD
>> default for vi.
>
> I was gonna stay out of this thread (it has the feel of old folks somehow)
> but 2 comments:
>
> Keith did nvi (I can't remember why?  licensing or something)

My vague recollection is that Rob Kolstad paid him to do it for
BSD/386.  As you say, licensing, and that BSD/386 *really* needed a vi
editor.

Does anybody know where Rob is?

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] screen editors

[Chet Ramey]

[-- Attachment #1.1: Type: text/plain, Size: 473 bytes --]

On 1/8/20 9:14 PM, Greg 'groggy' Lehey wrote:

> My vague recollection is that Rob Kolstad paid him to do it for
> BSD/386.  As you say, licensing, and that BSD/386 *really* needed a vi
> editor.
> 
> Does anybody know where Rob is?

Colorado Springs, according to Twitter.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: [TUHS] screen editors

[Bakul Shah]

Early in vim’s life I had emailed Moolenaar asking him if he would be
willing to add an option for nvi like behavior for undo/redo. He wasn’t
interested so I lost interest. nvi’s u & . behavior is not only quite clever
but also  much more intuitive and you don’t have to press the ctl key!

> On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)
> 
> 
> 
> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
> > 
> > > The first thing I do on a new machine is to install nvi. Very grateful to
> > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > horizontal splits but that is good enough for me as all my terminal
> > > windows are 80 chars wide. Not a vim hater but never saw the need.
> > 
> > I pretty much do the same thing. I think what I hate about vim is that it's
> > almost, vi but not the same. My fingers screw up when I use it.  For
> > instance, he 'fixed' undo.   
> 
> Holy crap Clem, you need to embrace that.  His undo goes back forever.
> And you can undo the undo and go forward forever.  
> 
> Not liking that puts you in the "get off my lawn" old guy camp.  Which
> is fine if that's who you want to be (sometimes I'm that guy).

Re: [TUHS] screen editors

[Larry McVoy]

I feel like there is an option to get nvi behaviour now but I dunno
why you want that.  Are you seriously advocating for less?  Because
objectively vim gives you more.

And it is faithful to vi, it has all the buffers so you can put stuff
back that way.

Maybe I'm clueless or I drank the koolaid, but I love vim.  It's vi
but better.

On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote:
> Early in vim???s life I had emailed Moolenaar asking him if he would be
> willing to add an option for nvi like behavior for undo/redo. He wasn???t
> interested so I lost interest. nvi???s u & . behavior is not only quite clever
> but also  much more intuitive and you don???t have to press the ctl key!
> 
> > On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote:
> > 
> > make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
> > and my lawn was lush and green before the snow came ;-)
> > 
> > 
> > 
> > On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
> > On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> > > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
> > > 
> > > > The first thing I do on a new machine is to install nvi. Very grateful to
> > > > Keith Bostic for implementing it. I do use multiple windows ??? only
> > > > horizontal splits but that is good enough for me as all my terminal
> > > > windows are 80 chars wide. Not a vim hater but never saw the need.
> > > 
> > > I pretty much do the same thing. I think what I hate about vim is that it's
> > > almost, vi but not the same. My fingers screw up when I use it.  For
> > > instance, he 'fixed' undo.   
> > 
> > Holy crap Clem, you need to embrace that.  His undo goes back forever.
> > And you can undo the undo and go forward forever.  
> > 
> > Not liking that puts you in the "get off my lawn" old guy camp.  Which
> > is fine if that's who you want to be (sometimes I'm that guy).

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] screen editors

[Mary Ann Horton]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

vim has an option to undo the vi way. "set cpoptions=u". There is a full 
set of vi-compatible options if you want them. "set cp" turns on full vi 
compatiblity.

Funny, I see vim as the vi that comes with UNIX, and never learned the 
enhancements, but I just tried it out and I don't have the compatibility 
option set. I don't seem to have noticed. I guess I don't do the "undo 
toggle" all that often.

     Mary Ann

On 1/8/20 6:12 PM, Clem Cole wrote:
> make a new command, don't break the old one....  maybe offer a way to 
> map the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)
>
>
>
> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com 
> <mailto:lm@mcvoy.com>> wrote:
>
>     On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>     > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com
>     <mailto:bakul@bitblocks.com>> wrote:
>     >
>     > > The first thing I do on a new machine is to install nvi. Very
>     grateful to
>     > > Keith Bostic for implementing it. I do use multiple windows
>     ??? only
>     > > horizontal splits but that is good enough for me as all my
>     terminal
>     > > windows are 80 chars wide. Not a vim hater but never saw the need.
>     >
>     > I pretty much do the same thing. I think what I hate about vim
>     is that it's
>     > almost, vi but not the same. My fingers screw up when I use it.  For
>     > instance, he 'fixed' undo.
>
>     Holy crap Clem, you need to embrace that.  His undo goes back forever.
>     And you can undo the undo and go forward forever.
>
>     Not liking that puts you in the "get off my lawn" old guy camp.  Which
>     is fine if that's who you want to be (sometimes I'm that guy).
>

[-- Attachment #2: Type: text/html, Size: 3388 bytes --]

Re: [TUHS] screen editors

[Larry McVoy]

+1

On Wed, Jan 08, 2020 at 07:27:13PM -0800, Mary Ann Horton wrote:
> vim has an option to undo the vi way. "set cpoptions=u". There is a full set
> of vi-compatible options if you want them. "set cp" turns on full vi
> compatiblity.
> 
> Funny, I see vim as the vi that comes with UNIX, and never learned the
> enhancements, but I just tried it out and I don't have the compatibility
> option set. I don't seem to have noticed. I guess I don't do the "undo
> toggle" all that often.
> 
> ?????? Mary Ann
> 
> On 1/8/20 6:12 PM, Clem Cole wrote:
> >make a new command, don't break the old one....?? maybe offer a way to map
> >the new one over the old -- but don't make it the default.
> >and my lawn was lush and green before the snow came ;-)
> >
> >
> >
> >On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com
> ><mailto:lm@mcvoy.com>> wrote:
> >
> >    On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
> >    > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com
> >    <mailto:bakul@bitblocks.com>> wrote:
> >    >
> >    > > The first thing I do on a new machine is to install nvi. Very
> >    grateful to
> >    > > Keith Bostic for implementing it. I do use multiple windows
> >    ??? only
> >    > > horizontal splits but that is good enough for me as all my
> >    terminal
> >    > > windows are 80 chars wide. Not a vim hater but never saw the need.
> >    >
> >    > I pretty much do the same thing. I think what I hate about vim
> >    is that it's
> >    > almost, vi but not the same. My fingers screw up when I use it.?? For
> >    > instance, he 'fixed' undo.
> >
> >    Holy crap Clem, you need to embrace that.?? His undo goes back forever.
> >    And you can undo the undo and go forward forever.
> >
> >    Not liking that puts you in the "get off my lawn" old guy camp.?? Which
> >    is fine if that's who you want to be (sometimes I'm that guy).
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] screen editors

[Bakul Shah]

If this option was added back then (992-94) I might have switched
over. I think I was tempted as it was “programmable”. But as it didn’t
have any other new features that I really wanted plus I was always
messing up undo/redo, probably like Clem, there was not much
point in switching. As it happens, I didn’t use the programmability
feature even when it was added to nvi!

No point in advocating as anyone who is used to the “more” of vim
would be frustrated with nvi!

> On Jan 8, 2020, at 7:08 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> I feel like there is an option to get nvi behaviour now but I dunno
> why you want that.  Are you seriously advocating for less?  Because
> objectively vim gives you more.
> 
> And it is faithful to vi, it has all the buffers so you can put stuff
> back that way.
> 
> Maybe I'm clueless or I drank the koolaid, but I love vim.  It's vi
> but better.
> 
> On Wed, Jan 08, 2020 at 06:59:02PM -0800, Bakul Shah wrote:
>> Early in vim???s life I had emailed Moolenaar asking him if he would be
>> willing to add an option for nvi like behavior for undo/redo. He wasn???t
>> interested so I lost interest. nvi???s u & . behavior is not only quite clever
>> but also  much more intuitive and you don???t have to press the ctl key!
>> 
>>> On Jan 8, 2020, at 6:12 PM, Clem Cole <clemc@ccc.com> wrote:
>>> 
>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>> and my lawn was lush and green before the snow came ;-)
>>> 
>>> 
>>> 
>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>> 
>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>> 
>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>> instance, he 'fixed' undo.   
>>> 
>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>> And you can undo the undo and go forward forever.  
>>> 
>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>> is fine if that's who you want to be (sometimes I'm that guy).
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] screen editors

[Bakul Shah]

It doesn’t work the same way. I just tried it (vim-8.0.something).
The way it is supposed to work is this:  the first u undoes the last change.
Then you keep hitting . to keep undoing more. Then if you went back too far,
you hit u again, to undo the undo and further . will keep redoing. You can
go back and forth this way as many times as you wish.

> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote:
> 
> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
> 
>     Mary Ann
> On 1/8/20 6:12 PM, Clem Cole wrote:
>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>> and my lawn was lush and green before the snow came ;-)
>> 
>> 
>> 
>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>> > On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
>> > 
>> > > The first thing I do on a new machine is to install nvi. Very grateful to
>> > > Keith Bostic for implementing it. I do use multiple windows ??? only
>> > > horizontal splits but that is good enough for me as all my terminal
>> > > windows are 80 chars wide. Not a vim hater but never saw the need.
>> > 
>> > I pretty much do the same thing. I think what I hate about vim is that it's
>> > almost, vi but not the same. My fingers screw up when I use it.  For
>> > instance, he 'fixed' undo.   
>> 
>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>> And you can undo the undo and go forward forever.  
>> 
>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>> is fine if that's who you want to be (sometimes I'm that guy).

Re: [TUHS] screen editors

[Mary Ann Horton]

Are you referring to the special case where an undo of "p" (put) will 
sucessively re-insert the most recent things you've deleted?

I just tried that in vim and it didn't seem to support the special case 
the way vi did.

     Mary Ann

On 1/8/20 7:49 PM, Bakul Shah wrote:
> It doesn’t work the same way. I just tried it (vim-8.0.something).
> The way it is supposed to work is this:  the first u undoes the last change.
> Then you keep hitting . to keep undoing more. Then if you went back too far,
> you hit u again, to undo the undo and further . will keep redoing. You can
> go back and forth this way as many times as you wish.
>
>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote:
>>
>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
>>
>>      Mary Ann
>> On 1/8/20 6:12 PM, Clem Cole wrote:
>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>> and my lawn was lush and green before the snow came ;-)
>>>
>>>
>>>
>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>>
>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>> instance, he 'fixed' undo.
>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>> And you can undo the undo and go forward forever.
>>>
>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>> is fine if that's who you want to be (sometimes I'm that guy).

Re: [TUHS] screen editors

[Jon Steinhart]

Clem Cole writes:
>
> make a new command, don't break the old one....  maybe offer a way to map
> the new one over the old -- but don't make it the default.
> and my lawn was lush and green before the snow came ;-)

Clem, this seems like an unusual position for you to take.  vim is backwards
compatible with vi (and also ed), so it added to an existing ecosystem.

Jon

Re: [TUHS] screen editors

[Bakul Shah]

Short answer: there is no special case in nvi.
P or p put back the contents of the last delete.
u undoes whatever was the last change (including the last undo or redo).
. repeats whatever was the last modifying command.

A detailed answer would merely confuse you. At least my attempt at it!
Suggest you try out various combinations in nvi and compare with vim.

> On Jan 8, 2020, at 7:55 PM, Mary Ann Horton <mah@mhorton.net> wrote:
> 
> Are you referring to the special case where an undo of "p" (put) will sucessively re-insert the most recent things you've deleted?
> 
> I just tried that in vim and it didn't seem to support the special case the way vi did.
> 
>     Mary Ann
> 
> On 1/8/20 7:49 PM, Bakul Shah wrote:
>> It doesn’t work the same way. I just tried it (vim-8.0.something).
>> The way it is supposed to work is this:  the first u undoes the last change.
>> Then you keep hitting . to keep undoing more. Then if you went back too far,
>> you hit u again, to undo the undo and further . will keep redoing. You can
>> go back and forth this way as many times as you wish.
>> 
>>> On Jan 8, 2020, at 7:27 PM, Mary Ann Horton <mah@mhorton.net> wrote:
>>> 
>>> vim has an option to undo the vi way. "set cpoptions=u". There is a full set of vi-compatible options if you want them. "set cp" turns on full vi compatiblity.
>>> Funny, I see vim as the vi that comes with UNIX, and never learned the enhancements, but I just tried it out and I don't have the compatibility option set. I don't seem to have noticed. I guess I don't do the "undo toggle" all that often.
>>> 
>>>     Mary Ann
>>> On 1/8/20 6:12 PM, Clem Cole wrote:
>>>> make a new command, don't break the old one....  maybe offer a way to map the new one over the old -- but don't make it the default.
>>>> and my lawn was lush and green before the snow came ;-)
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jan 8, 2020 at 9:07 PM Larry McVoy <lm@mcvoy.com> wrote:
>>>> On Wed, Jan 08, 2020 at 09:04:46PM -0500, Clem Cole wrote:
>>>>> On Wed, Jan 8, 2020 at 8:41 PM Bakul Shah <bakul@bitblocks.com> wrote:
>>>>> 
>>>>>> The first thing I do on a new machine is to install nvi. Very grateful to
>>>>>> Keith Bostic for implementing it. I do use multiple windows ??? only
>>>>>> horizontal splits but that is good enough for me as all my terminal
>>>>>> windows are 80 chars wide. Not a vim hater but never saw the need.
>>>>> I pretty much do the same thing. I think what I hate about vim is that it's
>>>>> almost, vi but not the same. My fingers screw up when I use it.  For
>>>>> instance, he 'fixed' undo.
>>>> Holy crap Clem, you need to embrace that.  His undo goes back forever.
>>>> And you can undo the undo and go forward forever.
>>>> 
>>>> Not liking that puts you in the "get off my lawn" old guy camp.  Which
>>>> is fine if that's who you want to be (sometimes I'm that guy).

Re: [TUHS] screen editors

[Thomas Paulsen]

> Nvi is also interesting and 1/10th the size of vim. It's also the FreeBSD default for vi.


check out elvis https://github.com/mbert/elvis 
vi + syntax highlighting + clean help subsystem = ~ 25% of size of vim 

Re: [TUHS] screen editors

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 7167 bytes --]

Answering, but  CCing COFF if folks want to continue.  This is less about
UNIX and more about how we all got to where we are.

On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon@fourwinds.com> wrote:

> Clem, this seems like an unusual position for you to take.  vim is
> backwards
> compatible with vi (and also ed), so it added to an existing ecosystem.
>
No, really unusually when you think about it.  vim is backward compatible
except when it's not (as Bakul points out) - which is my complaint.  It's
*almost* compatible and those small differences are really annoying when
you expect one thing and get something else (*i.e.* the least astonishment
principle).

The key point here is for *some people*, those few differences are not an
issue and are not astonished by them.  But for *some of the rest of us*
(probably people like me that have used the program since PDP-11 days) that
only really care about the original parts, the new stuff is of little value
and so the small differences are astonishing.  Which comes back to the
question of good and best.   It all depends on one what you value/where you
put the high order bit.  I'm not willing to "pay" for the it; as it gives
me little value.

Doug started this thread with his observation that ex/vi was huge compared
to other editors. * i.e.* value: small simple easy to understand (Rob's old
"*cat -v considered harmful*" argument if you will).  The BSD argument had
always been: "the new stuff is handy." The emacs crew tends to take a
similar stand.  I probably don't go quite as far as Rob, but I certainly
lean in that direction.  I generally would rather something small and new
that solves a different (set of) problem(s), then adding yet another wart
on to an older program, *particularly when you change the base
functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial
credit' does not cut it].

To me, another good example is 'more', 'less' and 'pg'.  Eric Schienbrood
wrote the original more(ucb) to try to duplicate the ITS functionality (he
wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and
4.1BSD was a few years in the future - so small an simple of a huge
value).  It went out in the BSD tapes, people loved it and were happy.  It
solved a problem as we had it.  Life was good.  Frankly, other than NIH,
I'm not sure why the folks at AT&T decided to create pg a few years later
since more was already in the wild, but at least it was a different program
(Mary Ann's story of vi *vs*. se if probably in the same vein).   But
because of that behavior, if someone like me came to an AT&T based system
with only pg installed, so those of us that liked/were used to more(ucb)
could install it and life was good.   Note pg was/is different in
functionality, it's similar, but not finger compatible.

But other folks seem to have thought neither was 'good enough' -- thus
later less(gnu) was created adding a ton of new functionality to Eric's
program.  The facts are clear, some (ney many) people >>love<< that new
functionality, like going backward.  I >>personally<< rarely care/need for
it, Eric's program was (is) good enough for me.   Like Doug's observation
of ed *vs.* ex/vi; less is huge compared to the original more (or pg for
that matter).   But if you value the new features, I suspect you might
think that's not an issue.  Thanks to Moore's law, the size in this case
probably does not matter too much (other than introducing new bugs).    At
least, when folks wrote did Gnu's less, the basic more(ucb) behavior was
left along and if you set PAGER=more less(gnu) pretty much works as I
expect it too.  So I now don't bring Eric's program with me, the same way
Bakul describes installing nvi on new systems (an activiity I also do).

Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do
>>occaisonally<< use split screens, but frankly, I can get most of the same
from having a window manager, different iterm2 windows and cut/paste.   So
even that extension to nvi, is of limited value to me.  vim just keeps
adding more and more cruft and its even bigger.   I personally don't care
for the new functionality, and the size of it all is worrisome.  What am I
buying?  That said, if the new features do not hurt me, then I don't really
care.  I might even use some of the new functionality - hey I run mac OS
not v7 or BSD 4.x for my day to day work and I do use the mac window
manager, the browser *et al*, but as I type this message I have 6 other
iterm2 windows open with work I am doing in other areas.

Let me take a look at this issue in a different way.   I have long been a
'car guy' and like many of those times in my youth spent time and money
playing/racing etc. I've always thought electric was a great idea/but there
has been nothing for me. Note: As many of you know my work in computers has
been in HPC, and I've been lucky to spend a lot of time with my customers,
in the auto and aerospace industry (*i.e.* the current Audi A6 was designed
on one of my supercomputer systems).  The key point is have tended to
follow technology in their area and tend to "in-tune" with a lot of
developments.  The result, except for my wife's minivan (that she preferred
in the years when our kids were small), I've always been a
die-hard German-engineered/performance car person.  But when Elon announced
the Model 3 (like 1/2 the techie world), I put down a deposit and waited.

Well why I was waiting, my techie daughter (who also loves cars), got a
chance to drive one.   She predicted I would hate it!!! So when my ticket
finally came up, I went to drive them.  She was right!!!  With the Model 3,
you get a cool car, but it's about the size of a Corrolla.  Coming from
Germans cars for the last 35 years, the concept of spending $60K US in
practice for a Corrolla just did not do it for me.   I ended up ordering the
current Unixmobile, my beloved Tesla Model S/P100D.

The truth is, I paid a lot of money for it but I *value *what I got for my
money. A number of people don't think it's worth it.  I get that, but I'm
still happy with what I have.   Will there someday be a $20K electric car
like my Model S?  While I think electric cars will get there (I point out
the same price curve on technology such microwave ovens from the 1970so
today), but I actually doubt that there will be a $20K electric vehicle
like my Model S.

The reason is that to sell this car because it as to be expensive for
technology-based reasons, so Tesla had to add a lot of 'luxury' features
like other cars in the class, other sports cars, Mercedes,  *et al*.  As
they removed them (*i.e.* the Model 3) you still get a cool car, but it's
not at all the same as the Model S.   So the point is, if I wanted an
electric car, I had to choose between a performance/luxury *vs*.
size/functionality.  I realized I valued the former (and still do), but I
understand not everyone does or will.

Coming back to our topic, I really don't think this is a 'get my lawn'
issue as much, as asking someone what they really value/what they really
need.   If you place a high-value you something, you will argue that its
best; if it has little value you will not.

[-- Attachment #2: Type: text/html, Size: 11739 bytes --]

Re: [TUHS] screen editors

[Jon Steinhart]

Clem Cole writes:
>
> Answering, but  CCing COFF if folks want to continue.  This is less about
> UNIX and more about how we all got to where we are.
>
> On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon@fourwinds.com> wrote:
>
> > Clem, this seems like an unusual position for you to take.  vim is
> > backwards
> > compatible with vi (and also ed), so it added to an existing ecosystem.
> >
> No, really unusually when you think about it.  vim is backward compatible
> except when it's not (as Bakul points out) - which is my complaint.  It's
> *almost* compatible and those small differences are really annoying when
> you expect one thing and get something else (*i.e.* the least astonishment
> principle).
>
> ...

OK, ok, the point that it's not 100% compatible wins the day.  Couple more
points and then it's time to move on.

While I spend a lot of time railing against bad programming, the fact that
vim is huge doesn't bother me too much because my machine has more memory
that the machine on which I started using vi had disk.  And just because it
still blows my mind, my machine (on just one of the drives) has more disk
than was available in the world when I started using vi.  Good chance that
my CPU has more cache memory than the PDP-11/70 on which I started using vi
had main memory.  So the size doesn't matter too much for me.

One of the reasons that I chose vi over emacs was architectural.  At a certain
level, vi was a text editor and emacs was an operating system, and since I was
running UNIX and was a UNIX philosophy person I just didn't want to be running
an operating system on top of an operating system just to do text editing.

It's for that reason that I hate the addition of multiple windows to vi.  I
already have a windowing system on my machine, and that's what I use for windows.
To me, the correct thing to do is to open a new desktop window to edit a new file
and start a new instance of vi, not to use vi to open another internal window.

I guess that what I'm saying is that I think that rather than following the
UNIX philosophy of having distinct tools and composing, much modern software tries
to do too much stuff that's not unique to its domain.  A strained analogy would be
if every "little language" felt that it had to re-implement a big language too.

Jon

Re: [TUHS] screen editors

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

On Thu, Jan 9, 2020 at 10:22 AM Jon Steinhart <jon@fourwinds.com> wrote:

> One of the reasons that I chose vi over emacs was architectural.  At a
> certain
> level, vi was a text editor and emacs was an operating system, and since I
> was
> running UNIX and was a UNIX philosophy person I just didn't want to be
> running
> an operating system on top of an operating system just to do text editing.
>

I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines
at school had emacs as the default editor) and also because it lets me
program better. I didn't let the fact it accomplished that by trying to be
an OS or LISP-M or whatever get in the way of using the best tool for the
job. In the 90s this meant that I had to be careful about the machines I
used it on. These days, it just doesn't matter. Mostly, though, it was
finger muscle memory :)

Warner

[-- Attachment #2: Type: text/html, Size: 1240 bytes --]

Re: [TUHS] screen editors and beyond

[Jon Steinhart]

Warner Losh writes:
>
> I chose emacs because of muscle memory (Both the VAX and TOPS-20 machines
> at school had emacs as the default editor) and also because it lets me
> program better. I didn't let the fact it accomplished that by trying to be
> an OS or LISP-M or whatever get in the way of using the best tool for the
> job. In the 90s this meant that I had to be careful about the machines I
> used it on. These days, it just doesn't matter. Mostly, though, it was
> finger muscle memory :)
>
> Warner

That's a great reason.  I never did any bodybuilding with emacs so I have
different muscle memory.

There is another reason why I stayed away from emacs which is that I was
running projects at the time - I had graduated from being an individual
contributor.  The multiple versions of emacs got in the way.  We had too
many instances where one person would ask another person for help or to
review something, but people using different tools interfered with the
ability of people to walk over to another terminal and get stuff done.

Because of this, I made and enforced a rule that said that one could only 
use shell aliases if they didn't redefine any existing commands.  It was
important for people to be able to work together.  Things were getting
so flexible that it was as if everybody had their own custom power outlets at
their desks preventing any other group member from coming over and plugging
something in.

Taking this in a different direction, one of the other rules that I enforced
was "don't redefine the programming language."  This is in my mind right now
as I try to navigate the linux kernel.  Someone obviously didn't like C and
made a bunch of overly complicated constructs via macros to change it to
something else generating bad code in the process.  It reminded me of the
first time that I ran across this, which was the Bourne shell in C redefined
as Algol.  I recently asked Steve about why he did this and he did give me
an answer which he said I couldn't share until he refined it.  He probably
forgot over the holidays but since I think he's on this list maybe he'll
weigh in.

One amusing thing that Steve told me which I think I can share is why the
symmetry of case-esac, if-fi was broken with with do-done; it was because
the od command existed so do-od wouldn't work!

Jon

Re: [TUHS] screen editors

[Bakul Shah]

On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon@fourwinds.com> wrote:
> 
> It's for that reason that I hate the addition of multiple windows to vi.  I
> already have a windowing system on my machine, and that's what I use for windows.
> To me, the correct thing to do is to open a new desktop window to edit a new file
> and start a new instance of vi, not to use vi to open another internal window.

The Rand editor made good use of multiple windows. You could set things up so
that two windows would scroll *in sync*. This is handy e.g. when you are looking
at two columns or rows that far apart in the same file or in different files and
too large so you need to scroll.

Acme makes even better use of multiple windows. Right click on a compile error
message in one window and the cursor moves the error causing line in the source
file in another window etc. You can repeat as many times as you want.

So I tend to think combining multiple windows and editing can be effective.

> I guess that what I'm saying is that I think that rather than following the
> UNIX philosophy of having distinct tools and composing, much modern software tries
> to do too much stuff that's not unique to its domain.  A strained analogy would be
> if every "little language" felt that it had to re-implement a big language too.

Finding the "right cut" of functionality is not easy. Scheme or Common Lisp?
Editors and a set of tools or an all singing all dancing IDE? Can one implement
something like Photoshop as a set of separate tools that can be combined any way?

What old style Unix tools give you is isolation and (one way) controlled
communication. Can this model be generalized to a set of Lego blocks out of
which one can compose even complex tools such as Photoshop as easily is an open
question. 

Re: [TUHS] screen editors

[Larry McVoy]

On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote:
> It's for that reason that I hate the addition of multiple windows to vi.  

That's just silly.  I frequently open two panes on the same file.  Lets
compare:

Your way:
	- click to open a new terminal
	- click on it because it's not where I want, move it
	- cd to where ever I am
	- vi whatever

My way:
	:sp

You are welcome to your opinion but to argue that multiple panes in
vi aren't useful, fine, maybe not to you.  Don't use them.  Other
people love that feature, that feature is why I tried emacs many
years ago.

Re: [TUHS] screen editors

[Jon Steinhart]

Larry McVoy writes:
> On Thu, Jan 09, 2020 at 09:21:40AM -0800, Jon Steinhart wrote:
> > It's for that reason that I hate the addition of multiple windows to vi.  
>
> That's just silly.  I frequently open two panes on the same file.  Lets
> compare:
>
> Your way:
> 	- click to open a new terminal
> 	- click on it because it's not where I want, move it
> 	- cd to where ever I am
> 	- vi whatever
>
> My way:
> 	:sp
>
> You are welcome to your opinion but to argue that multiple panes in
> vi aren't useful, fine, maybe not to you.  Don't use them.  Other
> people love that feature, that feature is why I tried emacs many
> years ago.

Yes, that is my opinion and clearly yours is different.

Being as I have a huge hi-res screen, I often have other windows
open and ready to do, so all I have to do is move the mouse.

But really to me you're opening yet another can of worms, which is what
I call the "string theory school of design" where every new program
creates its own universe instead of functioning in the existing one.
I'm working on a demonstration project to illuminate a different path,
but it's gonna be a while before I have something to show.

Jon

Re: [TUHS] screen editors

[Steffen Nurpmeso]

Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\
mail.gmail.com>:
 |Answering, but  CCing COFF if folks want to continue.  This is less \
 |about UNIX and more about how we all got to where we are.
 ...

To me endless undo of vim is great, and i am used to it.  I think
i could compile a version from ~20 years ago, supposed to be much
smaller, and i would be ok with it.  You have other windows open,
ok, but you have typed this in a browser that consumes more memory
than all the programs running here altogether have (real), within
a codebase that consists of millions and millions lines of code.
I mean hey, even though decades of development and tens of
thousands of eyes passed, i see super simple compiler errors in
gcc and clang, and except for optimization maybe not that much
improvement in useful diagnostics, even though the executables
are 150 times and more greater than that.

For example i have a netrc parser which uses a fixed size target
buffer, in a 90 lines function, with comments, empty lines, and
a static structure of token types to test-iterate against, and
with a possibly *off++=by;*off='\0'; one, but it took
a Coverity.com run to detect it.  (Actually it is worse, because
this code is from 2014, and it seems only the combination of gcc
8.3.0 and the current cov-analysis-linux64-2019.03 could find it;
not in August, when i checked for the second to last, but only for
the last check.)

 |Let me take a look at this issue in a different way.   I have long \
 |been a 'car guy' and like many of those times in my youth spent time \
 |and money playing/racing etc. I've always thought electric was a 
 |great idea/but there has been nothing for me. Note: As many of you \
 |know my work in computers has been in HPC, and I've been lucky to spend \
 |a lot of time with my customers, in the auto and aerospace 
 |industry (i.e. the current Audi A6 was designed on one of my supercomputer \
 |systems).  The key point is have tended to follow technology in their \
 |area and tend to "in-tune" with a lot of developments.  
 |The result, except for my wife's minivan (that she preferred in the \
 |years when our kids were small), I've always been a die-hard German-eng\
 |ineered/performance car person.  But when Elon announced 
 |the Model 3 (like 1/2 the techie world), I put down a deposit and waited.
 |
 |Well why I was waiting, my techie daughter (who also loves cars), got \
 |a chance to drive one.   She predicted I would hate it!!! So when my \
 |ticket finally came up, I went to drive them.  She was right!!!  
 |With the Model 3, you get a cool car, but it's about the size of a \
 |Corrolla.  Coming from Germans cars for the last 35 years, the concept \
 |of spending $60K US in practice for a Corrolla just did not do it 
 |for me.   I ended up ordering the current Unixmobile, my beloved Tesla \
 |Model S/P100D. 

Corolla is not $60K. So you want 500 horse power, maybe.

 |The truth is, I paid a lot of money for it but I value what I got for \
 |my money. A number of people don't think it's worth it.  I get that, \
 |but I'm still happy with what I have.   Will there someday be a 
 |$20K electric car like my Model S?  While I think electric cars will \
 |get there (I point out the same price curve on technology such microwave \
 |ovens from the 1970so today), but I actually doubt that there 
 |will be a $20K electric vehicle like my Model S.

Well, lucky you that you can and want to spend that much money for
a, hm, car.

 |The reason is that to sell this car because it as to be expensive for \
 |technology-based reasons, so Tesla had to add a lot of 'luxury' features \
 |like other cars in the class, other sports cars, Mercedes,
 |  et al.  As they removed them (i.e. the Model 3) you still get a cool \
 |car, but it's not at all the same as the Model S.   So the point is, \
 |if I wanted an electric car, I had to choose between a 
 |performance/luxury vs. size/functionality.  I realized I valued the \
 |former (and still do), but I understand not everyone does or will.

So i for one _totally_ - totally! - disagree.  It really drives me
up the wall.  You drive around with a 600 kilogramm or even
heavier battery.  You car is about 2000 kilogram.  That is a lot
of resource that needs to be digged, transported, assembled
.. recycled, as far as that is possible.  It increases the load on
the streets, you know, trucks have a factor of an impact higher
than cars.  I mean, in America the difference is maybe not that
big since the average car is very big on its own, i think a pick
up is the most-selled car there for many years, with each instance
being worth at least 2 of the German and Austrian etc. top seller.
You can add to that entire Europe, including England.

The entire car community did know at the end of the 80s
/ beginning of the 90s what is necessary for better Otto and
Diesel engines, and as of today, thirty years later!, not all
engines are actually using these technologies.  There is nothing
new at all regarding technology, nothing!, except of course
materials engineering and robotics.  That is a political
declaration of bankruptcy.  And i hate BMW top managers starting
over with "the problem is not the SUV driver, the problem is the
15 year old family shooting brake".  That is antisocial, ignorant,
reckless and homicidal.

And it was clear what the future after those combustion engines
will be, and that is hydrogen.  That is fuell cell and tank in
sandwich floor, with wheel hub motors.  The latter has always been
my favourite, even though it could increase moved mass, but i do
not know.  So 120 years after wheel hub we choose two on-axe to
reduce production cost.  That is composite material.  Luckily even
some market-based industries have shown the fertility and will to
develop further beyond what was there about 120 years ago,
unfortunately we the Germans not, except for rare military
developments, also decades ago.  I said 26 years ago the best
would be if each and every citizen would gain such a chassis, and
the body would be up to each and everyone, [why not] with some
"Trabant 601 based default".

Even Tesla was interesting, fifteen or so years ago.  Because they
used the Lotus Elite chassis, which is about <800 Kilogramm.
I personally am and always have been a total fan of Chapman's
Philosophy, the lighter, the more beautiful.   And if you want
comfort and industrial mass production, take the Mazda MX-5, it is
1000 Kilogramm, and has 160 horse power.  Your Tesla is still more
powerful, because it has more than 320 horse power, but it is much
heavier around the corners, and much much less swift.  Of course,
i see here in Germany in practice all men above 50 need their SUV
now (thanks America for this future relevant trend), and they look
relaxed, meaningful, potent.  Yet they are not.  See above.  And
they are not, beyond that.  They reflect reckless degeneration.
Yes, the white men's sperm production has halved, their allergies
and woewoes have increased, their abuse of substances is enormous,
and different to normal native human beings, entirely senseless
and not embedded into any cultural surroundings.

I mean, the heck.  This wave has started, we now already explore
digging much more of the necessary resources in the Atacama and
maybe already in some Portuguese nature resource.  We have
interesting things which are maybe ok, like the Honda e.  In the
ever growing mega cities with the necessary infrastructure "i
allow you to" use such city cars.  It may make sense.  What does
not make sense is installing thousands of kilometers of copper
cable to build up an infrastructure for high voltage battery
filling.  Really.  That is copper.  You know how much resources
are required to produce copper?  And in third countries our
industry does not even give the minimum shit and uses the cheap
most poisening elements to do its dirty work.  No!

Yes, just this week i think the German "Die Zeit" had an article
on trash, trash everywhere, the trash island in the pacific is now
as large as Texas they said, i know i have read about this island
of trash in an early 80s book on open sea (sailing) accidents at
the friend of my father, about 35 years ago, i blindly assume it
was smaller by then.  So only the one copper factory in Germany he
was writing about produces more Trash than all European households
altogether.  That is just one.  No!

But there you go along with batteries.  I mean they (Tesla) seem
to have made their homework regarding crash safety, though i also
disliked the crash test standards 26 years ago, and still back
crashs are not tested, and they bang a solid cube regardless of
the misalignment of at least the major masses that happens in
practice if an Escalade hits an AMC Pacer.  They seem to have
created a new user experience that is also much cheaper to build
(i do not like it), the cars have a tremendous power, and
California has a nifty Energy Mix and infrastructure to satisfy
full throttle fun.  (Maybe.)

I admit i was happy once a german car manager said dismissive
words about Tesla (yesyesyes!), but again, just to find out they
were doing and heading out for exactly the same.  Except battery
technology, maybe.  Yes, i think the Porsche Taycan has an
interesting design, i like especially the profile, i could maybe
even like the interieur, for that one, but it is too heavy and
uses the wrong technology.  And no wood.

I for one would not spend that much money for a car anyway, but
if, definitely not like that.  If i buy a CRV Hybrid, or a Suzuki
Vitara, then i can buy a Caterham, a Lotus Elise, and almost
a Morgan 3-Wheeler all in addition to end up at that price.  See,
the latter three are almost hand-built by human beings which
perform craftsmanship, they do real jobs, and can go home prowd or
at least somewhat fullfilled.  Small companies.  Buying and
refining mass production engines (here Ford, Toyota, and S&S).
And the CRV technology will at later times simply replace the
combustion engine with a fuell cell.  And it has some natural
thing in it, a wooden strip.

I personally like the Vitara, because it is only 1300 kilogramm,
can tow enough for me, has a glass roof that can be opened, has
LED lamps, does not contain any leather (no more), and if they
will use the cylinder deactivation that i demanded almost thirty
years ago, and maybe bring in the little Hybrid system they now
introduce to their Ignis and Swift, i would go for it.  The new
Subaru Forester has a 16.7 horsepower electrical add-on.  Enough
for city traffic jam stop and go!  Fiat has the wonderful
two-cylindre engine in Panda and 500, 85 to 105 horsepower.
A wonderful engine!  Ford also, it has a wonderful three-cylindre
engine.  (I am talking Europe here, mind you.)  And next year --
and here it comes!  -- next year Toyota will come over with the
new Mirai, real fuel-cell, refined, and not as a SUV!, and i think
i will buy myself that one.

 |Coming back to our topic, I really don't think this is a 'get my lawn' \
 |issue as much, as asking someone what they really value/what they really \
 |need.   If you place a high-value you something, you will 
 |argue that its best; if it has little value you will not.   

In the end all that is industrial shit.  If you are a lucky man
you are science or worked at Bell Labs.  The rest is all
industrial shit, may it be pharmacy or medicine or whatever else.
With all the little ones trying to get their place at the sun,
recklessly.  It is up to everyone to work on its own reflection
and awareness, and to bring that work into all the many which are
incapable to or uninterested in doing that.  And unfortunately
most do not.  They are never shown, too, which makes me sad.

I will now listen to the Westminster Abbey chorus singing Miserere
mei Deus, just to let you know.  And think how it must have been
by then, with simplemost illnesses and wounds killing everyone
from poor to rich, and with bad weather or other pest causing
starvation and death, with regional food only, if you were lucky,
not kilos of meat with cost backlog every day, when in early
morning hours in a dark church the first sunlight would fall
through handcrafted art- and passionful windows.

 --End of <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail\
 .com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] screen editors

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in <20200109190219.bdHOi%steffen@sdaoden.eu>:
 |Clem Cole wrote in <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@\
 |mail.gmail.com>:
 ...
 ||Let me take a look at this issue in a different way.   I have long \
 ||been a 'car guy' and like many of those times in my youth spent time \
 ||and money playing/racing etc. I've always thought electric was a 
 ||great idea/but there has been nothing for me. Note: As many of you \
 ..
 ||Coming back to our topic, I really don't think this is a 'get my lawn' \
 ||issue as much, as asking someone what they really value/what they really \
 ||need.   If you place a high-value you something, you will 
 ||argue that its best; if it has little value you will not.   

What else.  All the many, many reports and expert assessments
which suddenly appear and point out to the last cent that and why
battery cars are better for the environment than anything else,
including fuell cell driven cars.  Heck, how i hate those.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] screen editors

[Mary Ann Horton]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Yes, I totally agree. NIH was rampant at Bell Labs in the 1980s. 
Management pushed us to use the internal tools rather than external 
tools we liked better. 3B vs Sun comes to mind. Datakit vs TCP/IP.

     Mary Ann

On 1/9/20 7:54 AM, Clem Cole wrote:
> Frankly, other than NIH, I'm not sure why the folks at AT&T decided to 
> create pg a few years later since more was already in the wild, but at 
> least it was a different program (Mary Ann's story of vi /vs/. se if 
> probably in the same vein). 

[-- Attachment #2: Type: text/html, Size: 946 bytes --]

Re: [TUHS] screen editors

[Michael Parson]

On Wed, 8 Jan 2020, Jon Steinhart wrote:

> Clem Cole writes:
>>
>> make a new command, don't break the old one....  maybe offer a way to map
>> the new one over the old -- but don't make it the default.
>> and my lawn was lush and green before the snow came ;-)
>
> Clem, this seems like an unusual position for you to take.  vim is backwards
> compatible with vi (and also ed), so it added to an existing ecosystem.

It's like 99% compatible.  The undo change bothered me a lot, I still
don't really 'get' vim's undo method even having mostly given up on
old vi about 10 years ago.  I'm sure it's better, if I ever got around
to learning it, but I agree with Clem, vim's 'enhanced unlmited undo'
should have moved to a different keybinding.

'vim' also moved the "increment number" command to a new key.

And the one that visually bothered me is 'cw' or 'c<anything>',
immediately removes the text that's going to be replaced.  I liked old
vi's way of leaving it there for you to type over.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

Re: [TUHS] screen editors

[Michael Parson]

On Thu, 9 Jan 2020, Bakul Shah wrote:
> On Jan 9, 2020, at 9:21 AM, Jon Steinhart <jon@fourwinds.com> wrote:
>>
>> It's for that reason that I hate the addition of multiple windows to vi.  I
>> already have a windowing system on my machine, and that's what I use for windows.
>> To me, the correct thing to do is to open a new desktop window to edit a new file
>> and start a new instance of vi, not to use vi to open another internal window.
>
> The Rand editor made good use of multiple windows. You could set things up so
> that two windows would scroll *in sync*. This is handy e.g. when you are looking
> at two columns or rows that far apart in the same file or in different files and
> too large so you need to scroll.

For your .vimrc:

nmap =f :vsplit<bar>wincmd l<bar>exe "norm! Ljz<c-v><cr>"<cr>:set scb<cr>:wincmd h<cr>:set scb<cr>

Don't remember where I picked that up, but this will give you two vim
windows, showing your file in both, one-screen's worth apart, with
synchronized scolling.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

Re: [TUHS] screen editors

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote:

> It's like 99% compatible.

Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
"I'll give you partial credit when you can bring be me a female that is
partially pregnant."

To be you are either compatible or not.  I would have been ok to have had
an option that you could turn on that gave you new behavior (but make the
user turn it on thank you).

BTW:  the cX command's behavior I also find annoying visually, but it does
not screw up 30-40 years of programming in my fingers.

[-- Attachment #2: Type: text/html, Size: 1511 bytes --]

Re: [TUHS] screen editors

[Kurt H Maier]

On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote:
> 
> > It's like 99% compatible.
> 
> Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
> "I'll give you partial credit when you can bring be me a female that is
> partially pregnant."
> 
> To be you are either compatible or not.  I would have been ok to have had
> an option that you could turn on that gave you new behavior (but make the
> user turn it on thank you).
> 
> BTW:  the cX command's behavior I also find annoying visually, but it does
> not screw up 30-40 years of programming in my fingers.

There was a time when, by default, vim started in 'compatible' mode, in
which u didn't ignore u, so you got the toggle-style undo.  Compatible
mode also keeps the ol$ style of c representation, and so forth.  You
can still force this by making a ~/.vimrc file that just contains

set compatible

I don't remember when vim stopped launching in compatible mode by
default, but that was basically when I stopped using it.  I only figured
out how to force it back because it's on all the linux computers I run
into at work.

As I recall, the 'set compatible' command is shorthand to set all the
vi-compatibility flags by default; it is possible to set them
individually as well.  So your proposal is (was?) at least implemented,
if not in a very useful manner.

khm

Re: [TUHS] screen editors

[Michael Parson]

On Wed, 8 Jan 2020, Nemo Nusquam wrote:
> On 01/08/20 04:46, Rudi Blom wrote:
>> That's a real big vi in RHL. Looking at a few (commercial) unixes I get
>> SCO UNIX 3.2V4.2 132898 Aug 22 1996 /usr/bin/vi
>>   - /usr/bin/vi: iAPX 386 executable
>> Tru64 V5.1B-5 331552 Aug 21 2010 /usr/bin/vi
>>   - /usr/bin/vi: COFF format alpha dynamically linked, demand paged
>> sticky executable or object module stripped - version 3.13-14
>> HP-UX 11.31 748996 Aug 28 2009 /bin/vi
>>   -- /bin/vi: ELF-32 executable object file - IA64
>
> Solaris 10 on Ultrasparc 239828
>  /usr/bin/vi:    ELF 32-bit MSB executable SPARC Version 1, dynamically 
> linked, stripped
>
> Any others?

I've been playing with this for the last few months:

$ uname -a
UNIX_System_V amix 4.0 2.1c 0800430 Amiga (Unlimited) m68k

$ file /usr/bin/vi
/usr/bin/vi:    ELF 32-bit MSB executable M68000 Version 1

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

Re: [TUHS] screen editors

[Larry McVoy]

On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> On Fri, Jan 17, 2020 at 9:35 PM Michael Parson <mparson@bl.org> wrote:
> 
> > It's like 99% compatible.
> 
> Exactly...  As my old (non-PC) 10th-grade calculus teacher used to say,
> "I'll give you partial credit when you can bring be me a female that is
> partially pregnant."
> 
> To be you are either compatible or not.  I would have been ok to have had
> an option that you could turn on that gave you new behavior (but make the
> user turn it on thank you).

It's rare event when I disagree with you, Clem (sometimes it seems like
we were separated at birth :)  If it was compat by default then you
wouldn't learn any of the new stuff.  

set compatible

isn't that hard but we'd have to read docs to find that.  

Anyhoo, cross reference to Ted's thought that Linux didn't have to 
deal with the Gods of BSD so they could rip stuff out and try again,
his point is that worked better than the BSD way.  Compat is fine
but if you want progress, sometimes you break compat.

For me, I've got a .exrc that I've been carrying around for decades
(has maps in it for some compat bindings to an editor I used on CP/M,
it's _that_ old) and vim is perfectly happy with it.

I mostly use vim as a vi compat but I regularly use 2 panes, that's
super useful.  It's progress and you can have compat mode easily,
seems like a win.

Re: [TUHS] screen editors

[markus schnalke]

Hoi.

Not wanting to heaten this rather annoying editor discussion, but
as no one yet has mentioned argv[0]:

[2020-01-18 07:37] Larry McVoy <lm@mcvoy.com>
> On Fri, Jan 17, 2020 at 10:13:45PM -0500, Clem Cole wrote:
> > 
> > To be you are either compatible or not.  I would have been ok to have had
> > an option that you could turn on that gave you new behavior (but make the
> > user turn it on thank you).

> If it was compat by default then you
> wouldn't learn any of the new stuff.  

> set compatible

Shouldn't all that be solved by acting compatible if called as
`vi' and being free from compatibility bounds when called as
`vim'?

If I say `vi' I want a vi. If I want Vim, I say so. (No matter
if these are links to the same binary.)

Problem solved. Everyone happy?


meillo

Re: [TUHS] screen editors and beyond

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

http://man.cat-v.org/plan_9/1/xd

There's a copy of the source in plan9port.

-rob


On Fri, Jan 10, 2020 at 11:26 PM Andrew Luke Nesbit <
ullbeking@andrewnesbit.org> wrote:

> On 10/01/2020 01:52, Rob Pike wrote:
> > I wrote xd for a reason.
>
> What is xd?  Please could you send a link to it?  Thank you!!
>
> Andrew
> --
> OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9
>

[-- Attachment #2: Type: text/html, Size: 826 bytes --]

Re: [TUHS] screen editors and beyond

[Mark van Atten]

On Fri, 10 Jan 2020 at 13:27, Andrew Luke Nesbit
<ullbeking@andrewnesbit.org> wrote:
>
> On 10/01/2020 01:52, Rob Pike wrote:
> > I wrote xd for a reason.
>
> What is xd?  Please could you send a link to it?  Thank you!!

I'm obviously not Rob Pike, but here is a link to the man page of (the
plan9port incarnation of) xd:
https://9fans.github.io/plan9port/man/man1/xd.html

Mark.

Re: [TUHS] screen editors and beyond

[Andrew Luke Nesbit]

On 10/01/2020 01:52, Rob Pike wrote:
> I wrote xd for a reason.

What is xd?  Please could you send a link to it?  Thank you!!

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: [TUHS] screen editors and beyond

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

I wrote xd for a reason.

-rob

[-- Attachment #2: Type: text/html, Size: 278 bytes --]

Re: [TUHS] screen editors and beyond

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Thu, Jan 9, 2020 at 4:54 PM Norman Wilson <norman@oclsc.org> wrote:

> As I heard the story in the UNIX room decades ago (and at least five
> years after the event), Steve tried and tried to convince Ken to
> rename od so that he could have the symmetry he wanted.  Ken was
> unmoved.


I admit I'm not sure which solution is 'least astonishing.'  Just think if
DEC had used hex for years, instead of octal ;-)

[-- Attachment #2: Type: text/html, Size: 996 bytes --]

Re: [TUHS] screen editors and beyond

[Richard Salz]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

At first I wanted to know why having an "od" command interfered with the
shell's source code of #define, but then I realized y-all meant the control
structures for scripting :)

[-- Attachment #2: Type: text/html, Size: 238 bytes --]

Re: [TUHS] screen editors and beyond

[Norman Wilson]

Jon Steinhart:

  One amusing thing that Steve told me which I think I can share is why the
  symmetry of case-esac, if-fi was broken with with do-done; it was because
  the od command existed so do-od wouldn't work!

=====

As I heard the story in the UNIX room decades ago (and at least five
years after the event), Steve tried and tried to convince Ken to
rename od so that he could have the symmetry he wanted.  Ken was
unmoved.

Norman Wilson
Toronto ON