[Gzz] ``xu_link_space--benja``: Put xanalogical links into the same space

[Benja Fallenstein]

New PEG; please comment. -b.

===================================================================
``xu_link_space--benja``: Put xanalogical links into the same space
===================================================================

:Author:       Benja Fallenstein
:Date:         2002-11-14
:Revision:     $Revision: 1.1 $
:Last-Modified: $Date: 2002/11/14 16:35:36 $
:Type:        Architecture
:Status:    Current


Xanalogical links are currently stored in a different space,
because we do not want the cells that make up the link
to be shown as transclusions. However, this introduces
additional complexity, such as the need to know about
two different ``Space`` objects in many places, or
to have a Storm pointer reference in the main space that allows
loading the link space.

Additionally, links are not the only place where we do not
necessarily want transclusions to be shown. Other examples
include marking spans to make links (we do not want
the mark cells to show), an applitude to render textured
vector graphics (we do not want the cells containing
the textures to show), and so on. Whenever a cell's contents
are not actually 'user contents' but are used in the
lower-level fabric of the system, we don't usually want
them to show up as transclusions.

Finally, links should be first-class members of a space,
available for connections. For example, it should be possible
to connect an explanation to a link (like 'this is related
because...'), which could be rendered in the middle between
the link's endpoints on the screen. It should be possible
for such an explanation to be a clone of something else
in the space etc.

Thus, I propose to put the links into the same space
and to have a more generally useful way for avoiding
to show them as transclusions. As for this way, for now I propose
to have a dimension ``a.hidden-transclusion``; if
a cell has a posward connection on ``a.hidden-transclusion``,
it will not by default be shown in that kind of context.
(Of course, for diagnostic views, we may want to view
such cells also.)

Notes:

- The respective applitudes creating the cells are responsible
 for putting the additional connection in.
- Often, the connection on ``a.hidden-transclusion`` will
 simply be to the cell itself, thus forming a single-cell
 ringrank. Since it doesn't matter what the connection
 is to, this is convenient.
- The ``a.`` prefix is for 'attribute,' since this
 is an attribute of a cell.

\- Benja