[comp.lang.icon] ansi routines

goer%sophist@GARGOYLE.UCHICAGO.EDU (Richard Goerwitz) (06/10/91)

Is anyone using the IPL ansi.icn library?  If so, I have a set of
compatible routines I'm trying to test out that will run under a
wider variety of platforms.  Anyone who wants to try them out, pleas
drop me a line.


   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer

shafto@EOS.ARC.NASA.GOV (Michael Shafto) (06/11/91)

Richard --

Yes, and I would be interested in testing your new improved version.

Mike

goer@ellis.uchicago.edu (Richard L. Goerwitz) (06/11/91)

shafto@EOS.ARC.NASA.GOV (Michael Shafto) writes:
>
>Yes, and I would be interested in testing your new improved version.

I wasn't clear enough:  My version is expanded (in the sense that
the ANSI interface can be applied to non-ANSI terminals).  I'm not
sure that it really constitutes an improvement.  Anyway, I haven't
had enough requests to consider posting, so I reiterate the offer
of sending them to anyone who wants to use them.

It's really a good idea to used generalized I/O for any programs
written in Icon, since Icon runs on so many platforms.  These new
ANSI routines have the advantage of working as-is on DOS platforms
with the ansi.sys driver installed.  The escape codes are hard-
coded in.  If, however, you want to run a program written with
them on, say, a UNIX box, the routines are structured so that you
can just link in the Icon termlib-type routines I posted some time
ago here (and which I have copies of I'll gladly pass on; I use
them constantly, and can't seem to stop revising them).  There is
also a library of high-level routines I wrote for use in conjunc-
tion with the termlib-type library.  These can also be linked in
with the revised ANSI screen control library.  The routines in
the revised library sense what it is you've linked in, and make
use of whatever you've made available (if in fact they need any
additional help - which they don't in DOS environments).

The idea is to have a generalized library of screen functions
that DOS users can blindly use, which take up minimal space, are
fairly fast, and which can be augmented for Unix without having
to change a single line of code (and without requiring the user
to have to do worry about setting up any sort of database).  Ad-
mittedly, these routines are a bit more spartan than the iolib
routines I posted a while back.  They are a lot more hassle-free,
though, and they cover pretty much all the basic functions that
people doing visually oriented programs would need.

You know, speaking of screen control, I wrote a set of Icon-based
windowing routines some time ago.  They let you open up virtual
screens, move them around, create borders, overlap them, write to
any screen (aka window), and have the portion showing on the stan-
dard screen be correctly updated (if in fact any was showing).

The reason I didn't post them is quite simple:  Although they were
fast enough for most purposes, they ate up way, way too much mem-
ory.  I implemented the concept of a displayable area with the
Icon equivalent of a 2d array (a list of lists), and then tried
various ways of representing squares in that array (integers, rec-
ords, etc.).  The trouble was that I wanted them to be pointers
to window structures created by the user.  Not having this facility,
I had to use records, which used up just too much space.

It *almost* worked.  :-(  I guess I wish that Icon had some sort
of explicit pointer data type.

-- 

   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer

nowlin@isidev.UUCP (06/15/91)

 > From: Richard L. Goerwitz
 > 
 > shafto@EOS.ARC.NASA.GOV (Michael Shafto) writes:
 > 
 > > Yes, and I would be interested in testing your new improved version.
 >
 > I wasn't clear enough: My version is expanded (in the sense that the ANSI
 > interface can be applied to non-ANSI terminals).  I'm not sure that it
 > really constitutes an improvement.  Anyway, I haven't had enough requests
 > to consider posting, so I reiterate the offer of sending them to anyone who
 > wants to use them.

We (ISI) would like to see the expanded ansi routines to compare with the
beta version of our Enhanced Character Interface (ECI).  This is a
character based windowing interface implemented in Icon at the C level.  We
demonstrated a prototype at the last ICEBOL conference.

 > It's really a good idea to used generalized I/O for any programs written in
 > Icon, since Icon runs on so many platforms.  These new ANSI routines have
 > ... 
 > The idea is to have a generalized library of screen functions that DOS
 > users can blindly use, which take up minimal space, are fairly fast, and
 > which can be augmented for Unix without having to change a single line of
 > ...
 > You know, speaking of screen control, I wrote a set of Icon-based windowing
 > routines some time ago.  They let you open up virtual screens, move them
 > ... 
 > The reason I didn't post them is quite simple: Although they were fast
 > enough for most purposes, they ate up way, way too much memory.
 > ...
 > I guess I wish that Icon had some sort of explicit pointer data type.

ISI's Icon for 386 UNIX will provide an interesting interface to the
standard curses/eti (Extended Terminal Interface) functionality introduced
to UNIX with SVR3.2.  We think many programs can benefit from a screen
oriented user interface so we came up with ECI.  It has the ability to open
multiple "text", "menu", or "form" windows.  Window borders, titles, sizes,
etc. all have defaults but can be explicitly specified by the user.
Everything happens at the C level so it's fast and pointers aren't needed.

Programming with ECI is done at the appropriate level in Icon.  For
example, the code to create a menu looks something like this:

   choices := ["bank","savings and loan","mattress"]
   smenu   := wcreate("menu","Choose a Savings Plan",choices)
   choice  := post_menu(smenu) # displays the menu window and
                               # returns the user's choice
   unpost_menu(smenu)          # erases the menu

We're interested in feedback on whether this functionality should be made a
standard part of our Icon or an add-on.  The reason for making it an add-on
is because all this doesn't come for free.  The size of iconx at least
doubles.  Any and all comments are appreciated.  Thanks.

  --- ---
   | S | Iconic Software, Inc.  -  Jerry Nowlin  -  uunet!isidev!nowlin
  --- ---

goer@ellis.uchicago.edu (Richard L. Goerwitz) (06/15/91)

In article <9106142244.AA22433@relay2.UU.NET> nowlin@isidev.UUCP writes:

>We (ISI) would like to see the expanded ansi routines to compare with the
>beta version of our Enhanced Character Interface (ECI).  This is a
>character based windowing interface implemented in Icon at the C level.  We
>demonstrated a prototype at the last ICEBOL conference.

They are very minimal ANSI routines, and in fact are completely compatible
with the ansi.icn file included in the IPL.  I've been accumulating enough
requests that I've decided to post the routines.  They are appended below.

>[Stuff on ECI - a great idea - deleted, as also some examples illustrating
>high-level, generalized screen control.]
>
>We're interested in feedback on whether this functionality should be made a
>standard part of our Icon or an add-on.  The reason for making it an add-on
>is because all this doesn't come for free.  The size of iconx at least
>doubles.  Any and all comments are appreciated.  Thanks.

I'd vote that that you not include it as part of the standard package.
First of all, is it OS-specific (only for systems with SysVr3 curses)?
If so, then it definitely needs to be separated out.  I hear of inter-
faces being built for X, and perhaps for other visual environments, in
addition to ECI.  I guess I'd like to see them all built as add-ons.
What would be really nice is if everyone kept in touch, and attempted
to use a similar approach.

-Richard


----------------------------- ansi2.icn ------------------------------
############################################################################ 
# 
#	Name:	ansi2.icn
# 
#	Title:	ANSI-based terminal control library
# 
#	Author: Ralph E. Griswold and Richard Goerwitz
# 
#	Version: 1.1 (pretty much untested)
# 
############################################################################ 
# 
#     This package of procedures implements a subset of the ANSI terminal
#  control sequences.  The names of the procedures are taken directly from
#  the ANSI names.  If it is necessary to use these routines with non-ANSI
#  devices, link in iolib.icn, and (optionally) iscreen.icn as well.  Use
#  will be made of whatever routines are made available via either of these
#  libraries.  Be careful of naming conflicts if you link in iscreen.icn.
#  It contains procedures like "clear" and "boldface."
#
#	 CUB(i)		Moves the cursor left i columns
#	 CUD(i)		Moves the cursor down i rows
#	 CUF(i)		Moves the cursor right i columns
#	 CUP(i,j)	Moves the cursor to row i, column j
#	 CUU(i)		Moves the cursor up i rows
#	 ED(i)		Erases screen: i = 0, cursor to end; i = 1,
#			   beginning to cursor; i = 2, all (default 2)
#	 EL(i)		Erases data in cursor row: i = 0, cursor to
#			   end; i = 1, beginning to cursor; i = 2, all
#			   (default 0)
#	 SGR(i)		Sets video attributes: 0 = off; 1 = bold; 4 =
#			   underscore; 5 = blink; 7 = reverse (default
#			   0)	
#
#     Note that not all so-called ANSI terminals support every ANSI
#  screen control sequence - not even the limited subset included in
#  this file.
#
#     If you plan on using these routines with non-ANSI magic-cookie
#  terminals (e.g. a Wyse-50) then it is strongly recommended that you
#  link in iolib or itlib *and* iscreen (not just iolib or itlib by
#  itself).  The routines WILL WORK with most magic cookie terminals;
#  they just don't always get all the modes displayed (because they
#  are basically too busy erasing the cookies).
#
############################################################################ 
#
# links: iolib or itlib, iscreen (all optional)
#
# see also: ansi.icn
#
############################################################################ 

# For DOS, or any system using ANSI-conformant output devices, there
# is no need to link any routines in.

# For Unix systems, you may choose to link in itlib or iolib, and (if
# desired) iscreen as well.  Some of these may be in the IPL.  You can
# get any that aren't from Richard Goerwitz (goer@sophist.uchicago.edu).

# link iolib, iscreen

procedure _isANSI()
    static isANSI
    initial {
	if find("MS-DOS",&features) then {
	    isANSI := 1
	} else {
	    if type(getname) == "procedure" then {
		if find("ansi",map(getname())) | getname() == "li"
		then isANSI := 1
		else isANSI := &null
	    } else {
		# We'll take a chance on the user knowing what he/she
		# is doing.
		isANSI := 1
		# If you're not so confident, comment out the following
		# line:
		# stop("_isANSI:  you need to link itlib or iolib")
	    }
	}
    }
    return \isANSI
end

procedure CUD(i)
    if _isANSI()
    then writes("\^[[",i,"B")
    else {
	iputs(igoto(getval("DO"),i)) | {
	    every 1 to i do
		iputs(getval("do")) | stop("CUD:  no do capability")
	}
    }
    return
end

procedure CUB(i)
    if _isANSI()
    then writes("\^[[",i,"D")
    else {
	iputs(igoto(getval("LE"),i)) | {
	    every 1 to i do
		iputs(getval("le")) | stop("CUB:  no le capability")
	}
    }
    return
end

procedure CUF(i)
    if _isANSI()
    then writes("\^[[",i,"C")
    else {
	iputs(igoto(getval("RI"),i)) | {
	    every 1 to i do
		iputs(getval("nd")) | stop("CUF:  no nd capability")
	}
    }
    return
end

procedure CUP(i,j)
    if _isANSI()
    then writes("\^[[",i,";",j,"H")
    else iputs(igoto(getval("cm"), j, i)) | stop("CUP:  no cm capability")
    return
end

procedure CUU(i)
    if _isANSI()
    then writes("\^[[",i,"A")
    else {
	iputs(igoto(getval("UP"),i)) | {
	    every 1 to i do
		iputs(getval("up")) | stop("CUU:  no up capability")
	}
    }
    return
end

procedure ED(i)
    /i := 2
    if _isANSI() then {
	writes("\^[[",i,"J")
    } else {
	case i of {
	    0:  iputs(getval("cd")) | stop("ED:  no cd capability")
	    1:  stop("ED:  termcap doesn't specify capability")
	    2:  {
		if type(emphasize) == "procedure" then clear()
		else iputs(getval("cl")) | stop("ED:  no cl capability")
	    }
	    default:  stop("ED:  unknown clear code, ",i)
	}
    }
   return
end

procedure EL(i)
    /i := 0
    if _isANSI() then {
	if i = 0
	then writes("\^[[K")
	else writes("\^[[",i,"K")
    } else {
	case i of {
	    0:  iputs(getval("ce")) | stop("EL:  no ce capability")
	    1:  stop("EL:  termcap doesn't specify capability")
	    2:  stop("EL:  try using CUP to go to col 1, then EL(0)")
	    default:  stop("EL:  unknown line clear code, ",i)
	}
    }
   return
end

procedure SGR(i)

    static isISCR
    initial {
	if type(emphasize) == "procedure"
	then isISCR := 1
    }

    /i := 0
    if _isANSI() then {
	writes("\^[[",i,"m")
    } else {
	case i of {
	    0: (\isISCR, normal()) | {
		every iputs(getval("me"|"so"|"ue"))
	    }
	    1: (\isISCR, boldface()) | {
		iputs(getval("md"|"so"|"us"))
	    }
	    4: (\isISCR, underline()) | {
		iputs(getval("us"|"md"|"so"))
	    }
	    5: (\isISCR, blink()) | {
		iputs(getval("mb"|"us"|"me"|"so"))
	    }
	    7: (\isISCR, emphasize()) | {
		iputs(getval("so"|"me"|"ue"))
	    }
	    default:  stop("SGR:  unknown mode, ",i)
	}
    }
   return
end
-- 

   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer