sourcedoc: fwSpecAdds3-D5

hide references

fwSpecAdds3-D5

===06.07.31

fwSpecAdds3:

FLOATINGWORLD SPEC FURTHER TWEAKED,

    from meetings of 26-7 July.

    Note: "FloatingWorld", "Xanadu", "ZigZag" and other names have

various trademark status, registered and unregistered.

Here are results of discussions amongst Ted, Rob and Marlene.

I regret that this may not be at our usual level of clarity, but time

is very short.

===CONTENTS: headings from below

    ===EXPLAINING THE PRODUCT

    ===WHAT THE PRODUCT IS TO BE

    ===THE HOLY GRAILS OF THE PRODUCT

    ===DEVELOPMENT SCRIPTS; CLOSING THE SCRIPTS

    =HOWEVER, WE'LL KEEP SCRIPTING

    =AND HOWEVER, PAYING USERS MAY SCRIPT

    =THE DANGERS OF SCRIPTS

    ===HYPERCAPS-- NEW CONTROL ALPHABETS

    =OUR NEW CONTROL ALPHABET, "Spatial Characters"

    ===ZIGZAG AT LAST: FZZ IS HERE

    =THE FIRST VIEW

    =NO COMMANDS YET

    ===CELLVIEW IDIO SPECS

    ===SPECIAL FUNCTIONS TO BE DONE

    =KEYBOARD FILTER ROUTINE

    =HOPSWITCH ROUTINE

    =TIMERS

    =EXECUTION DIMENSION

    ===THE KEYBOARD FILTER (KBF)

    ===SELECTIONS IN FLOATINGWORLD

    =SELECTIONS FROM OUTSIDE FLOATINGWORLD: DRAG AND DROP

    =SELECTIONS FROM INSIDE: SLICES, ETC.

    =SELECTIONS FROM INSIDE: DOCUMENTS AND TEXT BY MOUSE

    ===CELLTYPES

    ===CELL MODES

    ===CELLIDs AND CELL MOVEMENT

    =MOVING CELLS BETWEEN A USER'S SLICES

    =CLONING CELLS WITHIN A USER'S SLICES

    =CLONING CELLS TO ANOTHER SLICE

    =MOVING TO ANOTHER SLICE AFTER CLONING

    ===SLICE FUSIONS AND SPLITTINGS

    ===SLICES AND PACKAGES

    ===SLICE TYPES: DIFFERENT SLICETYPES AND VARIANTS

    =SLICE NAMING AS A CROSS-PLATFORM ISSUE

    =MULTIDOT SUFFIXES

    =SLICENAME VERSIONING

    ===SLICE TUPLES EXACTITUDE

    ===BUFFERNAME VERSIONING

    ===SLICE BACKUP ISSUES

    =OTHER DIRECTORIES

    ===THE SCENELIST: misc. points

    =LOTS OF CHANGES NEEDED

    =THE d.1 PROBLEM

    ===SWORFING: THE PROBLEM OF SWORFING CONNECTION-LINES CORRECTLY

    ===MULTIPART CELL ADDRESSING ISSUE

    =TRANSMISSION OF CELLS, POSSIBLY CONTENT

    =ORIGINS OF "SERVER/SLICE/cellID"

    ="SLICE OF ORIGIN" IS NOT USUALLY A CONCEPT.

    =SENDING NAMED SLICES BETWEEN USERS

    =CONNECTION OF SAME CELLS

    ===SCRIPTING

    =WHEN CAN WE EDIT SCRIPTS AND SEE ZIGZAG RESULTS?

    =SCRIPTING ENHANCEMENT NOW IN PLACE

    =SCRIPTS IN CELLS

    ===ZIGZAG VIEWS

    =ZIGZAG VIEWS: TO SELECT A CELL AS REFRESH CENTER

    =ZIGZAG VIEWS: WHATCHAMACALLIT

    ===OUR LANGUAGE, recently called "Gartersnake"

    =MOST FUNCTIONS RETURN LISTS EXCEPT--

    =THE MYSTERY OF PYTHON TUPLES, NOW SIMPLIFIED

    =DIMDESIGNATORS

    =NONEXISTENT DIMENSIONS

    =DIMENSION SYNONYMS

    =PYTHON TRUTH-VALUES

    =CHANGES FROM ROB'S GARTERSNAKE WRITEUP (of 06.07.15)

    =LOOP DETECTION

    ===NAMING AND RENAMING ISSUES

    =TERMS NEEDED

    =BEST NAME FOR OUR SCRIPTING LANGUAGE?

    =NEW TERM

    =MAJOR NAMING OF PARTS

    =SCENELIST DIMENSIONS-- RENAMING THEM, REALLOCATING THEM

    =THE STRANDCHUNK ISSUE

    ===ISSUES UNRESOLVED

    =(HYPERTIME FOR ZIGZAG UNDO etc)

    =AUDIO

    =LINK-LOCKS

    =VINKS

    =CAPS-LOCK TIMEOUT

    ===GLOSSARY FOR THIS DOCUMENT

