So, normal way is bad (or at least : not optimized) because this way is finding through too many lines (assumed 10000 lines) until it match.
Storing that info will save time and battery. :)p
...
I see no need to store for example that a fold starting in line 190 has a length of 75 lines. (store 75)
c) if you store it in the range, or code foldblock (part of the range) then they become nearly impossible to re-use.
As for long folds (10000 lines), that is no problem. Well if you scan a 1000 folds of 10k lines then maybe it will be.
Hey, I currently face a real problem ...
!
coming is new bad news (and the same time is also good news too),
well, I integrated my MarkupColorFold into Lazarus
The good news is there are no error, it was gracefully integrated (debug assert enabled).
The bad news is:
it is not as what it was designed. Vertical lines are jerk here.
Rather helps programmer, it will confusing them.
Yeah, It need some finishing/touch-up to be looked as cool enough...
(see attachment)
This messy visual effect, can be solved by drawing all vertical lines, straight to "end;" keyword vertically.
We can see how CnPack solves the same problem. (see attachment II )
-----
Using MarkupWordGroup as guidance, we can easily found the 'end' part of each fold block.
When the 'end' is founded, we can compare with the 'begin' positions, resulting which one is the left most.
this leftmost position will be used to draw the correct vertical lines.
This way, one vertical-line-mark is done.
But if a line is located in 3th dept of folds, this step should repeated 3 times.
But, because MarkupColorFold will operate per sourcecode's line basis,
the next sourcecode-line will repeat comparing the left most pair of that begin~end (that have already proir calculated)
... plus : if it still in 3th depth of folds, comparison will be repeated 3 times again.
see?
For honest, the longest procedure AFAIK would be only 200 lines including off-of-screen lines. (sorry for 10K abuse).
But, couldn't we make this real solution more efficient?
MarkupWordGroup only finding pairs of begin~end once, or twice, or maximum 3 time, and her job done.
But MarkupColorFold is more expensive on looking for paired begin~end than MarkupWordGroup in this situation.
So, it is my assumption : storing both closing+opening tag of a fold-block will minimize allocate/deallocate memory,
which in turn will reduce your battery-laptop consumption.
How?
THere is a good idea that depends on the concept/fact that HL store states for each line.
Assumed that System.pas has 10K lines, it should have 10K states stored, right? because 1line = 1 states.
Hence, on file loading, when a 'begin' of procedure block founded, I can store that begin postion.
when 'end' of that procedure founded, I stored that in the shared-folding-block (whatever Range / CodeFoldBLock?).
Now, when SynEdit need to refresh the screen, MarkupFoldColorPascal wouldn't need to find the left most X of paired 'begin'~'end' for each dept of fold block.
She can directly read the data stored for each block, and when need to read the same info of .Parent block just read, without re-searching.
(similar situation was described here:
http://forum.lazarus.freepascal.org/index.php/topic,30122.msg194828.html#msg194828| | | | | HorzEntry := EMPTY_ENTRY;(see attachment for complete lines)see?
You might say that we don't really want to store this specific pascal things in MarkupFold,
Well, For reason of general purpose use, let MarkupColorFold as is.
For pascal, we can inherit it into new class that able to store 3 x integer x 2(begin,end) = 6 integer length per block (not per line).
If this concept is negative, how can an HL rescan (reparsing) a line randomly?
But it most probably impossible, when range (or foldblock?) is reused rewriten unpredicably.
Ranges (if they are an object) are re-used. And with that the same FoldBlock object is used to represent the state on many lines.
begin // range at the end of line has foldblock 0x0001
if a then begin // range at the end of line has foldblock 0x0002
end; // range at the end of line has foldblock 0x0001 since the inner fold is closed
if longer_condition then begin // range at the end of line has foldblock 0x0002 again (re-used), even the X pos differs.
end;
end;
What do you think ?