editing trees

7.22: adde/gui/editing trees:
. how do we sync a tree with the editor's
textual representation of the tree?
as lines are added to the text,
the line numbers change
but the tree nodes never change
without needing to rebuild the text too.
. there are 3 objects at work here:
the tree, the array of strings,
and an intermediate that's like wordcode,
in that it's a string of ptrs to tree nodes
that are in turn printable as words or symbols .
. at each line we have a ptr to the tree
but a line serves several nodes .
9.5:
. the ptr heading each line of text
is pointing to the root of the subtree
that is on that line .
. if we change that line or insert lines below it,
those changes are happening to that subtree
indicated by the root node;
therefore, to reflect any changes to the text,
we need reparse only that subtree ... ?!
actually,
there are 2 cases of tree:
# prefix:
. in the presentation of a folder system,
all the child nodes are below the parent's .
. that is a very simple and easy case,
as was expected above .
# infix:
. in the presentation of math formulae,
and programming code, such as adda,
we have expressions like (a+b),
where if all these expression tree nodes
are on separate lines,
then you see the root in the middle of the page,
not at the top . a further complication is that
the same text line can be representing
2 different subtrees: eg,
line#1: a*
line#2: b + c*d;
. in that example, line#1 and #2
share pieces of subtree#(a*b),
and line#2 represents parts of 2 subtrees,
so if line#2 is edited,
then there are possibly 2 subtrees to reparse .

9.5: the real-time complication:
. the text editing has to be very responsive;
therefore, we can't map each word
to a subwindow corresponding to a subtree;
instead, we have to let the user edit plain text,
and then have some way of mapping
text changes back to tree changes .
. to minimize reparsing,
we have to map character positions to tree nodes,
and then track how character modifications
have effected our text-to-tree map .

9.5: typical conditions simplifying:
. one simplifier provided by typical conditions
is tree size limits:
the expression trees that are complicated,
are usually only a few lines long;
they are separated by sequence operators,
or list delimiters .
. in the case of programming,
the effect of one tree change
can effect the parsing of another;
because, a symbol's meaning can change
either by deleting or creating a declaration
which will have a scope beyond the current tree
extending throughout the enclosing declare block .
. if there's a decl'deletion,
then we have to notice what type was being declared;
because, sometimes the type is determining
how we parsed the expression trees
that were surrounding that symbol;
eg, a declaration tells us whether or not
a symbol can be used as an infix operator,
or whether it was an atom or a function .
. much of syntax is only allowed for
certain types of symbols and not for others;
so, can we find a symbol of the same name
in an enclosing scope, and of the same type,
or a type change that won't matter ?
we may have to reparse the entire enclosing scope .
. if there's a decl'creation,
we must ensure that this scope
doesn't already declare this symbol .
. if there's a decl'modification,
we must ensure that type change doesn't matter,
else we have to reparse the entire enclosing scope .