===EXPLAINING THE PRODUCT

Aside from the technical problems, we have a tremendous issue: how to

explain this system to people, and its parts. FloatingWorld has many

levels and isn't like anything else. The next few paragraphs are my

latest attempt.

    FloatingWorld is a Quasi-Operating System (QOS). While it is not

an actual operating system (with low-level drivers), its levels

correspond roughly to what users see in an operating system of today.

    The internal mechanism is ZigZag(R), a data and computing engine.

This corresponds roughly to the guts of the conventional operating

system. Most users will not go into the ZigZag level, just as most

users do not go into the operating-system level of Windows or the Mac.

    Corresponding to conventional windows, we have three-dimensional

Scenes and Shows.

    Corresponding to conventional applications which do not connect to

each other, we have Applitudes (which do connect to each other).

These include LifeDimensions (which you may use to keep track of much

of what you do.) Users may create views, or "skins," which change the

ways these are seen.

    Corresponding to conventional database and spreadsheet, we have

data arrangements in ZigZag (zzstructures). Like spreadsheet, this

offers light numerical programming.

    Corresponding to conventional files, we have "slices"

--interpenetrating packages of zzstructure.

    Corresponding to conventional document viewers-- notably, Adobe

Acrobat-- we offer CosmicBook, which stores documents in Outspread

format, with as many links showing as you want.

    (Buffering the scenes, we also have zzstructure packages.)

    For those who reach the ZigZag layer, there is Geography (layout),

Clockwork (mechanics), Plumbing (flow-- programs and flowing data).

===WHAT THE PRODUCT IS TO BE

The product, as presently defined, will have two versions--

      - the Free Reader, with editing and scripting not available to

the user. This will open documents and graphics, with links, and

allow you to read and explore them. If you pay to unlock it, you get

the second--

      - the Editor, the paid product-- a full multidocument hypertext

editor, with scripting available and full ZigZag available.

I think it best not to give direct ZigZag access in the free reader,

especially by disabling ZigZag views and Kblang operations; perhaps

not even in the early paid reader. This gives us less to maintain at

the beginning, and makes it easier to explain the system

incrementally.

===THE HOLY GRAILS OF THE PRODUCT

I believe Rob has committed to the first three of these--

Holy Grail 1

    Outspread documents with profuse transclusions and links, turnable

on and off

Holy Grail 2

    Distributable Outspread Document Package

Holy Grail 3

    Pullacross Editing

Holy Grail 4

    Network Editing, especially with audio

===DEVELOPMENT SCRIPTS; CLOSING THE SCRIPTS

In the development phase, we will be writing scripts for various

important functions.

When we build the distributable, these scripts will be transmuted--

closed up so they can't be changed, and compiled into the one unified,

monolithic program package.

Rob is checking into methods for this Rollup operation, which will

have to be done repeatedly, possibly without his help.

=HOWEVER, WE'LL KEEP SCRIPTING

Meanwhile, we will be scripting for the first package.

