Mailinglist Archive: opensuse (1231 mails)

< Previous Next >
Re: [opensuse] Silly little text file editing question...[Friday, getting OT]
Per Jessen said the following on 03/01/2013 05:57 AM:
Anton Aylward wrote:

Per Jessen said the following on 02/28/2013 03:15 PM:

There is also the little matter of two completely different
environments - a IBM 3270 terminal vs the DEC VT100 (essentially).
The former is screen based, the latter is line based.

The KSR-33 was line based but not the VY-100. As far back as 1982 I
was using VI on VT100 and clones (made by Wyse or someone) in full
screen mode. That's what TERMCAP was for. Thank you Bill Joy.

Not the interface, the technology. Everything you send to a VT-100 is
line base, one long string, optionally with ANSI control characters. A
3270 is more like a directly addressable full screen. Well, I guess
whatever comes down the line is a string too, but that's what a 3270
looks like to a programmer.

And its just the same with VI and other applications that used the
ncurses package and the like (ncurses was 'extracted' from the original
VI's mechanisms). They maintain a internal screen logical image. IIR
Bill Joy's VI kept this as a linked list. I once had to work on that
code and boy was it crufty! One man's really optimized work and almost
unintelligible to mere mortals. the code-base for VIM is so much nicer.

So, to the programmer working with ncurses the programming model was a
directly addressable full screen. You updated it and then did a 'sync'
-- "refresh()', and the algorithms worked out the best/optimal/minimal
stuff to send to the terminal.

And there in is the difference. TERMCAP tried to support cursor
addressing and such things as as region (not just single line) updates.
Some terminals could update a region in the middle of the screen:
specify a bounding box and fill it thusly. So using ncurses was
efficient on bandwidth (great over a slow modem).

The programming reality was that there were higher level layers of code
that made the manipulation of such easier, all the way up to 'layers'
which implemented a text-based windows system.

You might also find the referred to as 'panels'

Of course this got rapidly replaced when the IBM PC came out and made
cheap graphics and eventually GEM and MS-Windows available.

I still have the SVR4 and USG manuals .. moment.

Here we are: AT&T System V Interface Definition Volume 2, Part VI
Terminal Interface Extension Definition. P426 Curses - CRT screen
handling and optimization package.
ISBN: 0-932764-10-X

One funny thing is - the standard IBM line length is 80 chars, which
goes all the way back to punchcards. I have not worked with
punchcards myself, but IBM JCL is nothing but "screen" punchcards.

I had to for a very short time.
I hated it and soon found a PDP-11 running RSTS that supported RJE.
That PDP-11 was then knobbled by some post-grads to run UNIX version 5,
and I didn't want to let go, so they took me along as test case for
their work on compiler development and I got to play with the new
languages they were dreaming up. And UNIX. Eventually I did system and
kernel hacking on V6 and V7, then on System III and System V commercially.

However, think about how often we limit ourselves to 80 chars - in
email, in code, everywhere. If it wasn't for punchcards, we wouldn't
have a continuation character.

Yes, but there's a lot about UNIX and the 'Net which doesn't
acknowledge line length.


Strictly speaking email doesn’t limit itself to 80 columns.
Much of the mail I get seems to have been composed with long lines - one
line per paragraph, and its up to the display to do the soft line wrap.
So if I shrink or grow the width of the window the individual lines
alter in length. Well, maybe. I've set Thunderbird to wrap at 79 no
matter what, but its easy to see this behavior if you use a word
processor such as OpenOffice/LibreOfice.

Oh, right, that's cos its HTML mail. EVIL!

Again, as far bask as the 1980s protocols such as
NEWS/NNTP the concatenation of the sites the message had passed
though produced lines that were of indefinite length,

Hmm, don't they follow email standards? I'm sure USENET is where we
first saw base64 encoding folded into neat lines of 76 bytes.

I'm talking about the HEADERS not the body.
A site may find out about all other sites the article has already
traversed by looking at the Path: header field. This header contains a
list of all systems the article has been forwarded by in bang path
I'm not talking about 'source based routing' as with UUCP, though that
might apply a well. No, I'm talking about Henry's code in C-News that
read lines of indefinite length with NO BUFFER OVERFLOW.

Even the linux kernel likes the 80 character limit:

"The limit on the length of lines is 80 columns and this is a strongly
preferred limit."


That's about readability of the sources. The kernel itself has no such

Anyway, we're way OT.

Getting there ....

In view of the stupidity of the majority of the people, a widely held
opinion is more likely to be foolish than sensible.
--Bertrand Russell, Marriage and Morals
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups