Change an existing lexer file or create a new lexer file?

503 views
Skip to first unread message

oirfe...@yahoo.co.in

unread,
Sep 7, 2016, 7:37:00 AM9/7/16
to scintilla-interest
Hi
I want to change an existing lexer lexBaan.cxx.
How to proceed with this?
Actually the language itself has evolved and has many new features... but, lexBaan.cxx is not updated and I dont have any contacts with the original authors.
Generally what is the approach?


I have attached the changed files as well.
Let me know what can be done.

PS: This uses the InListAbridged function from the recent commits.

Regards,

LexBaan.cxx
Scintilla.iface
baan.properties

Neil Hodgson

unread,
Sep 7, 2016, 8:12:19 PM9/7/16
to scintilla...@googlegroups.com
oirfeodent:

> I want to change an existing lexer lexBaan.cxx.
> How to proceed with this?
> Actually the language itself has evolved and has many new features... but, lexBaan.cxx is not updated and I dont have any contacts with the original authors.

Their email addresses are in the lexer comments so they could be contacted. Changing a lexer in incompatible ways can cause problems for current users.

> I have attached the changed files as well.
> Let me know what can be done.

Scintilla still builds with older compilers that do not support std::regex so it may not be included or used by lexers.

The has-section and is-abridged logic is complex and repetitive so its likely it can be improved. Can’t arrays be used instead of variables keywordsAbridged, keywords2Abridged, … . The text in DefineProperty calls is meant for end users so shouldn’t mention coding things like IsAWordChar. Couldn’t the abridged state be deduced from whether any keywords in that set contain ‘~’?

IsAnyOtherIdentifier is also quite complex.

Neil

oirfe...@yahoo.co.in

unread,
Sep 8, 2016, 5:24:08 AM9/8/16
to scintilla-interest, nyama...@me.com
Hi Neil,
> Their email addresses are in the lexer comments so they could be contacted. Changing a lexer in incompatible ways can cause problems for current users.
I have dropped a mail to them. The reason I mentioned was both of them are not quite active in the other forums where we discuss this stuff.
Anyway, is there a possibility to add this changes as a new lexer and wait for sometime (so existing users can get accustomed to) and then switch off the existing lexer.
Just an idea, if not feasible... lets wait.

> Scintilla still builds with older compilers that do not support std::regex so it may not be included or used by lexers.
I have removed std::regex.

> The has-section and is-abridged logic is complex and repetitive so its likely it can be improved. Can’t arrays be used instead of variables keywordsAbridged, keywords2Abridged, … .
can you have a look now, I have implemented them as arrays.

>The text in DefineProperty calls is meant for end users so shouldn’t mention coding things like IsAWordChar.
Removed that property itself.

> Couldn’t the abridged state be deduced from whether any keywords in that set contain ‘~’?
I have implemented this idea to remove one property... to check for the presence of ':'.
As far as implementing to check for the presence of '~'... not all the words in the WordList is going to have '~'.

> IsAnyOtherIdentifier is also quite complex.
I could not find an easier way of using this without a regex. Originally regex was used in IsAnyOtherIdentifier() but reverted back to this technique.
Anyhow, I have added some comments to make it easier to understand.

Hope this is fine.
I have attached the files again.
Let me know your views on this.

Regards,
Scintilla.iface
LexBaan.cxx
baan.properties

Neil Hodgson

unread,
Sep 8, 2016, 7:15:36 PM9/8/16
to scintilla...@googlegroups.com
oirfeodent:

> >The text in DefineProperty calls is meant for end users so shouldn’t mention coding things like IsAWordChar.
> Removed that property itself.

The text for …abridged… mentions ^ which shouldn’t be needed now ~ can do suffixes.

> > Couldn’t the abridged state be deduced from whether any keywords in that set contain ‘~’?
> I have implemented this idea to remove one property... to check for the presence of ':'.
> As far as implementing to check for the presence of '~'... not all the words in the WordList is going to have '~’.

strchr(wl, ‘~’)

Its the word list as a whole that either has one or more ‘~’ entries or doesn’t. If there are any ‘~’ entries then InListAbridged should always be used. Further, it wouldn’t work to have 2 different characters behave like ‘~’ in one WordList so the character should be a member of the class. So derive a WordListAbridged class from WordList that stores the marker character and has a state of isAbridged so WordListAbridged::Contains(const char *s) { return isAbridged ? InListAbridged(s, chMarker) : InList(s); }.

All functions must be static or anonymous namespace to prevent name leaks. StringSplit isn’t.