=AND HOWEVER, PAYING USERS MAY SCRIPT

Those who pay for the editor will get the privilege of writing their

own scripts, exchanging scripts with others, and hiring our Certified

Customizers to add scripts to their setups.

=THE DANGERS OF SCRIPTS

I want users to be informed that running a script can be every bit as

dangerous as running arbitrary programs in Windows.

===HYPERCAPS-- NEW CONTROL ALPHABETS

Based on the Keyboard Filter (below), it will be possible to create

new control alphabets comparable to shift, ctrl- and ALT-.

    - "Shift", or capitalization has been around since Charlemagne.

    - "Control characters" were put into ASCII ca. 1960, but came from

telegraphic control codes. Don't know when it was made an alternative

alphabet rather than random codes.

    - ALT was added by Microsoft to correspond to Unix (or is it just

Emacs) META.

With our Keyboard Filter, anyone can create their private control

alphabet. We will be delivering the system with one of our own--

=OUR NEW CONTROL ALPHABET, "Spatial Characters"

Based on the keyboard filter (see below), we will add our own new

distictive control alphabet to the system.

We now add: "Spatial", as in spatial-A, spatial-#.

We will use spatial characters especially to control our spatial

functions (flying around and editing in space), but they may be

assigned to any operations through the keyboard filter.

We say "spatial a" to distinguish it from "space a," a full spacebar

up and down followed by a. In the spatial alphabet, you hold down the

spacebar and type a key. Alas, you will probably have to let it up

again and press the spacebar again for successive spatial characters.

Note that spatial characters must usually be caseless, since shift-up

and shift-down may not fit the sequences we want, and Caps Lock has

its own problems. (If we want uppercase and lowercase spatial

characters, however, we can specify Spatial-Capital-A, meaning

spacebar-down shift-down A, or Capital-Spatial-A, meaning shift-down

spacebar-down A.)

===ZIGZAG AT LAST: FZZ IS HERE

While earlier builds of FloatingWorld have had robust zzstructures,

nobody could see them. Finally we have a view. Rejoicing! Finally

we can call it Fzz (FloatingWorld ZigZag).

=THE FIRST VIEW

Rob has done a first ZigZag view. It is rather like the Zzz view in 3d

    - no unifreshment, ranks go on and on repeating.

BUT

    - cells are visible cubes

    - it has transparency, as cells get further away you can see

through them (looks nice!)

     - it seems to have haze [must check]

Rob will soon improve the View.

=NO COMMANDS YET

Still no zigZag commands as yet. These are not Rob's job any more.

They must for the most part be left to the Scripting levels.

EXCEPT Rob will do-- (detailed below)

    -- Keyboard Filter routine

    -- hopswitch

    -- timers

    -- jump to d.xeq routine on cellclosure

===CELLVIEW IDIO SPECS

Part of the ZigZag specification has long been Idiosyncratic Cellviews--

    - cellviews where each cell may have its own view or picture (done

with cellcover celltype)

    - cellviews that allow different cell types to have their own views

How do the latter? When we go to a zzview where celltypes are allowed

to have their own viewspecs, where are they kept?

Answer: on a dimension like "d.mastershape", so that we can specify

    - size

    - shape

    - covercell

    - color

etc.

Rob says these are at the script level and not his problem.

===SPECIAL FUNCTIONS TO BE DONE

Rob has kindly agreed to do four special functions--

=KEYBOARD FILTER ROUTINE (explained below).

=HOPSWITCH ROUTINE (described in separate fwSpec email)

=TIMERS

This came up when I proposed to have a routine that would turn off

Caps Lock after a second or two of disuse. Rob says he can do an

"execute on timer" instruction without too much dificulty, proposing

the form

    zz.executeontimer

details to come.

=EXECUTION DIMENSION

The execution dimension, d.xeq, has long been in the ZigZag specs (and

even on the Gzz dimension list, though nonfunctional-- except that

Benja Fallenstein at one point implemented a different meaning of it

that worked quite nicely).

The execution dimension as I have designed it is a very simple way of

