Re: [zzdev] Re: [zzdev] Re: [zzdev] :zz: Operations defined for ZZTP ( zzOplists.D8

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> >3. CHUG*,  SHEAR* etc are not defined clearly enough here. We talked about
> >you defining  them about a year ago but you never got back to us on that,
> >unfortunately.
> 
> Right.  Well, I think they're clarified by now, but I can only get out
>  about one memo a month ...   Sigh.

Our problem is not really the different versions of Java but this...

> >>   whichcur CURSORFORK  [  creates a new first-class cursor in the same
> >> location  ]
> >>  
> >>   whichcur KILLCURSOR [  evaporates the current cursor  ]
> >>  
> >>   whichcur SUBCURSOR   [ creates a subordinate cursor managed by another
> >> cursor, to be used in some sub-operation ]
> >>  
> >>   whichcur KILLSUBCURSOR   [ evaporates the current subcursor, but only if
> >> it is a subcursor in some current set.  Killing the last subcursor of a set
> >> is effectively a return-from-subroutine to a parent cursor above ]
> >
> >These are rather unclear as well, as you  have not properly defined  cursors
> >and subcursors yet.
> 
> Subcursors I know are new.  

Yet you don't anywhere say what they are,  except "managed by another cursor".
That's completely incomprehensible; you need to put in more context.

> I'm not sure what definition you want
>  of cursors.  I know the geometry of cursor-wheels and whatnot
>  that I presently have in mind, but I don't have any metaphysical
>  or mathematical definition ...

I just want to know which things you include in the concept of cursor
and which you exclude. Does the cursor include the "current set of dimensions"
or not? Does it include some marks associated with that particular cursor.
Etc.

> >> == VIEW OPERATIONS
> >> 
> >>   whichcur RASTER  [ sends out the current raster list, somehow
> >> linearized-- how linearized to be dealt with later ]
> >>   
> >>   whichcur REFRESH [ sends out the current raster list, with contents,
> >> somehow linearized-- how linearized to be dealt with later ]
> >
> >This means that the back-end has to be completely aware of any views.
> >I don't  think  that's  necessarily a good thing.
> 
> Correct in the best cases.  But if you're talking to a dumb
>  screen, it does.

A dumb screen wouldn't understand a raster list or zz ops anyway.

	Tuomas