Re: [zzdev] Nile

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> > Oops, of course. I completely forgot about that. (They're not more than
> > an intermediate, though: you can't see where something came from, just
> > all other places where it is. But that might suffice for the moment.)
> 
> Hmm, isn't that the whole point of transclusions?

No? You want to be able to see where a quotation is from, for example?
(Or, follow the way back some text went through your document?)

> > Could you do that job sometime? Because I'm not familiar enough with GZZ
> > spans, so it would take me much longer to do that. (I'd think a two
> > window structure would be best, where you transclude the selection in
> > one window to the other win, plus an action that is able to jump to
> > other instances of the same span?)
> 
> I will but the jumping to other instances part is trickier.
> 
> That's because I'd like to have that as a space-level mechanism and
> figuring the right structure to represent span overlap is ... interesting.

*g*

Well, to get the thing usable, we could start with jumping between the
different occurences of a single character -- that would save us the
headache of span overlap for the moment.

> > So, a spacepart which deducts the substream from the two markers?
> 
> That's certainly possible. Still have to think about it for a while.
> 
> The basic question is, I think, whether we really want to duplicate those
> cells in the structure or have a real, simple, unmodifiable reference in the
> place where the stuff was included in. Because that way the structure of
> copies would be clearer to the user.

If we have a spacepart which interprets the reference, we still have the
plain structure which is interpreted by the spacepart. I think we want
to be able to view both.

> > Hmmm... does that mean the d.n dimensions would be shown with
> > vanishing-like views in this context? I.e., you could seamlessly
> > integrate d.n connections with Nile streams etc.?
> 
> What is d.n?

d.1, d.2, d.3, d.4, d.5...

> > > This way, moving from between the text stream and the calendar could
> > > be fluid.
> >
> > And near the variable I include in a Nile stream, I could show the
> > program where that variable comes from, and vice versa... oh wow. ;o)
> > I've always seen gzz inclusion as a connection you can follow both ways,
> > but I never realized that it's not at all that hard to program a general
> > system that shows these connections!
> 
> Right. The atoms and molecules and ice-cream layers that Ted likes to talk
> about are beginning to show up.

*g* I really look forward to hear him talk in person sometime...

> > > Ok, except for terminology we are along the same lines here. Except
> > > that the applitudes will not use ZObs, but rather, simply have their
> > > own dimensions which are associated to that applitude somewhere else.
> >
> > Again, I fear we're running into namespace problems here. Any plans on
> > how to prevent that?
> 
> well, by having dimensions be cells and the dimensions used in a particular
> applitude would then be in that applitude's definition.
> 
> ZigZag and structure means that we don't really need to use naming anywhere.
> OTOH, having names is very convenient for humans...

If we use cells as dimensions, of course. Do you already have solutions
for the obvious problems? :)

But I really like this version better. E.g. because it means dimensions
can have different names in different languages.

(Which brings me to i18n... ugh, I really have to tackle that sometime soon)

> > > Now the question remains of whether it's possible to make it efficient.
> >
> > Hm -- should be, because a cell could know the applitudes it belongs to,
> > by checking its connections on the respective dimensions while being loaded.
> 
> A cell can be in several applitudes.
> 
> If I have an anchor in the text that I've connected to one applitude and connect
> it to another, that would have to be noted somewhere.

That's why I used plural for "applitudes." ;o) And when you connect a
cell in a different applitude, that's noted in the cell object.

Or do you think that'd cost us too much memory?

-b.