Re: [zzdev] Nile

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> On Sun, Dec 10, 2000 at 04:46:31PM +0100, Benjamin Fallenstein wrote:
> > The one thing I would like to see soon is cloning (and once we have
> > versioning&pull-outs, transcopying) of part of a Nile stream.
> 
> By cloning, do you mean active or passive copies? This might be easiest
> handled by a mechanism like below where it's not copied but rather
> used as an object inclusion from the other place.

Active copies, i.e. when you change the copy, the original changes. I'd
call passive copies transclusions if you can follow them back, and
copies if you can't. (Transclusions we should probably postpone until we
have general versioning, because we can build on the unified basis then,
and copies are trivial.)

> But this has problems with placing the cursor...
> 
> So far, all our views are nonhysteretic, i.e. given the cursor location,
> dimensions and parameters the result is always the same. Placing the
> cursor on some other part of the text would jump there and going back
> would be difficult. This opens an interesting can of worms...

I've tried to address them back in my "thing" draft from June or July
with a cascading (recursive) cursor mechanism. However, we might be able
to get away more easily here if we let the cursor point to the cell
which represents the substream (aka handle), and interpret the cursor
offset relative to the substream (cursor offset 8 means the 8th
character in the substream). This doesn't get out of bounds if we
introduce a spacepart that actually takes the whole content of the
substream and makes it the content of the handle.

Or we could make a spacepart that actually mirrors the substream in the
superstream (then we'd need to use a dimension from that subpart for the nile2iters).

> My first use for this will probably be two-directional anchored point-to-point
> hyperlinks, showing the linked-to text as floating in the margins.
> 
> Probably putting a single alphanumeric character in the special cell
> would make things easiest for the Nile2Iter&co...

That doesn't make a lot of sense to me. I think you should really use a
model that looks along a special dimension if something's there, and if
yes, we have a special cell. How the meaning of that cell is determined
is another question -- that doesn't need to interest Nile2Iter (except
if it's a subpart, i.e. not "one character long").

> Hmm, applitude-wise, it would be nice to be able to look for the special
> code just by dimension, so we'd have one cell connected to the stream in the special dimension
> and then that cell would be connected using a dimension that is special.
> This is the way applitudes are supposed to work. I wonder whether we could
> make it work already at this point?
> 
> The problem is that searching for which of N dimensions a cell is connected
> along is an O(N) operation which is NOT nice when the number of applitudes grows.

It also doesn't seem to make sense to me: in that model, Nile would need
to know all other applitudes that work with it. That's NOT the way
applitudes are supposed to work, is it?

> Any ideas?

I think if something from one applitude is included in something from
another applitude, the best way to look at it conceptually is to see the
connection as kind of a view. The "master applitude" finds a cell which
is "special." It somehow knows some code linked to that cell. (How that
should work is another question; for the moment, the ZOb interface and
similar structures work well.) It calls that code, which belongs to the
"sub-applitude." The "sub-applitude" is given the special cell, and
knows how to look for some of its own data from that cell. It reads that
data and processes it, like a view. Then, it returns a "view" on that
data in a form which the "master applitude" understands -- in the case
of Nile, something like an FText.Part array. The "master applitude" goes
on in building its own view.

Of course there can be different "views" on the same data structure
belonging to the "sub-applitude," meaning the data can be integrated in
different data structures of different "master applitudes" in different
ways at the same time.

> > Yep. (What we need first, though, is a framework to *make* the
> > connections, and have actions which jump between them... the view comes later...)
> 
> They all need to be thought out at the same time, because the views make
> some actions reasonable and some unreasonable.

Ok, granted.

> Basically, the current key->action list is completely wrong for this higher level.
> We need for e.g. the point-to-point linking applitude be able to say "I have
> these actions and would like to use these keystrokes for them", but with
> something on the higher level looking out for conflicts.

Oh my, yes...

- Benja