New FORMAT Features

[ELIOT%cs.umass.edu@CSNET-RELAY.ARPA]

   From: Rem@imsss
   ELIOT's proposed clear-to-EOL is ambiguous for bitmapped displays.
   Do you clear a swath from the bitmap equal in height to the current font
   height on the current line?

I don't think there is any reasonable alternative.  You might want
text and graphics to be treated as separate planes that don't affect
each other, but CL doesn't have any graphics capacity anyhow.

   (What is the current font if you have just done a cursorpos without
   printing anything?)

The current font is the font that would be used to print the next
character.  Actually font changes are not really supported by CL,
so this is moot.  Printing a character with a non-zero font field
doesn't nescessarilly change the font, does it?  Does any existing
implementation use the font bits of a character to do anything like
this?

   Or do you clear only text that is 
   exactly on the same line in the same font and not text from
   neighboring lines that slightly overlaps the current line?

That would seem bizare, since presumably you want newly draw characters
to be readable.  

   Perhaps ELIOT
   wants this feature only for character-only displays or other devices
   that support only fixed-width fixed-height fonts in character arrays with
   non-overlapping character positions, or any window that is emulating a
   printing terminal with no graphics or cursor positionning (i.e. maybe
   cursorpos and erase-eol are mutually exclusive on bitmapped displays)?

Cursorpos and erase-eol are not mutually exclusive.  They interact in a
funnny way if variable sized fonts are used, but that involves using
non-CL features.  A variable *width* font is OK if the cursorpos operation
is defined in terms of the width and height of the SPACE character.
(Required to be non-zero because of this.)  You lose if you change
from a 12 point to a 10 point font and expect line three to be in
the same place.  All of these features work together if you don't
change fonts, which you can't currently do in CL, and they can work
together anyhow if you are careful to leave enough space around
everything.

I think bit mapped displays are the only way to use a picture tube
(I own a Macintosh and no TV) but I am also concerned about the use
of dialup lines.  I think it is a real shame that no one has made
ZMACS work over the chaosnet or on dialup lines.  Perhaps we should
add enough primitives to CL to support the implementation of a
portable screen editor (scroll-region and insert-delete character.)

    
   Actually I'd like to see somebody propose a simple set of user-interface
   primitives that handle all usual kinds of terminals/displays with and
   without multiple windows/panes.

I would too.  I would rather see a Flavor system and an error system
and an iteration facility (loop macro).  I think this simple set of 
features does most of what we need inexpensively.

   ELIOT's proposal is merely deficient, 
   not in the right direction, probably...