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

[Tuomas Lukka]

> 
> ===================================================================
> ``xu_link_space--benja``: Put xanalogical links into the same space
> ===================================================================
> 
> 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, 

Which places?

> or
> to have a Storm pointer reference in the main space that allows
> loading the link space.

Why is this a problem?

> 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.

This is true.

> 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.

This is also true.

I think the two latter reasons are much better than the first one;
you might want to concentrate more on them.

> 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. 

Ok, agreed.

> 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.)

Hmmmm... This sounds like a really bad kludge. Any other way?

> 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.

Ted did have in his designs flags and attributes of cells...

        Tuomas