Recent

Author Topic: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}  (Read 112029 times)

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #135 on: December 21, 2015, 04:11:37 am »
Quote
The original PAS HL (I didn't touch) implements it's own version of InitNode,StartPascalBlock,EndPascalBlock...

Then for now it keeps its own. That can be independently reviewed later.
Yes it was, but Now I changed my mind.
Soon I will directly modify that (PasSynPas.pas).
And for reviewing/comparing reason, the unmodified class will be kept in new file (maybe Original_PasSynPas.pas or PasSynPas1.pas ).


The reason is I want to integrate/test that HL in our Lazarus IDE Editor.
Loading file in IDE Editor is great because of it receives drag/drop file from WindowsExplorer etc.
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #136 on: December 22, 2015, 02:09:37 am »
Hey all, I have a little good news.
My markup is now cross-ifdef-directive aware.
This way, any pascal statement after $else should be in similar level as $ifdef statement level.


For example, DirectChild1 is first nested procedure inside MainProc.
MainProc->begin should be red = #first level
DirectChild1->begin = orange = #second level
GrandChild2->begin = green = #3rd level
SubGrandChild3 = cyan = #4th level


SiblingDirectChild4 = second level = orange
BEGIN of MainProc = #1st level = red


Code: Pascal  [Select]
  1. {.$define debug_FC_line_changed}
  2. procedure MainProc;
  3. {$ifdef debug_FC_line_changed}
  4. var F : TCustomForm;
  5. begin
  6.   F := GetParentForm(self.SynEdit);
  7.   if F <> nil then begin
  8.     if F <> Form1 then begin
  9.        if F <> Form2 then begin
  10.            if F <> Form3 then begin
  11.                if F <> Form1 then begin
  12.                   Result := Form0; end end end;
  13. {$else}
  14.   function DirectChild1: Integer;
  15.   var i : integer;
  16.     function GrandChild2: Integer;
  17.     var j : integer;
  18.       function SubGrandChild3: Integer;
  19.       var k : integer;
  20.       begin
  21.         repeat
  22.           inc(ANodeIdx);
  23.         until (sfaInvalid in Result.FoldAction);
  24.       end;
  25.     var j2 : integer;
  26.     begin
  27.       Result := SearchLine(YIndex, NIndex);
  28.     end;
  29.   var i2 : integer;
  30.   begin
  31.     Result := -1;
  32.   end;
  33.  
  34.  
  35.   function SiblingDirectChild4( aRow: Integer ): integer;
  36.   var S : string;
  37.   begin
  38.     Result := 4;
  39.   end;
  40.  
  41.  
  42. var y : integer;
  43. begin
  44.   Result := 100;
  45. {$endif}
  46. end;          



Well, although it was almost complete, there are known bug:
It can't resolve this real code:
Code: Pascal  [Select]
  1. {$IFDEF BCB}
  2. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  3. {$ELSE}
  4. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: HDC);
  5. {$ENDIF}
  6. begin
  7.   (FBackend as IDeviceContextSupport).Draw(DstRect, SrcRect, hSrc);
  8. end;      


Any clue?
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #137 on: December 22, 2015, 02:57:30 am »
Wow, everything is fine when we get rid from {$ELSE}. How it can be? I don't know yet.



Code: Pascal  [Select]
  1. {$IFDEF BCB}
  2. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  3. {$ENDIF}
  4.  
  5.  
  6. begin
  7.   (FBackend as IDeviceContextSupport).Draw(DstRect, SrcRect, hSrc);
  8. end;




PS:
Legend:
Kwd: count of available node (keyword) in a line
Nst: count of parent fold in a line
Min: Range.MinimumCodeFoldBlockLevel
End: Range.CodeFoldStackSize
NMi: Range.MinimumNestFoldBlockLevel
Nst: NestFoldStackSize
@#: nested-procedure level
T : =True, Inside procedure Neck (after 'procedure' before 'begin')
.  : =False, =not inside the procedure's neck (maybe inside 'begin' or outside procedure).
R: old sign, obsolete, will be removed in near future.

<- : starting-fold sign
-> : end-of-fold sign


Yeah, I use all of them just for detecting the nested-procedure level. I maybe overkill :)p
« Last Edit: December 22, 2015, 03:22:47 am by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #138 on: December 23, 2015, 10:59:38 am »
@Martin, when code is good enough (used as best practice), I think support them is also best practice (good enough).
So, after several trial, I reach a nice solution.

