From: penev@venezia (Penio Penev)
Subject: Re: What's wrong with screens (Re: Documenting)
Organization: Rockefeller University
Date: Wed, 27 Jan 1993 04:01:53 GMT
X-Newsreader: TIN [version 1.1 PL6]
Reply-To: penev@venezia.rockefeller.edu
X-Posted-From: venezia.rockefeller.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

Nicolas Tamburri (nick@sw.stratus.com) wrote:
: penev@venezia (Penio Penev) writes:
: > Chuck Eaker (eaker@ukulele.crd.ge.com) wrote:
: > : However, the insert commands in typical Forth block editors
: > : usually cause a number of characters (equal to the number of
: > : inserted characters) at the end of the line or the end of the
: > : block to be discarded. This is not true of file based editors.
: > : I don't especially care for this block editor behavior.
: > : It's an implementation quirk that requires attention, and, in
: > : the old days, often distracted me from the real work I was trying
: > 
: > I avoid data loss by pressing the key for UNFLUSH, which copied the
: > current screen to a safe location (screen 0) and re-reads the block
: > from disk. I have rarely been unhappy about this.
: 
: I'm pleased to hear that you have found a way around this limitation with
: screens/blocks.  Unfortunately I've never heard of UNFLUSH, so I don't think
: it's a standard word.
: 

No, this is not standard and is implementation specific. Since I'm
stuck with a particular implementation, I've been using it across
many platforms without touching. Although the point of Nickolas was
about principles, rather than workarounds, I'll post the code for the
sake of completeness. Note, that it depends on the mechanism of the
linking of block numbers with buffers in memory. It relies on changing
the block number of the buffer with the corrupted data.

PREV holds an offset to the number of the most recently accessed block.
IDENTIFY  marks the newest buffer ( in PREV) with the block
   number from the stack, with  OFFSET  added.
s d COPY  copy block s to block d .

: IDENTIFY ( n)  OFFSET @ +  PREV @  PREV +  4+ ! ;   
: (COPY) ( s d)   SWAP BLOCK DROP  IDENTIFY  UPDATE ;
: COPY ( s d)  FLUSH (COPY) ;
: RECOVER   SCR @  0 (COPY)  DISPLAY ;

Well, as I see I've name this word RECOVER, rather that UNFLUSH. This
was too long ago.  DISPLAY is the equivalent of SCR @ LIST in the
screen oriented editor.

: One of the problems with this whole discussion is that when someone brings up
: a shortcoming in screens, those who use screens have come up with a nifty way
: of getting around the shortcoming, or the imaginitive ways they have for organizing
: their source etc.    I've actually found some of these messages informative (esp.
: the the messages long ago from E. Rather and Dick Miller, which were eye openers
: for me.)  But this issue is about fundamental concepts in the language,  not
: about how various implementations give you work arounds for screens' limitations.

Everything has limitations. The processor has limitations, the
technology has limitations, the human biology has limitations, the
speed of ligh has limitations. The questions is what are the
advantages of limiting Yourself. You loose the ability do do something
efficiently (or at all), but get the ability to do other things
faster. The judging is a matter of balance.

: Not one block proponent has yet to address the issues of interoperability with
: other system tools and utilities.  The only argument that comes close is "write
: your own, it's not that difficult in Forth."  I for one don't have the time to
: write my own applications, much less rewriting existing tools.  I refuse to rewrite
: GNU emacs in Forth, and I refuse to use a more limited editor to write my Forth
: code.  I shouldn't have to, and I will not choose a Forth that forces me to.

I use GNU emacs to write these lines. It has its virtues. But if I
wanted to write a FORTH-major-mode, It would have to mimic my FORTH
editor. So why bother? You can program in Elisp, You can do it in
FORTH. If I used emacs, I'd add another layer of complexity (interacting
between FORTH and Emacs) without gaining functionality. And of course
my FORTH editor's source is _much_ more manageable than Emacs'es
source. In general, I use a text file editor for text files and a
program editor for program files. Both tasks are _very_ different from
each other.

: If Forth's vendors wish to survive, they must address this issue;  not adaptability,
: (Forth is already that,) but interoperability.  [I'm sure Forth will survive,
: because even as I write, someone is writing their own version, rather than getting
: something useful done (like me :-)]  To me this essentially means 3 things:
: link foreign libraries,  provide calling mechanisms into the OS directly and
: coexist with the file system.  Happily, most Forth systems I've seen are moving
: in this direction.  Vendors know the value of providing these functions.  (The
: market has chosen, as Elizabeth Rather would say.)

Yes, I use all of these ( foreign libraries, calling mechanisms into the
OS, file system support). On one system You have to talk to a UART, on
another to a robot arm control register, and on UNIX You have to talk
to X terminals. For everything You build a little lexicon with the
interface and do Your job. You treat X terminal like external devices
with their own copntall language. What's the problem?

-- Penio.