Re: [Gzz] PEG: canvas_text--mudyc now current

[Tuomas Lukka]

Good to see a new version. I hope you notice yourself also
that this process (publish-comment-fix-comment-fix-comment)
really improves things. I know I am grateful for any comments
I get on anything - sometimes (like with HT03) it may take a while
to get over the primitive reaction ("someone didn't approve of my 
stuff! I'm personally insulted!") to the appropriate scientific
reaction ("Hmm, I forgot to explain this well enough - oh, and
yes, that's a valid objection which I need to address by 
showing experimentally that our stuff is valid"). It's the transformation
from a primate to a scientist ;) 

(I've been just reading Pratchett-Stewart-Cohen, The Science of the 
Discworld II, the Globe -- recommended reading for everyone)

I'm getting the impression that this PEG needs to be split 
some more - it still has too many different aspects:
1) the RST stuff (which I still haven't got a clear
   handle on)
2) the splitting of text into streams of nodes (what does this
   buy us above enfilades with markup??)
3) the nile edit ops

It seems that this is quite a natural thing with PEGs: someone
starts to PEG something and then, after some thinking, we find
that the PEG needs to be split into separate aspects...

Detailed comments below.

> 
> I do like to see improvements in text editing/handling in
> spatial canvases. 

It might be better to write PEGs a bit more officially,
avoiding "I".

> Current model is based on pp's way
> to handle text and that is too limited even for pp.

"The current model is based on plain text strings stored
in single nodes, which is quite limiting"

> There are at least three disagreeing circumtances:
> wysiwyg, text editability, spatial positions.
> This enchament propouse is meant to be compromise of
> these three circumtances for our own best.

What exactly is it that you want to improve? This part of the abstract
has a lot of words but says very little.

> Issues
> ------
> 
> - Would Nile like text editability be too complex for pp?
> 
>     RESOLVED:
>     Yes and no. Word/Sentence/Paragraph modes would not be 
>     set by default. Paragraph thinking already solves much 
>     of the current problems of pp text editability also.

Would not be set == would not be enabled??

What's "paragraph thinking"?

What are the current problems of pp text editability?

> - If we have associated a node [foobar] and
>   someone likes to split it as a [foo], [ ], [bar].
>   What we do for the rdf propertys while splitting?

Associated = ?

"RDF properties"

>     RESOLVED:
>     We do copy all propertys from [foobar] to [foo] and [bar],
>     except the property 'nextNode' which is set like:
> 
>     Old: ::
> 
>        [prev] --nextNode--> [foobar] --nextNode--> [next]
> 
>     New: ::
> 
>        [prev] --nextNode--> [foo] --nextNode--> [ ] -->
>  
>           >>--nextNode--> [bar] --nextNode--> [next]

I'm not at all sure whether this issue is satisfactorily resolved...
This means that there are several different associations for
what used to be just one?

> - Why sentence hasn't words but nodes?

I don't understand the question - you need to put in a little
more context and definitions of terms.

>     RESOLVED:
>     If one of the future goals is rst generated presentation
>     we need to be able to say where there are spaces and it's 
>     easier to not present unwanted spaces if those can be 
>     identified with ' ' or such.

I don't understand this explanation at all. Please write more specifically
and preferably with a concrete example.

> - What to do with emptys (spaces like [ ]) in rst generated view?

"rst generated view"???

>     RESOLVED:
>     That's the point, we don't show them but we do have to show them 
>     in text mode view.

> - What to do if someone wants to associate a piece of a sentence but 
>   more than one node?
> 
>     RESOLVED:
>     We don't support that or we associate nodes one by one.

But this conflicts with the earlier copying of [foobar] props to [foo], [ ] 
and [bar]!

> RST as a inspirer
> -----------------
> 
> I do like very much of reStructuredText philosophy.
> It is very handly to edit in *text mode* but of course
> looks fine in *generated mode* where we are used to 
> read it. 

> Normally you can't edit text in the generated 
> mode but I see this as a lack. 

"a lack" = having too little of something, i.e. "a lack of resources",
"a lack of milk".
"deficiency" / "inadequacy" is probably what you're after.

> At least I usually would 
> like to edit typos found in generated text.

Umm, this section leaves many more questions open than it provides answers.
1) what exactly will we want to borrow from RST
2) why?

> Nile as a inspirer
> ------------------
> 
> As discussed with Asko about rst like canvases he quite 
> fast informed me about Nile. After looking to Nile I
> needed to come back to design board. Yes, we absolutely
> need nodes, sentences of nodes and paragraphs as a primitives. 

Why? 

Nile is a *user interface*. What does it have to do with the internal
representation of text? 

What *exactly* do we want from nile? The UI? The chapter/section stuff?

I stop my comments here, since I think I'd really understand
the intentions of the split version better.

        Tuomas