Well, although it was almost complete, there are known bug:
It can't resolve this real code:
Code: Pascal  [Select]
  1. {$IFDEF BCB}
  2. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  3. {$ELSE}
  4. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: HDC);
  5. {$ENDIF}
  6. begin
  7.   (FBackend as IDeviceContextSupport).Draw(DstRect, SrcRect, hSrc);
  8. end;      


Any clue?
This problem is now solved.


Further, I also solved more complex $IFDEF $ELSE things:
Code: Pascal  [Select]
  1. {$IFDEF foo}
  2. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  3. {$ELSE}
  4.   {$IFDEF bar}
  5. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  6.   {$ELSE}
  7.     {$IFDEF abc}
  8. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  9.     {$ENDIF}
  10.   {$ENDIF}
  11. {$ENDIF}
  12. begin
  13. end;  


But, I wouldn't solve below code, because it seem ambiguous:
Code: Pascal  [Select]
  1. {$IFDEF foo}
  2. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  3. {$ENDIF}
  4.  
  5.  
  6. {$IFDEF bar}
  7. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  8. {$ENDIF}
  9.  
  10.  
  11. {$IFDEF abc}
  12. procedure TBitmap32.Draw(const DstRect, SrcRect: TRect; hSrc: Cardinal);
  13. {$ENDIF}
  14. begin
  15. end;
  16.  

So, no worry, the non-ambiguous logic should be resolved by wrapping $IFDEF altogether, and adding several nested $ELSE like my solution above.
« Last Edit: December 23, 2015, 11:02:37 am by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5768
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #139 on: December 23, 2015, 02:19:51 pm »
I dont know how you did it. But if you use different foldgroups, test with {%region} too.

Also you can not assume any knowledge with foldgroup is what, as that is internal to each HL and can change

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #140 on: December 23, 2015, 04:46:12 pm »
... But if you use different foldgroups, test with {%region} too.
I have no problem with {%region }..{%endregion}, and nested one.
Any other valid & complex code I can test?


