Re: Enfiladealigner (was: Re: [Gzz] Ids)

[Tuomas Lukka]

On Mon, Aug 19, 2002 at 09:47:55PM +0200, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >On another note: I'm deprecating the *Space constructors that
> >take an enfiladealigner: I already said here that Space should not
> >do anything with an enfiladealigner, as the implementation is too
> >ill-defined. I'd like to retain the gzz core APIs such that they could
> >be formally defined and justified.
> >
> Hm. While I do understand that, I also feel that enfilade aligning 
> should in fact be a part of the core API, with the following functions 
> in CellTexter:
> 
> exportText(Cell)
> updateText(Cell, String)
> 
> This is because I would like the client not to be dependent on 
> VStreamTexter etc. here: a simple string-based cell texter could 
> implement these methods in a terribly simple way.

Well... I don't know. We might actually use fake spans there.

But either way, aligner represents a complicated functionality that has 
a lot of *policy* embedded into it as assumptions and should not be set
on a space-wide way. 

What you want to happen depends on where you are.

I'm all for creating new classes for the different policies and using
them statically:

        AlignedTexter.getText(cell)
        AlignedTexter.setText(cell, string)

or dynamically. 

But the prime objection to having this in the space is that such policy
does depend on the particular thing that's being done with the space
and is not a space-wide policy decision but a per-user-interface one.

> I'd also like to define the result of a StringSearcher match always to 
> be ordered (two consecutive searches return the same order of items), 
> because I'd like to be able to step through the different matches with 
> e.g. the up/down keys.

Sorted could be very good.

        Tuomas