The headers should be ordered like scintilla/scripts/HeaderOrder.txt.

Neil

Neil Hodgson

unread,
Sep 8, 2016, 9:04:06 PM9/8/16
to scintilla...@googlegroups.com
oirfeodent:
> <Scintilla.iface><LexBaan.cxx><baan.properties>

From Visual C++:

..\lexers\LexBaan.cxx(36): error C2536: 'OptionsBaan::OptionsBaan::kwAbdridgedArr' : cannot specify explicit initializer for arrays [C:\u\hg\scintilla\win32\SciLexer.vcxproj]
..\lexers\LexBaan.cxx(36) : see declaration of 'OptionsBaan::kwAbdridgedArr'
..\lexers\LexBaan.cxx(37): error C2536: 'OptionsBaan::OptionsBaan::kwHasSectionArr' : cannot specify explicit initializer for arrays [C:\u\hg\scintilla\win32\SciLexer.vcxproj]
..\lexers\LexBaan.cxx(37) : see declaration of 'OptionsBaan::kwHasSectionArr'
..\lexers\LexBaan.cxx(36) : see declaration of 'OptionsBaan::kwAbdridgedArr'
..\lexers\LexBaan.cxx(37) : see declaration of 'OptionsBaan::kwHasSectionArr'
..\lexers\LexBaan.cxx(110): error C2899: typename cannot be used outside a template declaration [C:\u\hg\scintilla\win32\SciLexer.vcxproj]

Neil

oirfe...@yahoo.co.in

unread,
Sep 9, 2016, 2:24:09 AM9/9/16
to scintilla-interest, nyama...@me.com
Hi Neil,
> > >The text in DefineProperty calls is meant for end users so shouldn’t mention coding things like IsAWordChar.
> > Removed that property itself.

>   The text for …abridged… mentions ^ which shouldn’t be needed now ~ can do suffixes.
Removed the optionSet itself as it is not needed anymore, due to strchr(wl, ‘~’)  works.

> > > Couldn’t the abridged state be deduced from whether any keywords in that set contain ‘~’?
> > I have implemented this idea to remove one property... to check for the presence of ':'.
> > As far as implementing to check for the presence of '~'... not all the words in the WordList is going to have '~’.

>    strchr(wl, ‘~’)
I didn't realize this earlier, thx for the hint. Usage removes one more optionSet.

>    All functions must be static or anonymous namespace to prevent name leaks. StringSplit isn’t.
Funtion itself not needed anymore... removed.

>  The headers should be ordered like scintilla/scripts/HeaderOrder.txt.
Ordered the headers and realized not all or required. Removed the un-used ones. If required for some other compilers, let me know. Will add them.
Didn't knew this. Initialized inside, as individual array elements. Hope it is fine.

>     Its the word list as a whole that either has one or more ‘~’ entries or doesn’t. If there are any ‘~’ entries then InListAbridged should always be used.
> Further, it wouldn’t work to have 2 different characters behave like ‘~’ in one WordList so the character should be a member of the class.
> So derive a WordListAbridged class from WordList that stores the marker character and has a state of isAbridged so
> WordListAbridged::Contains(const char *s) { return isAbridged ? InListAbridged(s, chMarker) : InList(s); }.
I didn't get this point, correctly... So not sure what I should do after deriving the class. 
I assume, this derived class would make the below statement simpler.... But, do not know how to implement this.

"else if ((options.kwHasSectionArr[1] && (sc.ch == ':')) ? (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s1, '~') : keywords2.InList(s1)) : (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s, '~') : keywords2.InList(s))) {"

If not let me know. Attached all files again.

Regards,


LexBaan.cxx
baan.properties
Scintilla.iface

Neil Hodgson

unread,
Sep 9, 2016, 7:30:23 PM9/9/16
to scintilla...@googlegroups.com
oirfeodent:

> I didn't get this point, correctly... So not sure what I should do after deriving the class.
> I assume, this derived class would make the below statement simpler.... But, do not know how to implement this.
>
> "else if ((options.kwHasSectionArr[1] && (sc.ch == ':')) ? (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s1, '~') : keywords2.InList(s1)) : (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s, '~') : keywords2.InList(s))) {“

This is currently a 230 character expression. Making a method that encapsulates the choice between abridged and not changes

(options.kwAbridgedArr[1] ? keywords2.InListAbridged(s1, '~') : keywords2.InList(s1))

to

keywords2.Contains(s1)

Over the whole expression its

