Re: [TUHS] screen editors and beyond

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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