Recent

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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5695
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #150 on: December 31, 2015, 01:19:29 pm »
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.

I prefer only one mode. Because there may be further markups, or other modules that need to add modes.

then somehow configure on the markup, which nodes to color/line/both.

the markup could have a list of ptrint containing the ord values of cfbt.... that should have color or line.


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 #151 on: December 31, 2015, 01:37:05 pm »
oh, you saying about that.


well, when I did implement exactly what you wanted, then the keywords will be not configurable ([OutlineLine, OutlineColor]) any longer.
Let say I want cfbtForDo to be not colored, how can do that via IDE Editor-Options? We will not able to do that !


As far as I know, IDE editor options will change the HL.FoldConfig[ord(cfbtForDO)].modes := [fmOutline,fmOutlineHasLine, fmOutlineHasColor]
if you prefer only one mode ( [fmOutline] ), how this can be resolved ? >:D
« Last Edit: December 31, 2015, 02:00:00 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: 5695
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #152 on: December 31, 2015, 02:43:42 pm »
markup.drawLines[ord(cfbtForDO)] := true;
markup.drawColor[ord(cfbtForDO)] := true;

of course if you change the HL to xml, then you need to change settings.

on top of that 2 settings

markup.DrawLinesForAll := false // if true then do not check the above is ignored
markup.DrawColorForAll :=

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 #153 on: December 31, 2015, 02:44:17 pm »
Now I know the problem. :o
You are keeping HL classes to be not be changed when a new markup class introduced. aren't you?


Modularity = a module no need to be changed when another module introduced.
current situation = all foldable HL need to be changed to reflect of new markup born.


Now, let see what are the constraints:
* user should able to configure HL + Markup behaviors via IDE's editor options.
* HL should not changed too much (even shall not changed) when a new markup introduced.
* Ideally, Markup class is general purpose, not designed for specific programming language.
* FoldConfig is no longer for expand/collapse things only. It became more general purpose.




And what are NOT be constraints:
- FoldConfigs may/ may not attached to HL. it can be independent class, can be looked up using TypeInfo.
- configurations per markup should / should not multiply of available markup.
- known markups may / may not available at a time.
  (But configurations for each markup can be created & destroyed anytime)


So, from above thought this is my idea:
+ Extract the markup config into a new class/record.
Purpose: modularity, keep HL in it's own business.


It should apply to configure MarkupWordGroup, and any newer markup.
This way, new introduced markup would not change any HL.


The final amount of configurable things would be: (HL count * eachHL.configCount) * know markup class.
Pascal.configcount := ord(cfbtIfthen{last}) - ord(cfbtBeginEnd{first})
known markup class := [MarkupWordGroup, MarkupNestedColoring, ..., MarkupNewerClassIntroducedLater]
HL count := [ Pascal, JS, XML, HTML, PHP, ...]


You can see, additional new Markup class will only need additional config, but no change will be needed for each HL.


Note:
1) I don't know whether FoldConfig will be completely detached from HL, because fmFold may still needed by other module (such gutter, TextBuffer, etc.).
2) when a "new" config created, it will not require the markup instance exist,
but we only need the count of them for displaying / playing with them.


It will be similar of registering new type of TGraphic, but that TGRaphic ancestor instance are not required to be exist, just only need to register the class.
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 #154 on: December 31, 2015, 03:10:10 pm »

@Martin_fr, it would not work.
markup.drawLines[ord(cfbtForDO)] := true;
markup.drawColor[ord(cfbtForDO)] := true;

of course if you change the HL to xml, then you need to change settings.

on top of that 2 settings

markup.DrawLinesForAll := false // if true then do not check the above is ignored
markup.DrawColorForAll :=
You know, such configurations is needed to be stored some where.
And the current place is in HL.
We cant make markup class as the place to store the configuration.
Can we?
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 #155 on: December 31, 2015, 03:27:22 pm »
I have a question:


For each of specific language HL (let say for TPasSynPas), is there possible to have different FoldConfig for multiple instance?


Example: I have two TPasSynPas instance in real life, are there a need to have different FoldConfig ?
PasSynPas1 = if/then/else is marked as triplet markup,
PasSynPas2 = in opposite configuration.
Are these needed in real life?

-=-
if above is possible: fold config shall be inside HL, because different HL instance (same class) should has different config.

if above is Impossible: fold config can be extracted into another class, all similar HL class (multiple instance) has one global config.
« Last Edit: December 31, 2015, 03:30:59 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 #156 on: December 31, 2015, 03:34:26 pm »
Well, I just changed my mind.


Even there are one global config for all instance (multiple instance same class),
each instance can has a copy of that config.


Meaning no mater inside or ouside HL the config attached,  each instance can has individual config for further make different with other intance (same class).


It also possible to make the config shared among instance or independently, just like your ".AddReference" things !

wow. What's your opinion?
« Last Edit: December 31, 2015, 03:36:26 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: 5695
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #157 on: December 31, 2015, 03:43:31 pm »
You are keeping HL classes to be not be changed when a new markup class introduced. aren't you?
Ideally yes-ish. though its not entirely possible. (at reasonable cost.

Synedit should be modular, and modules should be forced to stay in there boundaries, which improves maintenance. Look at syncro edit, or multi-caret. You can use synedit without them. they are add ons.

Now HL and markup have some dependencies. That is ok. This are dependencies arising from the functionality they should provide. They should not arise from implementation detail.

Though there is a 3rd factor  "usability" (from users point) and that is not always easy to decide.

The dependency here is markup needs HL. But HL does not need markup.

So anything added by the markup should not impose on HL.
"should not". However to some extend it must do so, but should should be minimal.

For the HL it makes no difference, how the outline is painted (line, color-pair, both). That info is not needed to provide matching nodes. So if possible that should be configured on the markup.


Quote
And what are NOT be constraints:
- FoldConfigs may/ may not attached to HL. it can be independent class, can be looked up using TypeInfo.
foldconf class is always defined by the HL (HL subclass)

It may be, that markups can attach additional info

foldconf.foo = TCollection

and a markup could add an inherited TCollectionItem to that. Doing so needs clever lookup, in order to not search the entire collection all the time.

Quote

So, from above thought this is my idea:
+ Extract the markup config into a new class/record.
which part to extract?

Some parts go on the HL and the foldconf (mis-named now), as they are needed by the hl.

Some can go on the markup itself.

Are there currently parts that need to be extracted?

Quote

Note:
1) I don't know whether FoldConfig will be completely detached from HL, because fmFold may still needed by other module (such gutter, TextBuffer, etc.).
2) when a "new" config created, it will not require the markup instance exist,
but we only need the count of them for displaying / playing with them.


fmFold , fmMarkup and (ONE) fmOutline  will stay (as the HL needs it, too provide info).


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5695
    • wiki
Re: Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes}
« Reply #158 on: December 31, 2015, 03:45:50 pm »

Even there are one global config for all instance (multiple instance same class),
each instance can has a copy of that config.


Meaning no mater inside or ouside HL the config attached,  each instance can has individual config for further make different with other intance (same class).


It also possible to make the config shared among instance or independently, just like your ".AddReference" things !

wow. What's your opinion?

global meant PER markup, but switching all nodes.

 That is enable/disable per node config.

The module may also be used outside the IDE, so that is helpful for users.

---------
more next year

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
markup.drawLines[ord(cfbtForDO)] := true;
markup.drawColor[ord(cfbtForDO)] := true;


1) I assume you agree: we put Markup classes  in general purpose level (not for specific programming language) as possible.
MarkupIfDef is excepted. But other markup class should be independent.


2) I can implement what you wanted, so I accepted above code is a concept, it may different in real code.


Now, the problem is : pascal HL has CountPascalCodeFoldBlockOffset that used in too many lines.
This CountPascalCodeFoldBlockOffset are used together with CodeType (cfbtForDo, cfbtIfThen...) using sum operation.
Code: Pascal  [Select]
  1.  
  2. BlockEnabled := FFoldConfig[ord(ABlockType)].Enabled;
  3.   if (not BlockEnabled) and OnlyEnabled then
  4.     exit(nil);
  5.   FoldBlock := BlockEnabled and (FFoldConfig[ord(ABlockType)].Modes * [fmFold, fmHide] <> []);
  6.   p := 0;
  7.  
  8.  
  9.   if not FoldBlock then
  10.     p := PtrInt(CountPascalCodeFoldBlockOffset);
  11.   Result:=TSynCustomCodeFoldBlock(StartCodeFoldBlock(p+Pointer(PtrInt(ABlockType)), FoldBlock));  
The side effect is : pascal blocktype value sometime is beyond the foldconfig count.
in english: pascal blocktype value is not portable.


It is a bug of pascal HL. keeping this constant will sacrifice other class portability.


My sugested solution is deprecating this CountPascalCodeFoldBlockOffset, using portable logic/value: sfaFold.
You know, CountPascalCodeFoldBlockOffset is just a flag when the block has NOT sfaFold.


Is there another usage of CountPascalCodeFoldBlockOffset that I didn't know?
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5695
    • wiki
1) I assume you agree: we put Markup classes  in general purpose level (not for specific programming language) as possible.
MarkupIfDef is excepted. But other markup class should be independent.

2) I can implement what you wanted, so I accepted above code is a concept, it may different in real code.
/quote]
Now, the problem is : pascal HL has CountPascalCodeFoldBlockOffset that used in too many lines.
This CountPascalCodeFoldBlockOffset are used together with CodeType (cfbtForDo, cfbtIfThen...) using sum operation.

It is a bug of pascal HL. keeping this constant will sacrifice other class portability.
[/quote]
/quote]
My sugested solution is deprecating this CountPascalCodeFoldBlockOffset, using portable logic/value: sfaFold.
You know, CountPascalCodeFoldBlockOffset is just a flag when the block has NOT sfaFold.


Is there another usage of CountPascalCodeFoldBlockOffset that I didn't know?
[/quote]

I wouldn't call it a bug. It just needs an accessors that returns the true value to the outside world. internally it is allowed to store whatever it wants.

And yes, that may mean it can not make 100% use of the base class.

It may be possible to get rid of it in pas hl, but it is good that it is there as similar usage may arise with any hl  for any reason.

pas hl is more complex than it looks, and the test case only scratches the surface, Making bigger changes may mean having to extend those test.

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Okay, it's not "a bug".
However, too late. I have removed CountPascalCodeFoldBlockOffset together with PasFoldLevelEnd, PasFOldMinLevel.
As replacement, there is a new property to the CodeFoldBlock : Foldable.


THe reason: I want to make Pascal HL more natural. mean it just similar as possible as another HL ability.
We can't make pas HL as that too special, which too hard to follow of creating new HL.




I am in thinking of, maybe we also need to bring PasFoldFixLevel together with LastLineCodeFoldLevelFix,
into base class. (as we did with other PasXxxxLevel properties)
the reason: Python HL (foldable) seem need it.
you know, in Pascal: multiple ansi comment can be hidden (fmHide) together with fmFold,
now in Python: multiple import lines should can be hidden too. AFAiK it need LasLineCodeFoldLevel, isn't it?
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5695
    • wiki
sorry but it will be a bit until I can review.

And then, it will need to be possible to differentiate between (different) refactor and new functionality. They need to be checked and applied individually.

x2nie

  • Sr. Member
  • ****
  • Posts: 478
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com

Nice. you may in traveling, etc.
If I were able to make svn patch, what are the priorities?


You know, I have a lot of changes.
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

A-M

  • New Member
  • *
  • Posts: 13
Hi dear Lazarus developers
i'm so sorry because of my absence
i was completely busy at my work however, i was visiting this topic sometimes

to be honest i'm benefiting from Lazarus at my job so i think i should compensate that and so i'm doing some works for (such as writing a Lazarus handbook)

about this matter (Colorizing SynEdit) as i can see ,dear x2nie you are doing the job as well with the help of maestro Martin  ;)
but if you think my re-entry into the topic can be useful anyway please write a brief description on what did you till now and what i can do (i tried reading last pages but it was not clear for me because i wasn't involved)

With the best regards.
Like a circle in a spiral
Like a wheel within a wheel
Never ending or beginning,
On an ever spinning wheel
Like the circles that you find
In the windmills of your mind