[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ktexteditor-devel
Subject:    Re: question about EditInterface
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-05-18 3:06:51
Message-ID: 200505181006.52399.jens () kdewebdev ! org
[Download RAW message or body]


> The KTE interfaces are historically bound to the katepart editor, which
> stores the text in blocks consisting of lines. When you call text() or
> selection() the requested string is calculated and then returned. So to
> achieve what you want we'd have to add a method/methods to the interface to
> handle that translation.

I see and I will try to explain what I am thinking about than you might have a 
good solution how to do this with KTE.

The current big problem in Quanta is that we have the following flow of data:

1. texteditor -> internal tree 
2. file in the texteditor -> KHTML part

Basicly we manage two independent trees and try to glue them together so that 
we can manipulate the KHTML view, trace it back to the source and change the 
source in the texteditor. 

Quanta tries to not reformat the users code so we need links between the nodes 
in the trees and the area in the text where the node comes from. We do not 
want to build the document from the parsed tree!

The traditional DOM tree implementations are not interested in the way back 
because they usually want to render and not to edit the document. 

The solution I have in mind is to get rid of the internal tree of Quanta and 
create a DOM tree that can be used from KHTML. This tree needs to remember 
where the nodes come from. 

I want to use the texteditor as data source for the tree parsing. I can get 
the QString from KTE but than I am lost because I can not translate a 
substring to the line/col coordinates the interface uses in other places. 

And this is also not memory efficient because I have to copy the whole 
content. 

So the soultion I imagine would be a kind of iterator to get the underlaying 
document QChar by QChar. This can be fed into a parser. 

Of course I can count the \n myself than I know in which line I am and I can 
save positions in line/col format. But a offest/length format would much 
easier to handle and needs less memory to save.

This kind of interface is more an interface to the document than to the view.

> One thing to note in that context is that the length of the text or
> selection is different depending on the line end format.

Does that mean if I save the coordinates of a selection and change the line 
end format the saved selection is wrong? This would mean I can not save a 
selection!

I hope you understand more the background of what I would like to have.

Jens
_______________________________________________
Ktexteditor-devel mailing list
Ktexteditor-devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel
[prev in list] [next in list] [prev in thread] [next in thread]