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

List:       ktexteditor-devel
Subject:    Re: question about EditInterface
From:       Christoph Cullmann <cullmann () babylon2k ! de>
Date:       2005-05-18 15:56:54
Message-ID: 200505181756.57292 () cullmann
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 18 May 2005 05:06, Jens Herden wrote:
> > 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.
but offset/length will be invalid after each keystroke, while lines are 
easiert to be kept up to date, like done for the breakpoints and so on, the 
problem with a interface to allow access via offset/length is that it will be 
really slow for the 2 only implementations of kte, kate and yzis, as we are 
line based, and converting offset to lines is not that effective, not 
unusable, but really not nice to collect the lengths of all lines in front to 
get the offset

do you parse incremental? or just get the text once and be done?

>
> > 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.
it only means that the current way of line/col avoids this, as the line 
endings are not even in the buffer and are transparent, while for 
offset/lenght there would need to be consense that line endings count as 1 or 
0, or whatever ;) and that blockselections are not possible :)

-- 
Christoph Cullmann
KDE Developer, kde.org Maintainance Team
http://www.babylon2k.de, cullmann@kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]