putting spreadsheet capability into ZigZag. It works like this:

    - when a text cell is created, ZigZag looks to see if there is a

connection +d.xeq

    - if so, jump to a routine [not now written, so a dummy

temporarily] that looks posward on d.xeq for a formula and performs

the calculation there, putting result into a cell

    - when that cell is closed, do the same check again (allowing it to chain)

    - these cells can be embedded anywhere, e.g. in spreadsheets or

printable documents, or just Around.

    - (Later: if multiple cells close simultaneously, they'll have to

stack; but we'll worry about that later.)

Rob, somewhat amused: "There are worse ways of doing it."

The only implementation it presently needs is the on-closure check and

call for routines which enclose cell text content.

===THE KEYBOARD FILTER (KBF)

The keyboard filter gives the user complete control of key functions,

including the definition of new compound keystrokes and new control

alphabets. These may be user-configured at any time.

It just does this: When a match has been found to a keyboard sequence,

a progcell is executed.

The Keyboard Filter makes ZigZag into a Reconfigurable State Machine--

'depending on how you set up the wheels,' like the Enigma.

The Keyboard Filter cannot be disabled; if the user has access to the

ZigZag level at all, it's possible to reconfigure the Keyboard Filter.

Rob sez: We can be sure (under the Wintel BIOS) that any TWO

downstrokes will be recognized in order. MORE CONSECUTIVE DOWN

KEYSTROKES CAN'T BE GUARANTEED, may even vary between keyboards.

E.g., down or up--

    - shift

    - ALT

    - spacebar

followed by Whatever.

[SEE ENCLOSED PIC]

HOW KBF WORKS: an incoming keystroke goes to the keyboard filter. If

the key matches a routine, that routine is executed. If it does not

match any routine, the string is sent back out for use as a typed

string. If there is a partway-match, the KBF routine hovers waiting

for the next keystroke.

The keyboard filter is a succession of wheels. The wheels are lists

on d.2, which are connected sideways on d.1 at specific cells. For

visualization we suggest making the wheels hierarchial, though for the

same functionality the upper wheels (higher posward on d.1) could be

broken up into separate wheels.

Each connection on d.1 is recognized as a wheelhandle, used to

distinguish the end of a comparison strip.

The operation is as follows.

    Each character typed is presented to the wheel until a match is found.

        - If an executable routine is next to it on the next wheel

+d.1, that routine is executed.

        - Otherwise, the virtual pointer of the KBF then waits for the

next character.

Stated perhaps more exactly:

KBF: (Await keystroke)

KEYSTROKE ARRIVES.

TESTLOOP

    test against current cell.

    IF MATCH GO RIGHT +D.1

        if that cell is executable, EXECUTE

        else WAIT

    IF NO MATCH

        STEP +d.2

        IF THERE IS HANDLE +d.1, EXIT WITH CURRENT STRING

        IF NO HANDLE, REPEAT TESTLOOP

For now, this will be implemented with hovering mechanism rather than

contact mechanism, since it's easier.

=WE COULD DYNAMICALLY MODIFY OR REPLACE THE WHEELS! But that's kind

of like program modification. ("Deep water," says Rob.)

=TYPETWEAK ROUTINE

A second routine needed for this is a general typetweak routine which,

when a match is found, returns with some other string.

    - if it is a preset string, it will be waiting +d.1 of the

typetweak routine.

    - if it is a string dependent on the input routine, there'll need

to be a more specialized typetweak routine.

=JAPANESE AS SPECIAL CASE OF KBF OR TYPETWEAK

We have talked of doing Japanese. If we do, we'll let the user do

input the standard way-- type Romanji, then flip through plausible

alternatives. This could be done with the KBF.

===SELECTIONS IN FLOATINGWORLD

=SELECTIONS FROM OUTSIDE FLOATINGWORLD: DRAG AND DROP

"Drag and drop" is no problem cross-platform, says Rob.

=SELECTIONS FROM INSIDE: SLICES, ETC.

To select things from inside the program-- slices to bring in, etc.--

the best thing on the table is the Hopswitch.

=SELECTIONS FROM INSIDE: DOCUMENTS AND TEXT BY MOUSE

It is now possible to select individual strings within a flying

document by mouse.

This implicitly selects a document that is in view, and a tetroid within it.

(Note that "unproject" is the computer-graphics term for the function

that does this, returning 2D or 3D coordinates (x,y,z) of an object.

This can involve intricate sorting based on the shapes of overlapping

objects.) [I don't fully get this.]

===CELLTYPES (at last becoming needed, though only a few afre needed

immediately)

    - text (default) -- CONTENT DOES NOT CHANGE WITHOUT RENAMING THE CELL

    - unbrokenspan [formerly Rob's 'strandchunk']-- PRESUMABLY

CHANGEABLE CONTENTS

    - cursor [unless hovering]

    - dimdesignator or dimkey

    - executable (Python script being first type)

    - result cell, numerical

    - hopswitch

    - compound text? [nbk06.07.26p49]

    - preflet

        (Preflets have a far-off yearning for cells in other places.

"Like most of us.")

    cover

===CELL MODES [need better term]

A cell's mode is independent of its type.

    clone

    remote clone

    clonehead [prob.not a mode]

    headcell [prob.not a mode]

===CELLIDs AND CELL MOVEMENT

[This is a resolution of our discussion which contains new material.]

A user's cellIDs are assigned in ascending order, no matter what slice

they appear in.

=MOVING CELLS BETWEEN A USER'S SLICES

A cell may be moved to a different slice with no change.

=CLONING CELLS WITHIN A USER'S SLICES

    A clone in the same slice is a plain clone.

    A clone made in another slice is a remote clone.

=MOVING A CELL TO ANOTHER SLICE AFTER CLONING

The local clones on this slice are made into remote clones, and the

remote clones in the destination slice become local clones.

===SLICE FUSIONS AND SPLITTINGS

This is principally a selection issue.

    - two slices to be fused are selected by Hopswitch; some keyboard

command fuses them.

    - in a slice to be split, the user marks the cells to go into a

different slice. Some keyboard command causes the slice to be split.

        -- preflets replace the connections where required.

        -- clones and remote clones are appropriately replaced.

===SLICES AND PACKAGES

A slice is a collection of cells and possibly content, either for

local use or transmission.

A package is a slice set up with specific pieces, portions or sections inside.

Strongly relevant: "Docupack" memo (fwSpecDocupack-D1w-- which

superseded previous version, D1x).

    I'll be further revising that memo in a few weeks.

===SLICE TYPES: DIFFERENT SLICETYPES AND VARIANTS

We want specific ("registered") slice types, somehow reflected in

their suffixes. (Not specifying suffixes now.)

Main types (not needed immediately but important to think about):

    - ZZ CELLSTRUCTURE (plain) (whether local or transmitted)

    - USER'S LOCAL CELL DIVISIONS / PARTITIONS

    - SHOWPACK / SCENEPACK / FLIGHT (fulfilled, hollow, par-filled)

    - DOCUMENT (fulfilled, hollow, par-filled)

    - DOCMOD, CHANGE (fulfilled, hollow, par-filled)

        This will be represented as a hypertime modification

(position, string, op).

    - CHAT, VOIP INCREMENT (fulfilled, hollow, par-filled)

    - JABBER EQUIVALENT

        Not literally, but we need something that implements the IDEA

of the Jabber protocol-- back-and-forth of cells and content.

    - SCENE BUFFER for current scene

=SLICE NAMING AS A CROSS-PLATFORM ISSUE

Different OSs are different about capitalization!

    Windows: A = a (you can't store Hello without replacing HELLO)

    Unix, Linux, OSX: A does not equal a, every capital combination

is a different filename.

We can't have that. WE MUST ADOPT THIS CONVENTION: Slicenames are all

lower case and that's that.

    (Unix will not accept spaces, except with special handling, so we

must avoid them.)

    (Are there any other characters acceptable cross-platform?

Windows will accept a number of funny ANSI characters, but presumably

the others will not.)

=MULTIDOT SUFFIXES

All three platforms will accept multidot suffixes.

Presumably the last suffix will be a file type, on the Windows/DOS

model, since the others will not object. Three or four letters are

best.

=SLICENAME VERSIONING

Tentative:

    name.version.slicetype

where "version" is an integer. The CURRENT version will have nothing

between the two dots.

>>>Should versioned slices have internal dates?

===SLICE TUPLES EXACTITUDE

Rob says it is important that a tuple maps unambiguously to a slice.

I do not understand this fully.

===BUFFERNAME VERSIONING

Screen buffer slices have an identity if saved. Screenbuffers will

have ascending counts in the names, if saved at all.

(Should they have internal dates?)

===SLICE BACKUP ISSUES

=OTHER DIRECTORIES

On the user's local machine there should be at least one backup

directory for saved slices, so that only active slices are seen in the

current directory.

===THE SCENELIST: misc. points

Scenelists are HARD TO EXPLAIN. Help is needed.

    Note that SCENELIST HAS NO ORDER, objects may be anywhere

regardless of how they are ordered on scenelist.

    Scenelists are composed of vunits, except where they also have a

camera position.

Hard to explain.

Perhaps some rethinking is needed.

=LOTS OF CHANGES NEEDED

We need to straighten scenelists out. PARTLY THIS IS A RENAMING PROBLEM.

Agreed: the list should be on d.2, as lists generally are.

=THE d.1 PROBLEM

We must rethink d.1, which has been overloaded. Currently d.1 is used

in scenelists for

    - comments

    - tetroids connected to their slab! (Contents of slab) [I didn't know]

    - relative positioning with regard to another object (Rob's

initiative). As presently used, d.1 moves the vunit from an arbitrary

position. It may be possible to combine this with 'd.translate',

which moves the vunit from 0,0,0.

===SWORFING: THE PROBLEM OF SWORFING CONNECTION-LINES CORRECTLY

It turns out that Lukka doesn't sworf 'em in Gzz, he just fades them

out and redraws! Fooled me.

Rob wants to do better than Gzz on this. I say that's wonderful but

not topmost priority.

===MULTIPART CELL ADDRESSING ISSUE

Rob and I have had an ongoing discussion of what address parts a cell

should have. This is really about--

    - whether the slice of creation matters

    - where cells are going after they're created, and when and how

We want to be able to recognize (and address-- that is, ask for--) the

same cell no matter where it turns up.

We've decided on four fields--

    - cellID, of course (an ascending integer)

    - slice of origin

    - username ("account")

    - servername

I forget why we want slice of origin, but in any case it's been left

there, with the proviso that you don't have to ask for it-- you can

just ask for that user's cellID/slice/server.

=TRANSMISSION OF CELLS, POSSIBLY CONTENT

Our model is a centralized service with a common addressing structure.

 And we want to make it possible for all cells to be recognized, no

matter where they have gotten to.

Some transport cells-- zzcells used to transport others-- may simply

be eradicated when they've done their job.

=ORIGINS OF "SERVER/SLICE/cellID"

This comes from the old Xanadu address (xu88), which identified all

contents (characters and links) as--

    server / account / document / position

Transposing this division to ZigZag cells,

    server,account,doct => Sharable content of cells with identified origins

For instance, a structured piece that fits into something else, such

as an editorial change in a document. That means that the origin of

each cell can be spotted and collaborations precisely sorted out.

="SLICE OF ORIGIN" IS NOT USUALLY A CONCEPT.

Each user's next cell is just the next cell, regardless of the slice

it goes into.

Slicenames of origin can be ignored and wild-carded; THAT MEANS you

can look for a given user's cell N on any slice, under the assumption

there are not two of the same ID.

=SENDING NAMED SLICES BETWEEN USERS

has been thought of as very unlikely. But then, they might do it

among themselves; or, this may turn out to be the way we package

documents up.

=CONNECTION OF SAME CELLS

For several years, it has been part of the design that for all slices

in RAM, instances of the same cell are connected-- prob. on dimension

'd.samecell' or the like.

===SCRIPTING

=WHEN CAN WE EDIT SCRIPTS AND SEE ZIGZAG RESULTS?

"Two or three days," says Rob.

=SCRIPTING ENHANCEMENT NOW IN PLACE

Scripts may be put in files

    python1.txt... python5.txt

and run with function keys F1... F5.

=SCRIPTS IN CELLS

Scripts will be in cells. They will call each other, though the exact

mechanics are not decided.

===ZIGZAG VIEWS

=ZIGZAG VIEWS: TO SELECT A CELL AS REFRESH CENTER

    cursor,index:fw.focus()

=ZIGZAG VIEWS: WHATCHAMACALLIT

On the current build,

        Rob's horizontal XXX [26p21]

        is under F1.

===OUR LANGUAGE, recently called "Gartersnake"

Functions are defined to be AS FORGIVING AS POSSIBLE, so nothing stops.

=MOST FUNCTIONS RETURN LISTS EXCEPT--

    CELL returns a tuple

    SLICE returns a tuple

    zz.value returns a string

        >>>What will we do when cells have other content types?

=THE MYSTERY OF PYTHON TUPLES, NOW SIMPLIFIED

Rob says he could use lists. But tuples AVOID MEDDLING.

He now allows

    value,value,value

    (value,value,value)

    (tuple)

as equivalent inputs to a function.

=DIMDESIGNATORS (may become called "dimkeys")

The following are allowed:

    (tuple) -- for dimdesignator cell

    (dimname)

    (-dimname)

    (+dimname)

=NONEXISTENT DIMENSIONS

Trying to use a nonexistent dimension will cause an error.

    >>PERHAPS THIS SHOULD BE CHANGED.

But

    zz.dimdesignator(d.nonexistentdimension)

returns a zero.

=DIMENSION SYNONYMS

I pointed out to Rob that allowing dimensions to have more than one

name will allow tweaking dimension names without breaking the code.

He promises to think about it.

=PYTHON TRUTH-VALUES

Just for review: any value in Python is considered 'true' except

    0

    'false' (string)

    'nothing' (string)

=CHANGES FROM ROB'S GARTERSNAKE WRITEUP (of 06.07.15)

=RINGRANK DETECTION

The function

    zz.last()

        detects a ringrank, in that it returns the same cell if it is

in a ringrank. HowEVer, that means the result would be the same if--

            - there's only one cell

            - there's only one cell but it's looped to itself, a very

different but important case

Rob will therefore put in the test

    bool zz.isringrank(cell,dim)

        to return true if ringrank, false if not.

===NAMING AND RENAMING ISSUES

We have many things to keep track of and communicate to our future

users. These need to be expressed in the best terms we can find.

This means continual reassessment of what terminology works best.

=TERMS NEEDED

We need a term for 'document change unit'-- both as sent between users

and as accumulated in the Hypertime edit list.

=BEST NAME FOR OUR SCRIPTING LANGUAGE?

Our little scripting language wraps C++ routines for calling by

Python. What call it?

"Gartersnake" is too obscure. Something more related to the aquatic

"FloatingWorld" could be good. For instance--

    UNDERSEE

    UNDERFLOW

    UNDERWHERE

    UNDERWORLD

    FLOTATION

    TRANSFLOTATION

I particularly like "underflow"-- which long ago meant a particular

computer condition, but here connotes that which is flowing under our

floating world.

=NEW TERM: "Outspread" for documents spread open in space-- open, set

up and broadly viewable. (The term "open" has many connotations in

the present document world-- open source, OpenDoc-- so we had best go

another way.)

=MAJOR NAMING OF PARTS

    - 'Scenelist' may become 'Vunit List'

    - 'Tetroid' may become 'string'

    - SCENE may refer to a combinable part (e.g. a single document)

    - SHOW may refer to a gathered combination of scenes, such as a

package of opened documents

    - "permascroll" => SOURCE (in our Python functions)-- not all

sources are permascrolls

    - dimdesignator may become 'dimkey'

    - 'zz.createfollowing' should perhaps become 'zz.createalong'.

=SCENELIST DIMENSIONS-- RENAMING THEM, REALLOCATING THEM

        d.1 for comment => d.comment or d.scenecomment

        d.1 for tetroid => d.strings ? d.containedstrings?

                    => d.flow?

                    => d.docseq? /Rob doesn't like

        d.1 for relative positioning

                    => d.relativeposition

                            Could that somehow include relative from

0,0,0? Assimilate to d.translate?

        d.represents => d.instantiate?

            (This dimension allows multiple vunits to derive from the

same origin vunit.)

=THE STRANDCHUNK ISSUE

What Rob wants to call "strandchunk"

        => consecutive span of dereferenced strand

            consecutive segment

            unbroken span

[SEE PIC nbk06.07.26p74-5]

These are portions which are

    - unbroken from their original locations

    - unbroken by currently operative link endsets

These are to be successively divided and recombined during document

sessions, as part of TransLit internal data and buffer management.

Any re-use may chew them up further.

When we stop showing anything which divided such a segment (a

particular transclusion or link), the segments will be recombined.

>>>Rob wants a new celltype for these. I suggest--

    - "consegment" (consecutive segment)

    - "unbrokenspan".

The same transcluded span has two different indices, whether it is

    - in the source document

    - in a transcluding document

(Actually it has three indices--

    - point within the span (same in either)

    - point in the original source strand

    - point in the destination strand

Thus, saith Rob, it should have two different names for referencing in

our scripting code. Fine with me, we just need to pick them. I would

suggest

    - sourceUnbrokenspan

    - destUnbrokenspan

but it's under discussion.

===ISSUES UNRESOLVED

=(HYPERTIME FOR ZIGZAG UNDO etc)

We know we want hypertime editing for documents.

The same thing for ZigZag is an open issue. I think it is the best

way to do versioning, but we have a lot of loose directions here.

=AUDIO

Rob: "To do audio properly... The more I think about it, the simpler

it should be..."

An audio library has two buffers-- one being played, one filling up.

[I presume that's for each track or strand.]

We leave this for the future.

=LINK-LOCKS

These were an important part of the 1980s design. Currently being

Thought About.

=VINKS

Vinks go way back in ZigZag history, eg for Polish Notation executable

[pic nbk06.07.27p8].

Whether to include them soon is a question.

=CAPS-LOCK TIMEOUT

Very desirable.

===GLOSSARY FOR THIS DOCUMENT

comparison strip

    set of consecutive cells +d.2 in the keyboard filter, to be

compared to an incoming keystroke.

contact shoe

    cell connected to cell for a "contact" ZigZag function.

hovering function

    function accomplished without an actual ZigZag connection or contact shoe.

hypercap

    new special alphabet made possible by Keyboard Filter.

local clone

    clone which is not a remote clone; plain clone.

operative clink, currently operative clink

    a clink which is presently recognized as in place on a document.

outspread document

    document spread open in space-- open, set up and viewable, with

links and transclusions turnable on and off.

package

    a slice set up with specific pieces, portions or sections inside.

plain clone

    clone which is not a remote clone; local clone.

posture, document posture

    how a document is arranged and shown.

rollup, script rollup

    freezing scripts into a compiled version (method undecided) so

they are user-inaccessible. This will have to be done repeatedly.

show

    a gathered combination of scenes, such as a package of opened documents.

slice (official definition)

    a collection of cells and possibly content, either for local use

or transmission.

strand

    a sequential part of a translit document.

transport cells

    zzcells used to transport others. These may simply be eradicated

when they've done their job.

typetweak

    function of the keyboard filter that changes an input string. It

may either have a preset string to output or create something more

intricate.

wheelhandle

    a cell attached negward from a wheel, providing access to the

wheel; may be used to demarcate a section, such as a comparison strip.

—30•–

raw

span:

References

There are no documents that refer to this sourcedoc.