7 Jan
2020
7 Jan
'20
2:31 a.m.
but…damn, even ex/vi 3.x is huge
It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
Doug
7 Jan
7 Jan
2:37 a.m.
Well said. I do as well.
On Jan 6, 2020, at 9:31 PM, Doug McIlroy
<doug(a)cs.dartmouth.edu> wrote:
but…damn, even ex/vi 3.x is huge
It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
Doug
2:38 a.m.
On Mon, Jan 06, 2020 at 09:31:44PM -0500, Doug McIlroy wrote:
I grew up on 4MB Suns. Emacs was "8 megs and constantly swapping".
I thought vi was fine though I did do a lot with xvi (I think that was
what it was called) and I hacked it to use mmap to look at the file.
I had to do something about strings to make that work, don't remember,
but it worked and I could vi 4MB log files and search them pretty fast.
I'm a vi guy to this day. Love it.
but???damn,
even ex/vi 3.x is huge
It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today. 
4:30 p.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
I'm a vi guy to this day. Love it.
In the summer of '82 I did some contract programming at Southern Bell
on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se'
that I only ever saw there, written somewhere in the Bell System and
squeezed to run on an -11. Anyone know anything about it?
Unrelated, Georgia Tech had the 'se' screen editor as part of the
Software Tools Subsystem, based on the 'ed' in the Software Tools book.
This was later ported to Unix. I modified that code to use curses/termlib
and posted it to USENET. It's been updated and is available from
https://github.com/se-editor/se and http://se-editor.org is the home
page. (Thomas Cort IIRC did that work.)
What's funny is that in doing the work to get 'se' running on Georgia
Tech's Vax, I had to learn vi. By the time I was done, vi had become
my main editor and had burned itself into my finger's ROMs.
Arnold
4:38 p.m.
Any fans of the Rand Editor?
https://github.com/blakemcbride/Rand-E-Editor
And do folks here know of the TextEditors wiki at
http://texteditors.org/cgi-bin/wiki.pl?HomePage ?
6:32 p.m.
On Tue, Jan 7, 2020 at 11:31 AM <arnold(a)skeeve.com> wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
Ah, this reminds me of something. I assume you've read, "A Software Tools
Sampler"?
A few months ago, I started looking into screen update algorithms for a
(frivolous) retro-computing time sink, er, I mean project.
Naturally, Gosling's redisplay algorithm figured prominently, as it's
famous and well-known. I looked at the Unix emacs code and it's not that
hard to puzzle through, actually, despite the reputation and the (in)famous
skull and crossbones comment. However, Gosling's code assumes that update
commands all have uniform cost (cost here being proportional to the
command's length) which, on real terminals, just isn't true. Meyers and
Miller came up with several algorithms that take into account editing
command cost, and produce potentially far-better solutions than Gosling's
code, though limited by the inability at the time to quickly build suffix
trees (this was about a decade before Ukkonen's algorithm); it's
interesting that none of these algorithms take into account text
attributes, which on most serial terminals are modal. Anyway, at least one
of these algorithms was implemented in a modified version of `se`, as
described in "A Software Tools Sampler." I guess Webb thought that was
easier to work with than an existing editor? Perhaps these "se"s share a
lineage?
What's interesting to me is that redisplay algorithms were clearly an area
of active research at one time, but interest seemed to dry up almost over
night. One must presume that this evaporation of research activity had to
do with the en mass migration to graphical workstations where the problems
are different, and possibly with curses being "good enough" in e.g. an
xterm. However, one can see some of the fruits of Miller's research in his
later work in genomics.
- Dan C.
A few random references:
Gosling, James, "A Redisplay Algorithm."
https://dl.acm.org/doi/10.1145/872730.806463
Meyers, Eugene and Webb Miller, "A Simple Row Replacement Algorithm."
https://dl.acm.org/doi/10.5555/52187.52188
Meyers, Eugene and Webb Miller, "Row Replacement Algorithm for Screen
Editors." https://dl.acm.org/doi/10.1145/59287.59290
I'm a vi guy to this day. Love it.
In the summer of '82 I did some contract programming at Southern Bell
on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se'
that I only ever saw there, written somewhere in the Bell System and
squeezed to run on an -11. Anyone know anything about it?
Unrelated, Georgia Tech had the 'se' screen editor as part of the
Software Tools Subsystem, based on the 'ed' in the Software Tools book.
This was later ported to Unix. I modified that code to use curses/termlib
and posted it to USENET. It's been updated and is available from
https://github.com/se-editor/se and http://se-editor.org is the home
page. (Thomas Cort IIRC did that work.)
What's funny is that in doing the work to get 'se' running on Georgia
Tech's Vax, I had to learn vi. By the time I was done, vi had become
my main editor and had burned itself into my finger's ROMs.
7:14 p.m.
What's funny is that in doing the work to get
'se' running on Georgia
Tech's Vax, I had to learn vi. By the time I was done, vi had become
my main editor and had burned itself into my finger's ROMs.
I do ed/se
occasionally for simple tasks, vim frequently , because it loads fast, and emacs for all
bigger projects, beside liteide for golang.
10 Jan
10 Jan
8:16 a.m.
On 1/9/20 5:01 AM, Grant Taylor via TUHS wrote:
On 1/7/20 12:14 PM, Thomas Paulsen wrote:
I think he is referring to http://se-editor.org/, mentioned earlier in the
thread.
vks
I do ed/se occasionally for simple tasks
Was that supposed to be "sed"? Or is "se" something that I'm
not
familiar with?
8 Jan
8 Jan
12:10 a.m.
arnold(a)skeeve.com writes:
Larry McVoy <lm(a)mcvoy.com> wrote:
> I'm a vi guy to this day. Love it.
I'm a vi guy these days. My first screen editor was something called DTE
for Display Terminal Editor written by Dick Hause that ran on the Glance G
terminals hooked our Honeywell 516 running 516-TSS. I have some vague
recollection of at least one of these terminals ending up in the attic in
the UNIX room, but I don't think that the editor was ever ported. It was
painful to have to use ed or the 516-TSS equivalent when a terminal wasn't
available. Vi was an easy transition because the ed commands could be used
until the fancier stuff was learned. Also because that great vi trainer
program rogue existed :-)
Jon
17 Jan
17 Jan
10:06 p.m.
On Tue, 7 Jan 2020, Jon Steinhart wrote:
Also because that great vi trainer program rogue
existed :-)
The story is told of some professor having to learn VI, because EMACS was
not available. After a few minutes, he said "Hmmm... It's just like
Rogue".
FWIW, I once discovered a bug in the Curses library following an upgrade
on the Mac: Rogue had stopped working :-)
-- Dave
8 Jan
8 Jan
6:30 p.m.
It's interesting how much of this has been lost to history. Curses, in
particular, is sketchily documented, and se is unknown. Here's how I
remember it.
Bill Joy made major enhancements to previously enhanced versions of ed,
creating vi. In 1979, he bumped up against the 64K boundary on the
PDP-11, and handed it off to me. I made some more smaller enhancements.
vi was huge by the standards of the day, especially compared to ed.
There were ifdefs to take out several features, such as support for
upper case only terminals, to make it fit on the PDP-11. I had to split
it into version 2 (16 bit) and 3 (32 bit) to be able to enhance it and
still support 2BSD on the PDP-11.
Ken Arnold took the screen updating code from vi (just the "full screen
update", not the parts that did insert/delete line/char) and turned it
into the curses library. Rogue was the primary user of curses.
Once I graduated from Berkeley went to Bell Labs, I took vi, termcap,
and curses with me. I replaced termcap, which was too slow to start up
(it was quadratic on the size of the entry, which was awful on the
hardware of the day) with terminfo, a binary version that was faster. It
included tools like tic and infocmp to translate back and forth to text
and termcap.
I also rewrote curses with a new algorithm that fully utilized
insert/delete line/char. I had a paper to publish on the subject, but I
lost it and never did publish it.
I gave a talk at Usenix Boston in 1982 about the new curses and
terminfo. But I couldn't release the code, because it was considered
proprietary. Pavel Curtis offered to clone it, and I coached him on the
algorithm and specs, and he released a good clone pcurses. Eventually
that became ncurses.
Nearly everyone at Bell Labs (outside area 11) was using either vi or
emacs, but System III just had ed. There was a big push to add vi or
emacs to UNIX 3.0 (System III), but USG instead chose to write se, the
"screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0
(System V) relented and included vi.
Mary Ann
On 1/7/20 8:30 AM, arnold(a)skeeve.com wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
I'm a vi guy to this day. Love it.
In the summer of '82 I did some contract programming at Southern Bell
on a PDP-11 running USG Unix 4.0. It had a screen editor called 'se'
that I only ever saw there, written somewhere in the Bell System and
squeezed to run on an -11. Anyone know anything about it?
Unrelated, Georgia Tech had the 'se' screen editor as part of the
Software Tools Subsystem, based on the 'ed' in the Software Tools book.
This was later ported to Unix. I modified that code to use curses/termlib
and posted it to USENET. It's been updated and is available from
https://github.com/se-editor/se and http://se-editor.org is the home
page. (Thomas Cort IIRC did that work.)
What's funny is that in doing the work to get 'se' running on Georgia
Tech's Vax, I had to learn vi. By the time I was done, vi had become
my main editor and had burned itself into my finger's ROMs.
Arnold
9:41 p.m.
It's interesting how much of this has been lost
to history. Curses, in
thanks for the deep insider view.
I heard that Bill's ex/vi sources were incomprehensible 'read never' code.
Hence it makes no wonder that everybody failed adding real support for cursor keys. beyond
automatically switching from insert to visual mode on hitting any cursor key!
9 Jan
9 Jan
8:30 a.m.
Mary Ann Horton <mah(a)mhorton.net> wrote:
Nearly everyone at Bell Labs (outside area 11) was
using either vi or
emacs, but System III just had ed. There was a big push to add vi or
emacs to UNIX 3.0 (System III), but USG instead chose to write se, the
"screen editor" and put it in UNIX 4.0. Nobody would use it, so UNIX 5.0
(System V) relented and included vi.
Thanks for confirming that se existed in Unix 4.0, as I remember it.
I used it some; the only thing I remember about it was that the command
line was at the top of the screen.
I must have been disappointed with it, because I ended up doing most
of my contract programming work in ed. :-)
It'd be interesting to see the source for this 'se', but it's
probably
lost forever.
Arnold
7 Jan
7 Jan
6:19 a.m.
I don't recall the exact details, but there was once an editor called "em"
(Editor for Mortals). I remember thinking: what sort of an idiot would
call it that, with the "e" and "r" keys adjacent to each other? I
wonder
how many files were lost that way...
-- Dave
8:24 a.m.
I don't recall the exact details, but there was
once an editor called "em"
(Editor for Mortals). I remember thinking: what sort of an idiot would
call it that, with the "e" and "r" keys adjacent to each
other? I wonder how many files were lost that way...
you can download, build and
use em making immediately clear that em was much easier
to use than ed. Nevertheless em was only (another) step in between ed and vi.
http://pgas.freeshell.org/C/em/
http://www.tuhs.org/Archive/Applications/Em_Editor/
http://www.coulouris.net/cs_history/em_story/emsource/
8:44 p.m.
On Tue, 7 Jan 2020, Thomas Paulsen wrote:
I'm sure you're right, but that wasn't the point that I was making...
-- Dave
I don't
recall the exact details, but there was once an editor called
"em" (Editor for Mortals). I remember thinking: what sort of an idiot
would call it that, with the "e" and "r" keys adjacent to each other?
I wonder how many files were lost that way...
you can download, build and use em making immediately clear that em was
much easier to use than ed. Nevertheless em was only (another) step in
between ed and vi. 
8 Jan
8 Jan
3:29 p.m.
On 07/01/2020, Dave Horsfall <dave(a)horsfall.org> wrote:
I don't recall the exact details, but there was
once an editor called "em"
(Editor for Mortals). I remember thinking: what sort of an idiot would
call it that, with the "e" and "r" keys adjacent to each other? I
wonder
how many files were lost that way...
It was a line editor which resembled ex, came from QMC London and was
used on some VAX BSD systems in UK Universities in the early '80s. The
source is online.
As for "rm" typos I'm sure many discovered netnews the same way!
--
Steve Mynott <steve.mynott(a)gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
7 Jan
7 Jan
9:43 a.m.
7 Jan 2020 02:32:11 Doug McIlroy :
Sam was the first screen editor that I deemed
worthwhile, and I
still use it today.
I would like to experiment with Sam and run it on various *nix operating systems. There
seems to be many ports.
Do I need to install some kind of Plan 9 emulation layer (in user space), which Sam builds
and runs on? Obviously I'm referring to Russ Cox's libraries and user space
tools.
Is it necessary to have a p9 environment to gain the most advantage of a tool like Sam?
Or, is it possible for it still to function well as a transplant in a new environment such
as *nix?
In that second case, what are the well ported versions of Sam that build and run directly
on the target environment?
Andrew
2:53 p.m.
On Tue, Jan 7, 2020 at 4:50 AM <ullbeking(a)andrewnesbit.org> wrote:
7 Jan 2020 02:32:11 Doug McIlroy :
It is not necessary to have a plan 9 environment to take advantage of Sam,
and there was once a port for Unix that worked outside of the usual Plan 9
world. Indeed, Sam got its start on Unix.
However, I dare say that the best port to use is the one from plan9port:
Sam continued to evolve on plan9, if only gaining incremental improvements
after the early Unix years. By using the plan9port version, you'll pick up
on those changes (though I can't really enumerate them anymore).
- Dan C.
Sam was the first screen editor that I deemed
worthwhile, and I
still use it today.
I would like to experiment with Sam and run it on various *nix operating
systems. There seems to be many ports.
Do I need to install some kind of Plan 9 emulation layer (in user space),
which Sam builds and runs on? Obviously I'm referring to Russ Cox's
libraries and user space tools.
Is it necessary to have a p9 environment to gain the most advantage of a
tool like Sam? Or, is it possible for it still to function well as a
transplant in a new environment such as *nix?
In that second case, what are the well ported versions of Sam that build
and run directly on the target environment?
7:35 p.m.
i like to use it natively as much as possible, especially the 9front
edition with its usability (e.g. mouse chording) improvements. if that is
not possible, i drawterm into some cpu or a local vm where i can get a
little environment to work with whatever is at /mnt/term.
it also has a powerful command language and structural regular expressions,
and you can use your favorite unix tools on any piece of text you please.
it has given me the best text editing and programming experience i've ever
had.
-rodri
On Tue, Jan 7, 2020, 10:50 AM <ullbeking(a)andrewnesbit.org> wrote:
7 Jan 2020 02:32:11 Doug McIlroy :
Sam was the first screen editor that I deemed
worthwhile, and I
still use it today.
I would like to experiment with Sam and run it on various *nix operating
systems. There seems to be many ports.
Do I need to install some kind of Plan 9 emulation layer (in user space),
which Sam builds and runs on? Obviously I'm referring to Russ Cox's
libraries and user space tools.
Is it necessary to have a p9 environment to gain the most advantage of a
tool like Sam? Or, is it possible for it still to function well as a
transplant in a new environment such as *nix?
In that second case, what are the well ported versions of Sam that build
and run directly on the target environment?
Andrew
8 Jan
8 Jan
5:13 a.m.
On Tue, 7 Jan 2020 at 20:36, Rodrigo G. López <rodrigosloop(a)gmail.com> wrote:
i like to use it natively as much as possible, especially the 9front edition with its
usability (e.g. mouse chording) improvements. if that is not possible, i drawterm into
some cpu or a local vm where i can get a little environment to work with whatever is at
/mnt/term.
In the opposite direction of your preference for a native environment:
A port of 9front sam (with chording) to unix is available at
https://bitbucket.org/iru/sam9f-unix/src/default/
I use it as a drop-in replacement for the plan9port version.
it has given me the best text editing and programming
experience i've ever had.
For most types of editing I have come to prefer it over acme. The one
modification I should, perhaps, like to see is the possibility to
scroll the window while selecting. Rob Pike has made some comments on
the difficulty here; see the quotations and links in the discussion at
https://github.com/deadpixi/sam/issues/85
(incidentally, on the github pages of another fairly recent port of sam.)
A proposal for a (GSOC) project to improve sam scrolling:
http://fqa.9front.org/appendixg.html
Mark.
7 Jan
7 Jan
3:03 p.m.
On Mon, Jan 6, 2020 at 9:32 PM Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
Oh so true; although the early version from 2BSD was smaller. I bet my
fingers are still only using much of that subset ;-) But I certainly
watched it grow and grow over the years. I'm really not so sure about
'vim' -- it has become as much of a feature sink as emacs.
FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition
and somewhat pined for a screen editor. Soon after upgrading to 6th
edition at CMU, we found a visual editor called Fred - the Friendly Editor,
from Cornell IIRC (I think it's on the original USENIX tape but I don't
remember how we got it). I had to hack in the Perkin-Elmer Fox terminal
support, but it was a superset of V6 ed so a pretty trivial learning curve.
However, since Fred had the terminal support compiled it and when I went to
Tektronix a few years later, I had to add a whole bunch of new terminals
and we quickly started running into the address issues on the 11/40 class
systems. Mark Bales was working as a summer student and had brought 2BSD
with him (inc. vi and csh). Poof, thanks to termcap ex/vi could run on
most every terminal we already had (in some manner) which Fred could not.
And because of termcap not having to keep the code for the other terminals
not being used in memory, even though the editor itself was more complex,
we could just squeeze that version on an 11/40 class system running Seventh
Edition. That made me take notice. Again it was ed under the covers so
the transition was easy. I was pretty impressed with termcap, and soon
thereafter I found myself sending Mary Ann a couple of new terminal
definitions for some missing Tek terminals like Tek 4025.
With the VAX, and new ex/vi shows up and it would not run on the PDP-11's,
I was disappointed. But the old version still worked and I had started to
notice that a *version of **vi *had started to show up on most everything I
used, from VMS to the Cray's and later the PCs, so really I never looked
back. It became the most portable editor for my fingers as I had long ago
forgotten EMACS (even when we got Vaxen and Gosling EMACS shows up on the
UNIX scene, I never bother to really relearn it - I can use it if I have
too, but not as well as vi these days).
but…damn, even
ex/vi 3.x is huge
It was so excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
Doug
8 Jan
8 Jan
9:43 p.m.
New subject: screen editors (FRED)
At Tue, 7 Jan 2020 10:03:57 -0500, Clem Cole <clemc(a)ccc.com> wrote:
Subject: Re: [TUHS] screen editors
FWIW: When I went from PDP-10 land to UNIX, I learned ed for 5th edition
and somewhat pined for a screen editor. Soon after upgrading to 6th
edition at CMU, we found a visual editor called Fred - the Friendly Editor,
from Cornell IIRC (I think it's on the original USENIX tape but I don't
remember how we got it). I had to hack in the Perkin-Elmer Fox terminal
support, but it was a superset of V6 ed so a pretty trivial learning curve.
Ah, yes, Fred. A name with so many editors!
I used a full-screen version of an ed-like editor on V7, 32B, and 4BSD
at University of Calgary which was called the "FRiendly EDitor". This
may be the one you mention.
The FRED I know is not to be confused with the version of QED named FRED
(Friendly Editor) that was written at the University of Waterloo for
Honeywell GECOS by Peter Fraser. It's also not the "FRED - A Friendly
Editor" by Richard J. Botting [1]. There's also apparently an editor
named FRED for VMS, and another for Amstrad PCW systems (for editing
BASIC, and apparently written in BASIC itself). And then there's the
one from a company called Digitool which was called "FRED: Fred
Resembles Emacs Deliberately", which was written in Macintosh Common
Lisp. There's also an old Windows-based "Friendly Right-to-Left Editor
(FRED)" by NSRI. I also recently found this [2] reference to a "FRED",
but it seems to be yet another completely different kind of editor using
the same name.
[1] http://www.csci.csusb.edu/dick/papers/rjb84a.FRED.mth
[2] https://www.osti.gov/biblio/5141603-fred-program-development-tool
Abstract:
The structured, screen-based editor FRED is introduced. FRED
provides incremental parsing and semantic analysis. The parsing is
based on an LL(1) top-down algorithm which has been modified to
provide follow-the-cursor parsing and soft templates. The languages
accepted by the editor are LL(1) languages with the addition of the
Unknown and preferred production non-terminal classes. The semantic
analysis is based on the incremental update of attribute grammar
equations. We briefly describe the interface between FRED and an
automated reference librarian system that is under development.
FRED User's Manual
Shilling, J.
Illinois University, Urbana
Department of Computer Science
Feb. 1984
FRED, the frinedly editor, is a screen-based structured editor.
This manual is intended to serve the needs of a wide range of users
of the FRED text editor. Most users will find it sufficient to read
the introductory material in section 2, supplemented with the full
command set description in section 3. Advanced users may wish to
change the keystroke sequences which invoke editor commands.
Section 4 describes how to change key bindings and how to define
command macros. Some users may need to modify a language
description or create an entirely new language description for use
with FRED. Section 5 describes the format of the language
descriptions used by the editor, and describes how to construct a
language grammar. Section 6 describes known portability problems of
the FRED editor and should concern only system installation
personnel. The editor points out syntax errors in the file being
edited and does automatic pretty printing.
The version of Fred I used had a full-screen line-oriented mode as well
as what was called "open" mode which presented a much more direct
full-screen editing experience (though it was a bit quirky, but it
reminded me a bit of "Electric Pencil II" which I had used on a Sol-20).
Open mode of course generated an interrupt for every key press and so on
a PDP-11/60 with 16 terminals it could cause quite a system load, and
most of us avoided using open mode on the PDPs. Even the VAX 11/780
running 32V was sometimes slowed by it, but it had at least 24 terminals
as I recall (at the time it was still running 32V), so a room full of
students feverously typing away was quite a lot of input.
I've been unable to find any other reference or mention of this version
of Fred; and to the best of my searches it's not on any Usenix tape I
can find a copy of.
If anyone has any further info about the FRED Clem and/or I seem to
remember, please do post it!
I soon forgot most that I knew about Fred though once Gosling Emacs was
installed on the VAX (after it had been upgraded to 4BSD). I already
had a strong preference to Emacs having used it extensively on the
Multics system at UofC.
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
9 Jan
9 Jan
12:04 a.m.
New subject: screen editors (FRED)
I'm surprised that no-one has mentioned "F*cking Ripper of an EDitor" yet,
or was it UNSW-only?
-- Dave
7 Jan
7 Jan
3:50 p.m.
It was so excesssive right from the start that I
refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
my sam build is more than 2 times bigger than Gunnar
Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram
Moolenaar's vim.
8:45 p.m.
On 1/7/20 10:50 AM, Thomas Paulsen wrote:
If we're really doing this editor size contest thing, I'll submit my `ce'
editor. (ftp://ftp.cwru.edu/pub/chet/ce-4.8.tar.gz). It's emacs-like, but
not particularly configurable, and the defaults, strangely enough, are
exactly what I like.
On my Mac OS X machine, it's about ten times smaller than vim
$ size /usr/local/bin/ce
__TEXT __DATA __OBJC others dec hex
114688 339968 0 4295024640 4295479296 10007d000
$ size /usr/bin/vim
__TEXT __DATA __OBJC others dec hex
1687552 176128 0 4295016448 4296880128 1001d3000
Similar numbers on RHEL 7, but due to the large bss, it's only about
45% smaller than vim.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
It was so
excesssive right from the start that I refused to use it.
Sam was the first screen editor that I deemed worthwhile, and I
still use it today.
my sam build is more than 2 times bigger than Gunnar
Ritter's vi (or Steve Kirkendall's elvis) and even bigger than Bram
Moolenaar's vim. 
9:20 p.m.
On Tue, Jan 07, 2020 at 03:45:24PM -0500, Chet Ramey wrote:
On my Mac OS X machine, it's about ten times
smaller than vim
$ size /usr/local/bin/ce
__TEXT __DATA __OBJC others dec hex
114688 339968 0 4295024640 4295479296 10007d000
$ size /usr/bin/vim
__TEXT __DATA __OBJC others dec hex
1687552 176128 0 4295016448 4296880128 1001d3000
Similar numbers on RHEL 7, but due to the large bss, it's only about
45% smaller than vim.
So I got curious about those large numbers on the mac, and made use of 'otool
-l'.
It would seem that the values for __DATA reported by size correspond to the overall
size of the 'load command' for the __DATA segment, and so includes bss as well.
$ ls -l /usr/bin/vim
-rwxr-xr-x 1 root wheel 1530064 29 Jun 2018 /usr/bin/vim
So 'size' on the mac is not so useful, but 'size -m /usr/bin/vim'
gives
information from which one could derive the normal 'size' output.
$ size -m /usr/bin/vim
Segment __PAGEZERO: 4294967296
Segment __TEXT: 1388544
Section __text: 1271745
Section __stubs: 1044
Section __stub_helper: 1756
Section __cstring: 85892
Section __const: 14672
Section __unwind_info: 8944
total 1384053
Segment __DATA: 155648
Section __got: 1056
Section __nl_symbol_ptr: 16
Section __la_symbol_ptr: 1392
Section __const: 38608
Section __data: 64432
Section __bss: 42520
Section __common: 5720
total 153744
Segment __LINKEDIT: 36864
total 4296548352
DF
1561
days inactive
1571
days old
28 comments
20 participants
participants (20)
-
arnold＠skeeve.com -
Brantley Coile -
Chet Ramey -
Clem Cole -
Dan Cross -
Dave Horsfall -
Derek Fawcus -
Doug McIlroy -
Grant Taylor -
Greg A. Woods -
Jon Steinhart -
Larry McVoy -
Mark van Atten -
Mary Ann Horton -
ricercar＠lycos.com -
Richard Salz -
Rodrigo G. López -
Steve Mynott -
Thomas Paulsen -
ullbeking＠andrewnesbit.org