From ktexteditor-devel  Thu May 19 09:35:07 2005
From: Jens Herden <jens () kdewebdev ! org>
Date: Thu, 19 May 2005 09:35:07 +0000
To: ktexteditor-devel
Subject: Re: question about EditInterface
Message-Id: <200505191635.07484.jens () kdewebdev ! org>
X-MARC-Message: https://marc.info/?l=ktexteditor-devel&m=111649536615366


> but offset/length will be invalid after each keystroke, 

This problem is already there, we have to check out where the change happened 
and parse this area again.

> 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

I understand that the offset/length interface is not fast. It was not meant to 
replace the existing one. I was only thinking about an option to convert.

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

So the initial parse would be the whole document, but later on only damaged 
areas, as far as we can detect them. 

> 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 :)

Well I do not care for blockselections at all and as I said I do not want to 
change the interface just add something. 

In fact I can live without the offset/length interface, but what I really 
would like to have is a easy and fast way to get the document character by 
character to feed them into the parser. 

Jens
_______________________________________________
Ktexteditor-devel mailing list
Ktexteditor-devel@kde.org
https://mail.kde.org/mailman/listinfo/ktexteditor-devel