edit:
okay, I found the function (about {$ifdef,{$else ) also being called by {%region}
I will make it clear which line is special for $ifdef$else, so it will be easier to understand and maintain.


Quote
I dont know how you did it.
It's easy in theory. (evil is in detail  >:D ) :D


//any nested procedure is counted in each line in InProcLevel. let say: InProcLevel =0.
{$ifdef}
procedure a; //InprocLevel = 1
 function b; //inproclevel =2


// now, inprocLevel = 2
{$else}
// in $else, there are actually 2 node: close-node of $ifdef , and a new open-node of $else it self
// 1) when $else closing the $ifdef (by $else it self), it is a chance to reset InProcLevel to the value of InProcLevel before $ifdef was started
// this time, store InProcLevel to local variable, because the value of InProcLevel will be different whenever EndIfdefLevel changed.
// let say var LocalX := InprocLevel;
// now InProLevel == 0; LocalX == 0;
// 2) when $else has been creating new fold block, InProcLevel reuse last similar EndIfdefLevel value
// now InProcLevel == 2
// ----------------------- the idea is to reset nested procedure level after the $else, to be identic to condition before $ifdef---------------------------
// so, let reuse the local var!
{InProcLevel := LocalX;}
// now InProcLevel == 0;


 procedure a_2; // inproclevel ==1
 procedure b_2; // inproclevel ==2


{$Endif}
// in $endif, we do nothing, just continue the last counter
// now, inProcLevel ==2.
begin end; //inproclevel ==1 // nestd proc
begin end; //inproclevel == 0 // main proc



Quote
Also you can not assume any knowledge with foldgroup is what, as that is internal to each HL and can change
@Martin, in english, please?
what is "is what"? changes what? do you refer to FoldConfig, or refer to change api in future?
who is changer ? do you mean I couldn't change everything I wanted because it is a holy design?
« Last Edit: December 23, 2015, 05:05:52 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5768
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #141 on: December 23, 2015, 05:43:14 pm »
I havent sees your code, only will in 2 weeks...

so just generic comments, that may or may not apply.

I dont know how you "solved" ifdef. imho there is no easy way to do so.

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #142 on: December 23, 2015, 05:54:13 pm »
Also you can not assume any knowledge with foldgroup is what, as that is internal to each HL and can change
I try my best to reparse, your intonation might be:
"You can not assume with foldgroup is: as internal to each HL and hence you should not change too much".


Well, martin_fr, for honest I have a few degree of different view of point of "FoldGroup", most probably yes.
I think lazarus (IDE & Editor) has few wrong point of view of FoldGroup too.


Look at Tools>Options > Editor > Display > Markup and Matches (may differ, I use Lazarus 1.5 at home)
it is not really integrated with Toos>Options > Editor > Code Folding.
If/then/else not found in Code Folding, but only appeares in Markup & Matches.
The side effects is it will be complicated when new keyword introduced in fold-config. Let say, I want to introduce folding of 'with~do', 'for~do' etc.

FYI, using my markup class, a 'procedure' can be configured by setting 4 new configuration.
* procedure can completely ignored = exclude(sfaOutline)
* can has/ has not coloring, but maybe has a vertical guideline
* can has / has not vertical outline, but maybe itself has not be colored (like current "then" behavior)
* can visually ignored but has some affect to it's children.
Whatever, how can it be easy to configured?
sure by redesign / redefine the 'fold'. at least I need to redesign the IDE Options's frame.


Another reason: I might change too much, but that was the only way I could do.
It is better for me to change anything than change nothing.

Currently I can't take care of everything beyond SynEdit (such codetool, compiler directive, etc.).
So, if you want to keep IDE in good condition, tell me what shall I do technically.


When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #143 on: December 23, 2015, 06:12:59 pm »
Ouch, did you say "foldGroup" instead "FoldConfig" ? I mean Fold, FoldConfig (folding keywords)

but it still relevant:
How can user configure $ifdef as to be nested-coloring or not?
Some user didn't want to nested color the $ifdef $ifdef $ifdef, but other maybe wanted.
So, still we (I &me ) need to integrated those 2 IDE OptionsFrame (Markup & maches, + Code Folding).


Quote

I havent sees your code, only will in 2 weeks...
so just generic comments, that may or may not apply.


HA HA HAAA.. :P Well I Agree.
But hey, You can not make assumption too, before read the code. Because apply/reject is by strong technical reason.
 >:D 8-)

« Last Edit: December 23, 2015, 06:16:06 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #144 on: December 31, 2015, 06:51:42 am »
Hi,
I have several good news. 8-)


The important news is : I finally able to independently draw markup without FOLD.
it means big change to SynEdit-foldable-Highlighter.
Because lazarus trunk will allow markup to be drawn : only when sfFold (code-folding in IDE) is enabled.


IMHO, it is better: if drawing any markup (such as MarkupWordGroup / paired open~close fold) independently, to being not interfered by code-folding.
in other word (not english) : [sfaFoldFold] <> [sfaMarkup] <> [sfaOutline].


Well, now we can make different between FoldConfig[].Enabled := False; vs FoldConfig[].Modes := -[sfaFold].
This way, "Enabled" will completely affect the whole Modes.
when "sfaFold" will only apply to foldable code, and other modes still active.



another news:
I introduce 3 pascal keywords to be in Markup+Match, Foldable, NestedColoring:
  • for/do
  • while/do
  • with/do

I also deprecating PasFoldLevelEnd, PasMinLevel. >:D  Reusing (and bugfixing) the base class. :-*




Final result: you can disabling fold and in the same time enabling other markup.
see the picture attached.

When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5768
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #145 on: December 31, 2015, 09:27:50 am »
IMHO, it is better: if drawing any markup (such as MarkupWordGroup / paired open~close fold) independently, to being not interfered by code-folding.
in other word (not english) : [sfaFoldFold] <> [sfaMarkup] <> [sfaOutline].


Well, now we can make different between FoldConfig[].Enabled := False; vs FoldConfig[].Modes := -[sfaFold].
This way, "Enabled" will completely affect the whole Modes.
when "sfaFold" will only apply to foldable code, and other modes still active.

absolutely correct. that is how it should be. (And the HL can force some nodes to be enabled, if it needs them for context. e.g. keywords that exists only in certain context)

if there are fixes needed, they should be applied independent of the markup you work on.