else if ((options.kwHasSectionArr[1] && (sc.ch == ':')) ? (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s1, '~') : keywords2.InList(s1)) : (options.kwAbridgedArr[1] ? keywords2.InListAbridged(s, '~') : keywords2.InList(s))) {

to

else if ((options.kwHasSectionArr[1] && (sc.ch == ':')) ? keywords2.Contains(s1) : keywords2.Contains(s)) {

which is less than half the length and easier to understand.

Neil

oirfe...@yahoo.co.in

unread,
Sep 12, 2016, 1:16:28 AM9/12/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Implemented your suggestions. Also removed the arrays and defined them in the class.
Can you have a look at the class WordListAbridged once... just to be sure. (I am not sure, if the destructor implementation is necessary there. though it works both ways).

Please have one more look and thx for your patience in explaining things. Thx.
Attached files again.

Regards,
LexBaan.cxx
baan.properties
Scintilla.iface

Neil Hodgson

unread,
Sep 12, 2016, 10:14:57 PM9/12/16
to scintilla-interest
oirfeodent:

> Implemented your suggestions. Also removed the arrays and defined them in the class.
> Can you have a look at the class WordListAbridged once... just to be sure. (I am not sure, if the destructor implementation is necessary there. though it works both ways).

Destructor doesn’t matter.

Again there are inline initial values for kwAbridged… Compile your code with —std=gnu++03 to to avoid C++11 features. atoi is in stdlib.h.

In WordListSet, there is a case statement that exists to produce a pointer to the particular word list. Then there is another case statement that refers to each of these by name. Just use the pointer.

Neil

oirfe...@yahoo.co.in

unread,
Sep 13, 2016, 9:55:25 AM9/13/16
to scintilla-interest, nyama...@me.com
Hi Neil,
> Compile your code with —std=gnu++03 to to avoid C++11 features. atoi is in stdlib.h

Done. I am using mingw32-make to compile... hope it doesn't matter.

> In WordListSet, there is a case statement that exists to produce a pointer to the particular word list. Then there is another case statement that refers to each of these by name. Just use the pointer.

Implemented to the extent of my understanding. Hope it is fine.
Attached files again.

Regards,

Scintilla.iface
baan.properties
LexBaan.cxx

Neil Hodgson

unread,
Sep 13, 2016, 9:15:55 PM9/13/16
to scintilla...@googlegroups.com
oirfeodent:

> > Compile your code with —std=gnu++03 to to avoid C++11 features. atoi is in stdlib.h
> Done. I am using mingw32-make to compile... hope it doesn't matter.

While the inline initialisation was removed, these fields still need to be initialised in the constructor. Use Cppcheck to find these sorts of problems.
http://cppcheck.sourceforge.net

Classes with names that may clash like WordListAbridged should be in an unnamed namespace. The cpp lexer puts all its classes except for the actual lexer in an unnamed namespace to avoid the possibility of clashes.

> > In WordListSet, there is a case statement that exists to produce a pointer to the particular word list. Then there is another case statement that refers to each of these by name. Just use the pointer.
>
> Implemented to the extent of my understanding. Hope it is fine.

(strchr(wl, '~') > 0) ? WordListAbridgedN->kwAbridged = true : WordListAbridgedN->kwAbridged = false;

This is fairly weird as it is using the ternary operator for flow control instead of as an expression. Try

WordListAbridgedN->kwAbridged = strchr(wl, '~') != NULL;

fold.cpp.syntax.based is owned by the cpp lexer so should not be reused by other lexers which should define their own names of the form fold.<lexer>.* or lexer.<lexer>.*. styling.within.preprocessor is also owned by cpp - it was defined before the lexer.<lexer>.* naming convention.

stdlib.h goes before string.h - see scripts/HeaderOrder.txt.

The baan.properties file sets global preferences like edge.mode. Language properties files should only set properties that are scoped to that language like keywords.$(file.patterns… and style.<lexer>… All the settings in the language properties files are dumped into one set so setting edge.colour may affect every other language or may be ignored because another language set it last.

Neil

Neil Hodgson

unread,
Sep 14, 2016, 2:59:28 AM9/14/16
to scintilla...@googlegroups.com
SCI_METHOD should only be used when implementing methods in interfaces which use this. Its there to allow some methods to be called between different compilers and languages. Its not needed for local classes and functions and is likely to lead to slower code.

Neil

oirfe...@yahoo.co.in

unread,
Sep 14, 2016, 4:31:03 AM9/14/16
to scintilla-interest, nyama...@me.com
Hi Neil,
>     While the inline initialisation was removed, these fields still need to be initialised in the constructor. Use Cppcheck to find these sorts of problems.
http://cppcheck.sourceforge.net
Done.

>    Classes with names that may clash like WordListAbridged should be in an unnamed namespace. The cpp lexer puts all its classes except for the actual lexer in an unnamed namespace to avoid the possibility of clashes.
Done.

> (strchr(wl, '~') > 0) ? WordListAbridgedN->kwAbridged = true : WordListAbridgedN->kwAbridged = false;
>
>     This is fairly weird as it is using the ternary operator for flow control instead of as an expression. Try
>
> WordListAbridgedN->kwAbridged = strchr(wl, '~') != NULL;
Changed it like above and it works.

>   fold.cpp.syntax.based is owned by the cpp lexer so should not be reused by other lexers which should define their own names of the form fold.<lexer>.* or
>  lexer.<lexer>.*. styling.within.preprocessor is also owned by cpp - it was defined before the lexer.<lexer>.* naming convention.
Ok. I noticed this, but did not give much of thought. Anyway, have added the new lexer specific stuff. Hope the fold.comment and so on are generic ones.
Let me know if it needs to be changed.

>    stdlib.h goes before string.h - see scripts/HeaderOrder.txt.
Done. Missed it when added again with gnu++03 option.

>    The baan.properties file sets global preferences like edge.mode. Language properties files should only set properties that are scoped to that language like
> keywords.$(file.patterns… and style.<lexer>… All the settings in the language properties files are dumped into one set so setting edge.colour may affect every other language
> or may be ignored because another language set it last.
OK. Didn't knew that. Done.

>   SCI_METHOD should only be used when implementing methods in interfaces which use this. Its there to allow some methods to be called between different compilers and languages. Its not needed for local classes and functions and is likely to lead to slower code.
Ok. Removed SCI_METHOD in Contains method.

Attached files again.

Regards,

LexBaan.cxx
baan.properties
Scintilla.iface

Neil Hodgson

unread,
Sep 17, 2016, 12:27:00 AM9/17/16
to scintilla-interest
oirfeodent:

> > fold.cpp.syntax.based is owned by the cpp lexer so should not be reused by other lexers which should define their own names of the form fold.<lexer>.* or
> > lexer.<lexer>.*. styling.within.preprocessor is also owned by cpp - it was defined before the lexer.<lexer>.* naming convention.
> Ok. I noticed this, but did not give much of thought. Anyway, have added the new lexer specific stuff. Hope the fold.comment and so on are generic ones.
> Let me know if it needs to be changed.

The convention is for folding properties to start with “fold.” so “fold.baan.syntax.based” instead of “lexer.baan.fold.syntax.based” since its shorter and separates the concerns more.

Its generally better for code to be removed rather than commented out. Its difficult for a maintainer to understand why there is the additional preprocessor folding code, for example.


Neil

Neil Hodgson

unread,
Sep 17, 2016, 12:30:20 AM9/17/16
to scintilla-interest
oirfe...@yahoo.co.in:

> <LexBaan.cxx><baan.properties><Scintilla.iface>

You are currently credited as “oirfeodent”. If you prefer some other name then please tell me.

Neil

oirfe...@yahoo.co.in

unread,
Sep 19, 2016, 12:38:33 AM9/19/16
to scintilla-interest, nyama...@me.com
>    The convention is for folding properties to start with “fold.” so “fold.baan.syntax.based” instead of “lexer.baan.fold.syntax.based” since its shorter and separates the concerns more.
Change Done.

>    Its generally better for code to be removed rather than commented out. Its difficult for a maintainer to understand why there is the additional preprocessor folding code, for example.
Commented lines removed. It was kept there as I believe originally it was moved from lexCPP. The #ifdef usage is very rare in baan. The changed folding has lots of usage scope.
Just kept it, if the rare usage is used by some one as a reminder. I can fetch it from the history of scintilla if required later. Thx.


>  <LexBaan.cxx><baan.properties><Scintilla.iface>
>    You are currently credited as “oirfeodent”. If you prefer some other name then please tell me.

Name is fine. Attached changed files again.

Regards,
Scintilla.iface
baan.properties
LexBaan.cxx

Neil Hodgson

unread,
Sep 22, 2016, 12:28:30 AM9/22/16
to Scintilla mailing list
oirfeodent:

> <Scintilla.iface><baan.properties><LexBaan.cxx>

Committed as
https://sourceforge.net/p/scintilla/code/ci/f30e4508da778d8680c37f9c4392eb1cbd876b2f/

Neil

Message has been deleted

oirfe...@yahoo.co.in

unread,
Sep 28, 2016, 5:16:49 AM9/28/16
to scintilla-interest, nyama...@me.com
> > <Scintilla.iface><baan.properties><LexBaan.cxx> 
>
>    Committed as
> https://sourceforge.net/p/scintilla/code/ci/f30e4508da778d8680c37f9c4392eb1cbd876b2f/

Thx for the commit.
There is bugfix and I have attached the LexBaan.cxx file with the required changes.
There is not any significant change, in such cases do you prefer a patch file or the whole file would do?

Attached the full file. Thx in advance for your perusal.

Regards,

PS: if you have received two notifications for this post, it is because I have attached the wrong file last time and deleted it.
LexBaan.cxx

Neil Hodgson

unread,
Sep 28, 2016, 10:50:14 PM9/28/16
to Scintilla mailing list
oirfeodent:

> There is bugfix and I have attached the LexBaan.cxx file with the required changes.

Change sets should have an explanation for maintainers as a “commit message". "There is bugfix” isn’t as useful as something like “Fixed folding for ‘select’ statement”.

> There is not any significant change, in such cases do you prefer a patch file or the whole file would do?

Best is a Mercurial changeset patch that includes context, attribution and a commit message. They are normally created using the ‘hg export’ command from a Mercurial repository. The first line in a commit message is displayed by Mercurial tools so should summarise the change.

They look like this:
http://www.scintilla.org/FixResume.patch

How to make:
https://www.mercurial-scm.org/wiki/TutorialExport

Next best is a patch in ‘unified’ format created with “diff —unified” or “hg diff” or by menu in GUI app.

Otherwise send whole files. Multiple files should be sent in a .zip archive.

> <LexBaan.cxx>

Committed:
https://sourceforge.net/p/scintilla/code/ci/0fd6719d2d9a9afb2ef6393458e57b132d0270ae/

Neil

oirfe...@yahoo.co.in

unread,
Oct 3, 2016, 5:53:14 AM10/3/16
to scintilla-interest, nyama...@me.com
Hi Neil,
I have attached a mercurial patch for "better handling of sub-queries folding".
Hope, I have created the patch correctly...

Attached the same.

Regards,

SubQueriesWrongFolding.patch

Neil Hodgson

unread,
Oct 3, 2016, 10:41:17 PM10/3/16
to scintilla-interest
oirfeodent:

> I have attached a mercurial patch for "better handling of sub-queries folding".
> Hope, I have created the patch correctly…

Yes, that applied nicely.
https://sourceforge.net/p/scintilla/code/ci/d2cd05d75e2ad1d61966dc3f5c883d0b527b60f4/

Neil

oirfe...@yahoo.co.in

unread,
Oct 19, 2016, 9:07:08 AM10/19/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Only after the release, I noticed that baan.properties file had the two fold parameters wrongly marked.
Even though the documentations are proper and clarify the file is wrong... I thought of patching it up just to clear.
This patch belongs to scite source actually.

Attached a patch for fixing the baan.properties file.

Regards,
wrongBaanProperties.patch

Neil Hodgson

unread,
Oct 19, 2016, 5:48:15 PM10/19/16
to scintilla-interest
oirfeodent:

> <wrongBaanProperties.patch>

Committed
https://sourceforge.net/p/scintilla/scite/ci/80ce725d31fc1dfce6c5a9b46a1e7b8a71a7a439/

Neil

oirfe...@yahoo.co.in

unread,
Oct 20, 2016, 7:16:30 AM10/20/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Thx for the commit.
Added section based folding based on the post release feedback and a Fix where Function Definition was shown as regular function.
Can you have a look, attached the patch file.

Regards,
sectionFoldingAndFunctionDefinitionFix.patch

Neil Hodgson

unread,
Oct 20, 2016, 7:36:16 PM10/20/16
to Scintilla mailing list
oirfeodent:

> Added section based folding based on the post release feedback and a Fix where Function Definition was shown as regular function.
> Can you have a look, attached the patch file.

The chPrev variable is not used.

Neil

oirfe...@yahoo.co.in

unread,
Oct 21, 2016, 12:59:24 AM10/21/16
to scintilla-interest, nyama...@me.com
hi Neil,

>> Added section based folding based on the post release feedback and a Fix where Function Definition was shown as regular function.
>> Can you have a look, attached the patch file.

>   The chPrev variable is not used.

Good catch, removed the variable.
However, I am not sure how to "hg export" two commits together.
So, attached two files and the _01.patch is the second commit to remove the variable.

Let me know, if this will work out.

Regards,


sectionFoldingAndFunctionDefinitionFix.patch
sectionFoldingAndFunctionDefinitionFix_01.patch

Neil Hodgson

unread,
Oct 23, 2016, 8:12:51 PM10/23/16
to scintilla...@googlegroups.com
oirfeodent:

> > The chPrev variable is not used.
>
> Good catch, removed the variable.

OK, committed:
https://sourceforge.net/p/scintilla/code/ci/2970b4305acf26b2dfa5bf8bde1119dd32e7322f/

> However, I am not sure how to "hg export" two commits together.
> So, attached two files and the _01.patch is the second commit to remove the variable.

For small unpublished changes like this its best to merge into (amend) the previous revision since adding and removing something not needed isn't interesting.

You can amend a revision when it hasn’t been pushed yet. If using the TortoiseHg GUI, the Commit button can be switched to Amend with the pull down. Then the amended revision can be exported.

If you have a sequence of changes where each change is interesting, select the revisions in the GUI and choose Export Selected… from the popup menu. This produces a sequence of revision#.patch files.

Neil

oirfe...@yahoo.co.in

unread,
Oct 25, 2016, 8:40:32 AM10/25/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Thx.
Attached two patches one for LexBaan.cxx. (foldDeclarationSectionParameterPreprocessorFix.patch)
  • Add new property for folding sections.
  • Expand keywords based folding to include declarations.
  • Preprocessors check if they are relevant to baan.
Another patch for baan.properties (sectionsFoldPropertiesBaan.patch) to include the new fold property.

Let me know of any comments.
foldDeclarationSectionParameterPreprocessorFix.patch
sectionsFoldPropertiesBaan.patch
Message has been deleted

Neil Hodgson

unread,
Oct 27, 2016, 12:29:40 AM10/27/16
to scintilla...@googlegroups.com
oirfeodent:

> <foldDeclarationSectionParameterPreprocessorFix.patch><sectionsFoldPropertiesBaan.patch>

Committed.
https://sourceforge.net/p/scintilla/code/ci/b428023242efbd61c1d332e99ac280e56431fc23/
https://sourceforge.net/p/scintilla/scite/ci/de8fb7a4bb17af5e22f82dfa3f8bf05717d8dd25/

Neil

oirfe...@yahoo.co.in

unread,
Oct 27, 2016, 5:32:56 AM10/27/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Thx for the commit. There is one last feature, which is subsection folding.
However there is a while loop to check the previous section was a sub or main section.
I could not get it working without this while loop. Let me know if this will be ok.

Attached the patch for the same (foldSubSectionsFixPreprocessor.patch).

Regards,

foldSubSectionsFixPreprocessor.patch

Neil Hodgson

unread,
Nov 4, 2016, 8:33:39 PM11/4/16
to Scintilla mailing list
oirfeodent:

> <foldSubSectionsFixPreprocessor.patch>

Committed.
https://sourceforge.net/p/scintilla/code/ci/63b397687df96da155f3f61a3c88d18a7de587f8/

Neil

oirfe...@yahoo.co.in

unread,
Nov 8, 2016, 3:45:36 AM11/8/16
to scintilla-interest, nyama...@me.com
Hi Neil,
One more feature, to fold inner levels of select clauses, defaulted to 0 in properties.
Attached the patch for the same.

Thx for your time so far.

Regards,
foldInnerLevelLexBaan.patch
foldInnerLevelBaanProperties.patch

Neil Hodgson

unread,
Nov 13, 2016, 9:13:27 PM11/13/16
to Scintilla mailing list

oirfe...@yahoo.co.in

unread,
Nov 18, 2016, 2:46:21 AM11/18/16
to scintilla-interest, nyama...@me.com
Hi Neil,
Attached a patch for a bug fix, where sections folding fails when comment placed between main & sub section.

Regards,
sectionsCommentFix.patch

Neil Hodgson

unread,
Nov 21, 2016, 12:36:40 AM11/21/16
to Scintilla mailing list
oirfeodent:

> Attached a patch for a bug fix, where sections folding fails when comment placed between main & sub section.
>
> Regards,
> <sectionsCommentFix.patch>

Committed:
https://sourceforge.net/p/scintilla/code/ci/ffb9fb8aeb775f40558f5c82f093096f205fc382/

Neil

oirfe...@yahoo.co.in

unread,
May 12, 2017, 8:11:51 PM5/12/17
to scintilla-interest, nyama...@me.com

Hi Neil,
Attached a patch where Comment is coloring the first character of <CR><LF> when "Show End of Line" option is enabled in Windows.
In Linux it works fine and I guess it should work in Mac as well.
If there is a better way to achieve that as well let me know, with out using '/r' and '/n' explicitly.
I have tested in windows and Linux. But I guess it should work in Mac as well.

Regards,

CommentsInWindowsColoringCR.patch

Neil Hodgson

unread,
May 15, 2017, 8:07:22 PM5/15/17
to scintilla-interest
oirfeodent:
The patch doesn’t work at all for me. Its using the wrong form for escape sequence: ‘/r’ instead of ‘\r’.
https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences

Patches should have old code removed instead of commented out. Leaving code commented out just leads to the file becoming messy and difficult to read. The source code control system (Mercurial for Scintilla) keeps all the old code so it can be recovered if there is a problem.
https://sourceforge.net/p/scintilla/code/ci/2042f082bf9250e97bde2905102e77adc0493bd6/log/?path=/lexers/LexBaan.cxx

Neil

oirfe...@yahoo.co.in

unread,
May 15, 2017, 9:25:17 PM5/15/17
to scintilla-interest, nyama...@me.com
Hi Neil,
> The patch doesn’t work at all for me. Its using the wrong form for escape sequence: ‘/r’ instead of ‘\r’
Thx, is fixed now.

> Patches should have old code removed instead of commented out. Leaving code commented out just leads to the file becoming messy and difficult to read.
> The source code control system (Mercurial for Scintilla) keeps all the old code so it can be recovered if there is a problem.
> https://sourceforge.net/p/scintilla/code/ci/2042f082bf9250e97bde2905102e77adc0493bd6/log/?path=/lexers/LexBaan.cxx
Understand, removed it. I just overlooked it, sorry.

The new patch is amended to the existing commit.
If it is not working let me know, I will create a new patch with a single commit.

Regards,


CommentsInWindowsColoringCR_v1.patch

Neil Hodgson

unread,
May 16, 2017, 12:34:13 AM5/16/17
to scintilla-interest
oirfeodent:

> The new patch is amended to the existing commit.
> If it is not working let me know, I will create a new patch with a single commit.

OK, committed.
https://sourceforge.net/p/scintilla/code/ci/13d9f35748e830e4313ee4caf9130c004ceb0cdc/

Neil

Message has been deleted

oirfe...@yahoo.co.in

unread,
May 18, 2017, 5:15:27 PM5/18/17
to scintilla-interest, nyama...@me.com
Hi Neil,
Thx for the commit, attached another patch for proper Hex and Exp representation.
Let me know if there are any issues.

PS: I have deleted the previous message as I missed adding the '+'.
As of now, the attached patch (Hex_Exp_number_handling_v2.patch) is the only valid patch.

Regards,

Hex_Exp_number_handling_v2.patch

Neil Hodgson

unread,
May 18, 2017, 6:38:54 PM5/18/17
to scintilla-interest
oirfeodent:
> <Hex_Exp_number_handling_v2.patch>

Using literal numbers 101 and 120 instead of character constants like ‘e’ and ‘x’ is quite strange.

Neil

oirfe...@yahoo.co.in

unread,
May 19, 2017, 12:45:03 PM5/19/17
to scintilla-interest, nyama...@me.com
Hi Neil,

> > <Hex_Exp_number_handling_v2.patch>
>
>    Using literal numbers 101 and 120 instead of character constants like ‘e’ and ‘x’ is quite strange.
Replaced them, didn't realize it. Thx.

Attached amended patch.

Regards,

Hex_Exp_number_handling_v3.patch

Neil Hodgson

unread,
May 21, 2017, 7:56:13 PM5/21/17
to scintilla-interest
oirfeodent:

> <Hex_Exp_number_handling_v3.patch>

OK, applied:
https://sourceforge.net/p/scintilla/code/ci/002391011fa657016b198153f0fde2dfd25cbdf2/

Neil

oirfe...@yahoo.co.in

unread,
May 25, 2017, 4:34:59 AM5/25/17
to scintilla-interest, nyama...@me.com
Thx Neil, I have one question.
How to implement string line continuation, if the continuation symbol is present on the first char of second line... instead of the last char of first line.

I have noticed, most languages has the below structure...
string a = "Hi, I am a \
String"

In the above case as the lexing is happening in the current line, we can identify when to Continue the string and when to convert it to STRINGEOL.
In case of below example, the lexing does not know if the next line is going to be a continuation or should it lex the current line as STRINGEOL.
string a = "Hi, I am a
^String"

Any samples/pointers how can it be achieved?
Basically, I want to change the lex state of the previous line... when the actual lexing is happening on the ^String" line in this case.

Regards,
 

Neil Hodgson

unread,
May 26, 2017, 7:31:05 PM5/26/17
to scintilla-interest
oirfeodent:

> How to implement string line continuation, if the continuation symbol is present on the first char of second line... instead of the last char of first line.

You can look forward at the end of the line. Possibly use the LineStart and SafeGetCharAt methods on LexAccessor to read the first character of the next line. Or GetRelative on the StyleContext.

Its better to get it right when processing a line than to fix it up later.

Neil


oirfe...@yahoo.co.in

unread,
May 29, 2017, 1:28:05 AM5/29/17
to scintilla-interest, nyama...@me.com
OK, Thx. I will check the possibility.

Regards.

oirfe...@yahoo.co.in

unread,
Jul 3, 2017, 8:52:36 AM7/3/17
to scintilla-interest, nyama...@me.com
Hi Neil,
Attached  a patch for fixing SCE_BAAN_NUMBER display bug when followed by an operator.

Anything additional needs to be done for the LongTerm3 branch or lexer files will go to both the branches.
If anything needs to be done, let me know the procedure as well. Thx

Regards,

Baan_NumberFollowedByOperatorBug.patch

Neil Hodgson

unread,
Jul 3, 2017, 8:19:04 PM7/3/17
to scintilla-interest
oirfeodent:

> Attached a patch for fixing SCE_BAAN_NUMBER display bug when followed by an operator.

Committed as
https://sourceforge.net/p/scintilla/code/ci/5a311da5df4077a7666cbfede428d8f29a6d14e6/

> Anything additional needs to be done for the LongTerm3 branch or lexer files will go to both the branches.
> If anything needs to be done, let me know the procedure as well. Thx

OK, I have added you to admins of the Scintilla group on SourceForge so it should be possible for you to clone the repository (as SourceForge user Oirfeodent), switch to the LongTerm3 branch, make the change, commit it, then push the result. Using a GUI client like TortoiseHg can make this easier but you may still have to read up a bit on the Mercurial site about branches.

Neil

oirfe...@yahoo.co.in

unread,
Jul 5, 2017, 5:41:43 AM7/5/17
to scintilla-interest, nyama...@me.com
Hi Neil,
I have committed the LongTerm3 Branch. Can you please have a look on the commit, if it looks fine.


Regards,

Neil Hodgson

unread,
Jul 5, 2017, 5:51:03 PM7/5/17
to scintilla...@googlegroups.com
oirfeodent:

> I have committed the LongTerm3 Branch. Can you please have a look on the commit, if it looks fine.
>
> https://sourceforge.net/p/scintilla/code/ci/c534665d5d3434bef08e400a93bfc5db8bb2d548/

That is correct.

Neil

oirfe...@yahoo.co.in

unread,
Aug 29, 2017, 9:45:20 AM8/29/17
to scintilla-interest, nyama...@me.com
Hi Neil,
Attached a patch for fix, where the lexing needs to be done only for functions.
Let me know, if any issues.

Regards,


baanLex_OnlyColoriseFunctions.patch

Neil Hodgson

unread,
Aug 30, 2017, 4:04:24 AM8/30/17
to Scintilla mailing list
oirfeodent:

> Attached a patch for fix, where the lexing needs to be done only for functions.
> Let me know, if any issues.

OK, committed to default:
https://sourceforge.net/p/scintilla/code/ci/d04b3417f375bc08abcbc7f1853a89faf11e725d/

Neil

oirfe...@yahoo.co.in

unread,
Oct 13, 2017, 5:34:56 AM10/13/17
to scintilla-interest
Hi Neil,
Attached a patch for some new additions to the language, as pre-processors.
Both lexing and folding changed.

Regards,
LexBaan_NewPreProcessorAddedRecently.patch

Neil Hodgson

unread,
Oct 14, 2017, 5:43:02 PM10/14/17
to scintilla...@googlegroups.com
oirfeodent:

> Attached a patch for some new additions to the language, as pre-processors.
> Both lexing and folding changed.

OK:
https://sourceforge.net/p/scintilla/code/ci/d9f8dc43cc9ddb65b7fa2da17aa965c426a3a74d/

It benefits future maintainers to include a documentation link for new features along with the patch. Linking to official documentation is best but could be to a mailing list entry. I couldn’t find anything in a web search for “baan ‘context_on’”.

Neil

Reply all
Reply to author
Forward
0 new messages