Re: [zzdev] Nile

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Sun, Dec 10, 2000 at 04:46:31PM +0100, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> >
> > Now, the biggest challenge here is to abstract and encapsulate it
> > to a sufficient degree; I'd like to be able to use the same text-editing
> > machinery in a variety of situations. That's why I haven't put in
> > bindings for the different levels of headings etc. just yet, since
> > those should be applitude-dependent and pluggable.
> > 
> > Similarly, things that we need for writing articles, such as
> > references and figures should be put in as an independent, pluggable
> > applitude.
> 
> 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.

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

> The other
> thing is that I would like to use it for my applitude. Now that things
> start falling into place concerning the zaubertrank, I see that I
> desperately need a good text editor supporting variables, i.e. something
> like "bla bla <var> bla bla," where <var> is shown like normal text (by
> the line breaker etc.), but treated like a single entity (somewhat like
> one character) by the cursor, hopping etc. algorithms.

Right.

> I think generally we need:
> o textual "objects" in the stream which can be edited with the Nile commands,
> o textual "objects" in the stream which cannot be edited with the Nile
> commands, and
> o graphical "objects" in the stream, which of course also cannot be
> edited with the Nile commands.
> 
> Textual objects' applitudes would be called for FText.Part arrays or the
> like. Maybe graphical objects should be, too: one could construct
> FText.Part subclasses which put graphics on the screen. On the other
> hand, we want to have figures which are surrounded by text, not included
> into one line of the text -- there, it gets harder.

> Any others I forgot?

I think those cover it all.

These are certainly among the next things I'm going to do. Probably with
one unified way: just a mechanism for Nile to look outside for how to show
a special cell in the stream. 

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

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.

Any ideas?

> > The whole framework needs a lot of thought.
> > 
> > One thing I'd like to do would be to have it be possible to have the
> > currently active text at one place, and then all the connections from it to
> > other places floating around it.
> 
> 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.

Getting the whole picture is the most difficult thing: we have
	- applitudes for showing the various things
	- applitudes for keystrokes to do various things with the various things
	- various actions for the various things

now, how to manage that without it becoming messy or monolithic is highly nontrivial.
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.

	Tuomas