Quote
I also deprecating PasFoldLevelEnd, PasMinLevel. >:D  Reusing (and bugfixing) the base class. :-*
that can also be patched on its own.

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #146 on: December 31, 2015, 10:17:56 am »
absolutely correct. that is how it should be. (And the HL can force some nodes to be enabled, if it needs them for context. e.g. keywords that exists only in certain context)
Yeah,
FoldConfig[].enabled, may then only (and still) needed on UnitTest applications.


But, that was not that finish. Lazarus IDE Cod-Folding (editor options) need to be changed too, to reflect the new way.
Anyway, I am trying to little bit redesign those IDE options. in directory: synedit-modified\ide\...
so, I will inform you if I have reached a satisfied result.


Quote
Quote
I also deprecating PasFoldLevelEnd, PasMinLevel. >:D  Reusing (and bugfixing) the base class. :-*
that can also be patched on its own.
I think the modified pascal HL is now stable. And it's baseclass too.
With debug-assert enabled, today I have no error appear.
I also test them with & without my markup. everything seem okay with Lazarus 1.6 and Lazarus 1.7 (a.k.a trunk).


If you have time, you are very welcome to patch them to lazarus trunk :
* SynEdit-modified\SynHighlighterPas.pp
* SynEdit-modified\SynEditHighlighterFoldBase.pas
* SynEdit-modified\SynEditMarkupWordGroup.pp


Quote
if there are fixes needed, they should be applied independent of the markup you work on.
Actually my Markup is also stable enough,
however, I can't recommend to use it now, because : it still slow down when reach lines > 4000.
And my markup is not sexy (even awkward) when 'begin' is not vertically similar to the 'end'.
I have some plan (good ideas) to resolve it later days.


Anyway, I have no further plan / todo with pascal HL. Maybe, just clean up the comments. you can do that.  :-[ :P
But let me know if I can do/correct something with it.
« Last Edit: December 31, 2015, 10:41:49 am by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5768
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #147 on: December 31, 2015, 10:47:03 am »
Quote
FYI, using my markup class, a 'procedure' can be configured by setting 4 new configuration.
* procedure can completely ignored = exclude(sfaOutline)
* can has/ has not coloring, but maybe has a vertical guideline
* can has / has not vertical outline, but maybe itself has not be colored (like current "then" behavior)
* can visually ignored but has some affect to it's children.
Whatever, how can it be easy to configured?
sure by redesign / redefine the 'fold'. at least I need to redesign the IDE Options's frame.

redesign of the ide frame should be no problem. Open to any change needed. But imho thats last on the list.

foldconfig:
I am still thinking about it, there are various options and considerations. Most important, what needs to be known by the HL, and what is markup.

Since the HL needs to deliver the base info for the markup, it also needs some config for this. This means certain config will have to be present, even if the markup is not used at all. (this conflicts with keeping everything modular, but it can't be avoided)

well it could have partly been avoided by adding a collection to foldconfig, and the markup could add a sub classed collection item. But that would cause far to much overhead, so imho not an option.

We first need to look at how many modes are needed.
That means do decide if EVERY configurable keyword can have all options:
- colored and/or lined
- ignored/merged parent or child

merging does not make sense for all the keywords (there in no point in merge "repeat" with parent or child ever).
Imho the HL should have a new property  (enum) to toggle the sensible merges.
Same for ignores.
pasHL.MarkupOutlineOptions = (
moProcedureHiddenIncrease,
moProcedureBeginMerge,
.....
)


as for color vs line:
Just an idea, think about, let me know.

maybe each fold config can have a integer tag.

the markup can then have a list of tags, and properties for it (the problem may be to implement a fast lookup)

e.g.
tags 1,2,3 color
tags 4,5 line
tags 6.7 both
other markups can use the same tags, but group them differently.

If it was only your markup, then we could add 2 modes (outlineColor, outlineLine) and maybe that is the better idea for now.

Only if there are more markups in future this will add many modes.
1) a SET has only so many members
2) the difference between color and line is really none of the HLs business.

Maybe you have more ideas?

btw,tags could also override merge info on the markups side.

------------------
 EDIT
instead of tags  a generic set/enum would also be possible. (more like a bitmap). The HL just copies them from the foldconf, and the markup then can be configured to apply features to individual bits/members
« Last Edit: December 31, 2015, 11:14:48 am by Martin_fr »

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #148 on: December 31, 2015, 12:32:41 pm »
Quote
FYI, ...
Whatever, how can it be easy to configured?
sure by redesign / redefine the 'fold'. at least I need to redesign the IDE Options's frame.

