[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Nile
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: [zzdev] Nile
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Mon, 11 Dec 2000 01:36:06 +0100
- Cc: zzdev@xxxxxxxxxx
- References: <20001209043511.B17413@xxxxxxxxxxxxxx> <3A33A557.31FE4891@xxxxxx> <20001210185537.D15044@xxxxxxxxxxxxxx> <3A33DE1D.375C90A6@xxxxxx> <20001210224318.A17858@xxxxxxxxxxxxxx> <3A34009B.FB990E0@xxxxxx> <20001211015201.E18012@xxxxxxxxxxxxxx>
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.
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?