#101 cache is not validated

[Anonymous]

Hi Igor,
I'm trying to integrate Colorer library in my editor
control.

Colorer version is Colorer-take5 beta4.
Environment: Win98, MSVC6.0

I don't use colorer as a dll.
Instead compiled all *.cpp listed in
Colorer-take5.beta4/src/shared/makefile.objs and
Colorer-take5.beta4/src/shared/makefile.zlib files into
static library and linked it to my project. This
provides me with direct access to EditorBase and
ParserFactory classes.

Colorer is used to immediately colorize text, i.e. no
delayed coloring like in "Bred3" is used. This affects
editor responsiveness, but this is another story...

Everything works fine, but after text is modified
BaseEditor::getLineRegions returns invalid regions for
some lines.
Walking with debugger inside of BaseEditor::validate
method I noticed that cache is not updated if passed in
line number is equal to BaseEditor::invalidLine and
(BaseEditor::wStart + BaseEditor::wSize) is equal to
BaseEditor::invalidLine.
E.g:
lno = 225;
BaseEditor::wStart = 203;
BaseEditor::wSsize = 22;
BaseEditor::invalidLine = 225;
BaseEditor::lineCount = 384;

My workaround for the problem:
BaseEditor.cpp(347): - parseFrom = parseTo =
(wStart+wSize);
BaseEditor.cpp(347): + parseFrom = parseTo =
(wStart+wSize*2);

The workaround brings performance degradation, but at
least my editor doesn't hang.

PS Игорь, это Алексей, мы вместе на Ниагару катались с
Женей :)

Alexey

[Igor Russkih]

Logged In: YES
user_id=313042

Alexey,

It seems to be a problem of +-one line.
In case you have 22 lines visible on the screen, with first
visible line No 203, your last visible line should be 224,
not 225.

Try to extend the screen size information you providing to
the colorer. Possibly this can help. Make sure you counting
even partially visible lines.

зы. Привет Леш, вот уж где не ждал с тобой встретиться ;)

[alsemm]

Logged In: YES
user_id=1090023

Igor,

This is not a problem with +-one line. I understand that I
request regions for line which is not visible on the screen.
It is legal use case in my editor, and I also found no
comments that this is illegal for Colorer.

As I described already the problem occurred when I requested
regions for No 225 line while wStart is 203 wSize is 22 an
invalid line is 225.
Additional info:
BaseEditor::lrSupport->getFirstLine() returns 198
BaseEditor::lrSupport->size() returns 44

So lrSupport holds some invalid data (198 + 44 > 225) which
is not updated in BaseEditor::validate.

Imagine the case:
BaseEditor::wStart = 203
BaseEditor::wSize = 22
BaseEditor::linesCount = 384
BaseEditor::invalidLine = 384
BaseEditor::lrSupport->getFirstLine = 198
BaseEditor::lrSupport->size = 44
Request regions for No 225 line. What should happen? Nothing
bad, i.e. I will get valid regions for requested line which
is not visible on the screen at the moment. This request
will not make BaseEditor run parser to update cache. And
this is correct, since cached data referenced from
BaseEditor::lrSupport is valid.
The difference between use case described above and my one
is that BaseEditor::invalidLine hits range of lines
addressed by BaseEditor::lrSupport. Why BaseEditor doesn't
run parser to update cache? Can't it see that cache holds
invalid data?

Your proposal to extend wSize doesn't solve the problem.
Tried it already :). After I extend wSize it takes just
longer time to reproduce the problem.

IMHO the root cause is that lrSupport holds invalid regions
but BaseEditor::validate doesn't validate it when it should,
so this doesn't relate to wSize.

PS: Чуден мир :)

Alexey