redesign of the ide frame should be no problem. Open to any change needed. But imho thats last on the list.
Thanks you! 8-)
Quote
foldconfig:
I am still thinking about it, there are various options and considerations. Most important, what needs to be known by the HL, and what is markup.
I keep it simple in mind:
- Markup do know nothing, except the instructions (X,Y, etc.) of drawing.
- HL dictate what should be drawn by Markup, but it always depends on foldconfig.
- HL do know nothing of final/current value of foldconfig. (however, HL provides default foldconfig values.)
- HL knows specific language keyword (repeat,until,begin,while,do, etc.)
Whenever found specific keyword, HL just quickly provides "node" info without seeing what values are delivering from foldconfig.


So, neither HL nor Markup care about foldconfig. It is indirectly from user to user.



It is beautiful design of fold config.
That is why my markup is very simple: modular.! only 500lines. I think I will reduce the codes in future.


Quote
Since the HL needs to deliver the base info for the markup, it also needs some config for this. This means certain config will have to be present, even if the markup is not used at all. (this conflicts with keeping everything modular, but it can't be avoided)well it could have partly been avoided by ...
Hey, there are no conflicting. When HL providing nodes/infos, it is not a big job for HL, because everything has been done once foldconfig changed. And as usually, foldconfigs are not changed during user work with synedit.
Its not a big job for HL : provides the value looked up from foldconfig.
So, I think no worry for this aspect.

Quote
But that would cause far to much overhead, so imho not an option.
I agree, there are no benefit of additional-config-properties of current foldconfig.

Quote
We first need to look at how many modes are needed.
That means do decide if EVERY configurable keyword can have all options:
- colored and/or lined
- ignored/merged parent or child

merging does not make sense for all the keywords (there in no point in merge "repeat" with parent or child ever).
If Merging not applicable for few keyword, let's make it disabled (not configurable) for them.
Look at attachment of how to disabled.

Quote
If it was only your markup, then we could add 2 modes (outlineColor, outlineLine) and maybe that is the better idea for now.
Great! adding fmOutlineColor,fmOutlineLine is the best we can do for now.
These 2 modes, together with fmOutline, can easily be implemented into IDE options. see attachment of how to.

Quote
2) the difference between color and line is really none of the HLs business.
even HL will never care about these, but the HL is the only correct place to put them.
It is the reason of why there are combobox "languange" for configuring them. see attachment, noticeable as green.

Quote
Maybe you have more ideas?
I don't understand what is problem with current foldconfig?
I can't see any benefit of additional tags or enums.
 I can't see any problem with current config's technique.

It is most probably caused by my stupid, I felt I may misunderstand of your ideas.
Can you further talk about these?



edit: +attachment.
« Last Edit: December 31, 2015, 12:47:44 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #149 on: December 31, 2015, 01:11:55 pm »
foldconfig:
I am still thinking about it, there are various options and considerations. Most important, what needs to be known by the HL, and what is markup.

Since the HL needs to deliver the base info for the markup, it also needs some config for this. This means certain config will have to be present, even if the markup is not used at all. (this conflicts with keeping everything modular, but it can't be avoided)

well it could have partly been avoided by adding a collection to foldconfig, and the markup could add a sub classed collection item. But that would cause far to much overhead, so imho not an option.


Oops, you said "conflicts" and I did recognize it as it's antonym. sorry.
Now I understand, you might said: adding more foldconfig to HL will add more work to HL, even the markup (who doing the foldconfig job) is not available (disabled). Ideally if markup not available, there are no related work for HL.


And most probably you are worrying about : my markup slowing down when reach line > 4000.


1) Well, about slowing down, it's pure my bug. It would not a bug for other markup class.
You have said that I should introduce a new virtual method that pascal HL can override. I will be solution, but I need more time to implement.


2) About useless foldconfig (because markup not available),
Based on my experience (1 month days and nights), IMHO it's normal.
Additional foldconfig wouldn't make HL work harder. (additional fold config = add more member of a type). And these types are not intensively calculated.
AFAIK, It would not make HL more complicated.
It may only make IDE's editor options a bit more changed.  8-)





When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine