Second keyword list for Pascal possible?

peterme
2013-08-18
2013-11-06
  • peterme

    peterme - 2013-08-18

    For distinct highlighting of certain keywords i tried to define a seocnd keyword list for Pascal following the method that had been occasionally described in Forum's threads
    (defining an "instre2" list in langs.xml, and using it for an "INSTRUCTION WORD2" styleID="15" in stylers.xml).
    -
    Of course that does not work, just as described by other users trying similar attempts.
    -
    It had been said that it is due to the hardcodings in the scintilla SciLexer.dll.
    So, i did a look into the scintially "pascal.properties" picked up from an "wscite334.zip".
    Indeed, only one keywordclass.pascal apperently is provided here.
    So, apparently no chance ....
    Moreover, i was not able to add a new keyword subject to be highlighted if it is not provieded by the property file that is compiled into the SciLexer.dll.
    -
    My question is: is that really so? Is the npp's highlighting configuration so much dependent on the settings from the scintialla dll? Isn't there any chance to achieve a second keyword list, some workaround, or is it possible ro request a second keyword list and how?

     
  • Loreia2

    Loreia2 - 2013-08-19

    Hi peterme,

    if you look at Scintilla code, you will find this line:

    ~~~~~~~~~~~~~~~~~~
    WordList& keywords = *keywordlists[0];
    ~~~~~~~~~~~~~~~~~~~

    So, just one keyword list is possible.
    Workaround would be to try to define Pascal using UDL module (Languages / Define your language).

    BR,
    Loreia

     
  • peterme

    peterme - 2013-08-19

    Hi Loreia,
    thanks for confirmation; i suspected that ..
    -
    So i tried to learn UDL and basically was successful, except one only ugly thing:
    you won't be able to define Pascal resp. Delphi Preprocessor statements for a distinct highlighting,
    as they are a kind of 'dialect' of the multiline comments:
    multiline comment start: {
    multiline comment end: }
    single line comment: starts with: //
    Preprocessor statements: start with: {$
    sample:
    {$DEFINE mystuff}
    or
    {$IFDEF mystuff}
    {$UNDEF otherstuff}
    {$ENDIF}
    -
    ==> So, being able to define a second multiline comment set: start with: {$ end with: }
    or - simply - a second single line comment pattern: start with {$
    would give the chance to highlight preprocessor statements in a distinct color.


    A seecond point (suggestion about number detection):
    Within the following expressions Numbers won't be recognized:
    MinWidth := 60; // due to the ;
    SetBounds(0, 0,60, 100); // due to: ( ) ,
    ... unless we add the ; ( ) , to the Operaters, which appears to be a little bit
    weird and may lead to other conflicts or problems.
    ==> So, for Numbers, why not give the possiblity to define extra delimiter tags
    in addition to the white space?

     
  • Loreia2

    Loreia2 - 2013-08-20

    Hi peterme,

    delimiters and comments are the same thing, in fact UDL3 won't even have comments. See examples here: http://udl20.weebly.com/delimiters.html

    You must define operators if you want those numbers recognized. Why is weird and what kind of conflicts do you get?

    BR,
    Loreia

     
  • peterme

    peterme - 2013-08-20

    Hi Loreia,

    many thanks, i appreciate your attention! My findings after hours of testing are as follows (and i'm happily awaiting any hints):

    Minor problem: number constants not surrounded by white space
    -> ok = solvable by defining the appropriate operators: ; , ) (

    Major problem: comments vs. preprocessor statements:
    multiline comment tags are: { and } // curly brackets
    but patterns like {$IFDEF blabla}
    {$WARNINGS OFF}
    should appear in a different color
    --> solvable, but only if i do not define comments (block comments)
    but only if i define delimiters like
    1: begin: ${ end: ((EOL)) .. color green ..
    2: begin: { end: } .. color brown ..

    So far, so really good (va bene!) regarding the highlighting :-)
    But at that point (because not using block comments) my MAIN PROBLEM appeared:
    The folding quality comes completely down, in comparison with the native Pascal definition.
    Now, i was no longer able to fold lines between: { and: }
    resp. something like:
    {$IFOPT D+} and a lot of equivalents: eg. {$IFDEF , {$IFNDEF and so on
    {$R+} { Range Checking - On - if compiled with Debug Information }
    {$ELSE}
    {$R-} { Range Checking - Off - if compiled without Debug Information }
    {$ENDIF}
    as it was possible before when applying Pascal language.
    How to fold this comment resp. preproc stuff now, sigh, using some/which regexps?

    Other findings between:
    a) about case sensitivity of keywords:
    you really must pay attention on casing (eg. "public" vs. "Public" ->
    both need to be defined as keywords. Hhm ... that's not needed with the standard langs.xml).

    b) about recognition of keywords:
    Why??? when defining keywords like: message Message
    does it recognize it in terms like: SendMessage
    so that e.g 'Send' appears in blue and 'Message' in red?

    c) collisions between keyword list styles and folding in group 1 style:
    .1. eg, keyword list 4th group: .. try except finally stdcall -> "try" should appear in style red
    .2. folding in group 1 style: begin try // style: blue
    ---> "begin" should appear in blue, that' ok, but i wanted to have
    "try" in red, as defined individually in the 4th group, ... and not in blue ...
    I only did that definition for to have the folding, but not for to see them all in the same style ..
    How many folding groups i do have avaiable for to differentiate colors?
    (Suggestion: let's define styles in the keyword lists and folding behaviour in the folding groups; don't mix)

     
  • Loreia2

    Loreia2 - 2013-08-21

    Hi peterme,

    1. I am afraid that defining operators in unavoidable
    2. Define it like this;

    delimiter 1: begin: $ end: ((EOL)) .. color green ..
    comment: begin: { end: } .. color brown ..

    Set nesting for comment to include Delimiter1.

    1. Just select "ignore case" then.
    2. How did you define "message"? As keyword1 type?
    3. If "begin try" is folding string, than it will be colored as folding type. You can't have folding keywords colored as some other type. This could be solved with multiple folding groups, but no one ever asked for such a thing.

    (Suggestion: let's define styles in the keyword lists and folding behaviour in the folding groups; don't mix)

    I don't quite understand this. Folding type is just another UDL type, the only difference is that it has folding quality. Other than that folding keywords are just another keywords and they have styler of their own.

    BR,
    Loreia

     
  • peterme

    peterme - 2013-08-21

    Hi Loreia,

    1. about the case sensitivity: ouch - i simply didn't see that checkbox; mea culpa; thanks!

    2. "SendMessage": simply put "Message" within the Folding in code 1 style "Open"
      and you will have that effect; but better let's explain with another sample:
      Folding in code 1 style (style red): Open: begin Close: end
      --> will a) fold and b) highlight the term "tatabegin"
      where "tata" will appear in the default color and "begin" in red ....
      If you want to fold a block starting with "try", it will fold and highlight incorrectly the line:
      FileCtrl, Registry,

    3. The proposal about the preprocessor statement ("define it like this"):
      yes, it works, but in difference to my solution not quite as expected
      as the preceding "{" itself is excluded from the preprocessor color style (eg. brown).
      Sample: {$DEFINE blabla "{" in green (comment), $DEFINE blabla in brown
      By that reason i did not define a block comment style at all, but use the
      delimiter style for that purpose.

    4. Multiple folding groups for individual colors for several folding tags/items?
      Not so elegant, but from the folding group i would expect only directives
      for folding and not for color (style).
      Why not allow the rule: if a style is explicitely defined elsewhere, eg.
      by a keyword list, and it appears within a folding group too, then don't
      apply the style onto that term, but only do the folding.
      Keep in mind that we have a limited number of folding groups and so
      potentially a list of items herein with maybe different styling needs.

    5. Another finding about comments & folding:
      if a comment block as candidate for folding is directly preceeded
      by another comment (i see that very oftenly), then the folding will not happen.
      If you enter a newline before (just for test), the folding will be done ...

    6. I can fold using an item list within Folding in code 1 style: eg.: begin try class(
      So, blocks starting with begin (resp. tatabegin ...), try, class ( and so on
      will be folded. Unfortunately, i did not succeed to fold a block starting with "{" (with other words:
      a comment block; keep in mind that i did not define comment block itself as of #3).
      Why does the folder engine processese "begin", but not "{"?
      If it only would accept "{", sigh ....

     
  • Loreia2

    Loreia2 - 2013-08-23

    Hi peterme,

    1. OK, that one is done :-)
    2. Folding in code 1 is meant for folding points that are based on Operators (like curly braces in C), Folding in code 2 is meant for folding points that use keyords. Also, notice that multi part keywords must be enclosed in quotes (read in documentation about the difference between single and double quotes when defining multi part keywords)
    3. yeah, that's the downside of it, but in UDL2 that's the best you can get. UDL3 will have foldable delimiters. Only then you will have full support for what you are trying to do.
    4. UDL is simply designed differently, allowing something like this would mean significant changes to UDL algorithm. Would two (or more ) folding groups solve your problem?
    5. You don't fold a comment, you fold a block of consecutive comment lines. This feature mimics Visual studio way of handling comments.
    6. Please read documentation throughly. You are trying to use advanced features of UDL but that is not possible without a peak in documentation. It won't be long, I promise :-), and everything is explained through examples.
      Quick explanation: define curly braces as Folding in code 1 type.

    BR,
    Loreia

     
    Last edit: Loreia2 2013-08-23
  • peterme

    peterme - 2013-08-24

    Hi Loreia,

    again, really many thanks for your attention!

    ad 2: bingo, that does the job - done .. :-)

    ad 3: for me the issue is obsolete when not using the comment style for styling of block comments,
    but using the definition of delimiters instead just as i described above

    ad 4: yes. two more folding groups (each for folding in code 1 style as well as code 2 style) probably
    would allow an individual highlighting of keywords that are, at the same time, used as folding Open/Close tags (but i'm not quite finished with my testings ..; so maybe three ..)

    ad 5: speaking in terms of "comments" (regarding the meaning) without using the comment style is, indeed. misunderstandable, sigh ..
    Three cases have to be distinguished:
    a) a line comment, or a consecutive series of line comments!, are of course probably not object to be necessarily folded ...
    pascal syntax 1: line starting with: //
    pascal syntax 2: line starting with: { and ending with: }
    b) a block comment, containing mulitple lines between { and }
    which are expected not to occur in the same line -> the start of this block should be foldable
    c) another multiline block comment maybe directly following the block comment b. Upfrom the start of this block comment
    identified by: { this one itself should be foldable again.
    The standard pascal styler handles that correctly (in fact it even detects a series of line comments and offers
    a folding upfrom the first one). An occurence of empty lines (or no empty lines) between this variants
    should not be relevant for the folder detection.

    ad 6: About the documentation, you are right, but until now it was not so indepth that i was able to find the solutions for my special issues.
    "Define curly braces as Folding in code 1 type"
    No sir, not quite, due to a conflict:
    - if i define curly braces within 'Folding in code 1 type', the folding appears to be correct. But not the colouring
    (the stuff between the curly braces is keyword highlighted as assumed to be code. Only the braces are formatted).
    - if i define curly braces within the delimiters page, the colouring is correct. But no folding happens
    - if i define both, the colouring is correct, but no folding happens -> the setting in Folding in code 1 type is simply ignored
    ==> Is it somehow possible to make the folding happen just as requested in 'Folding in code 1 type' AND
    keep the formatting directives about the same tags from the delimiters page, if any?

    For to summarize my facit in short here:
    - assuming we had three (maybe four) folding group definitions available
    - and could find a solution for #6 (curly braces, fold and color)
    the result would be nearly perfect :-)

    Best Regards!
    Peter

     
  • Loreia2

    Loreia2 - 2013-08-28

    Hi Peter,

    again, really many thanks for your attention!

    No problem, I answer a lot of support e-mails for UDL.

    ad 2: bingo, that does the job - done .. :-)

    One more done. Nice :-)

    ad 4: yes. two more folding groups (each for folding in code 1 style as well as code 2 style) probably
    would allow an individual highlighting of keywords that are, at the same time, used as folding Open/Close tags (but i'm not quite finished with my testings ..; so maybe three ..)

    OK, I am convinced. UDL 3 will have multiple Folding groups

    ad 5: speaking in terms of "comments" (regarding the meaning) without using the comment style is, indeed. misunderstandable, sigh ..
    Three cases have to be distinguished:
    a) a line comment, or a consecutive series of line comments!, are of course probably not object to be necessarily folded ...
    pascal syntax 1: line starting with: //
    pascal syntax 2: line starting with: { and ending with: }
    b) a block comment, containing mulitple lines between { and }
    which are expected not to occur in the same line -> the start of this block should be foldable
    c) another multiline block comment maybe directly following the block comment b. Upfrom the start of this block comment
    identified by: { this one itself should be foldable again.
    The standard pascal styler handles that correctly (in fact it even detects a series of line comments and offers
    a folding upfrom the first one). An occurence of empty lines (or no empty lines) between this variants
    should not be relevant for the folder detection.

    This is an area where UDL3 will need some improvment. So far (UDL2) it was easy to identify a comment. UDL3 will simply have foldable delimiters (an option in each delimiter), so it wwill need some additional logic regarding folding. Can you do me a favor? Please, make few screen shots of each combination of foldable comments in Pascal Lexer? I know I could do it myself, but I am so busy, I hardly have time to answer few e-mails (it took me days to answer this one).

    ad 6: About the documentation, you are right, but until now it was not so indepth that i was able to find the solutions for my special issues.
    "Define curly braces as Folding in code 1 type"
    No sir, not quite, due to a conflict:
    - if i define curly braces within 'Folding in code 1 type', the folding appears to be correct. But not the colouring
    (the stuff between the curly braces is keyword highlighted as assumed to be code. Only the braces are formatted).
    - if i define curly braces within the delimiters page, the colouring is correct. But no folding happens
    - if i define both, the colouring is correct, but no folding happens -> the setting in Folding in code 1 type is simply ignored
    ==> Is it somehow possible to make the folding happen just as requested in 'Folding in code 1 type' AND
    keep the formatting directives about the same tags from the delimiters page, if any?
    For to summarize my facit in short here:
    - assuming we had three (maybe four) folding group definitions available
    - and could find a solution for #6 (curly braces, fold and color)
    the result would be nearly perfect :-)

    For this you will need to wait untill UDL3 is ready for beta testing. UDL3 will have foldable delimiters. UDL2 is not good enough for this task.

    BR,
    Loreia

     
  • peterme

    peterme - 2013-08-28

    Hello Loreia,

    of course ... the screenshots attached (zip file; npp_screenshot1.png, npp_screenshot2.png).
    I did set the comment colours differently, for to see the distinctions better.
    Btw, in the pascal styler there are 3 different comment styles and 2 different
    preprocessor styles available, but only one color for 110 keywords. Crazy!
    This is my only problem with the pascal styler.
    So, in parallel i proposed a change request on the scintilla side (*); -> workins sample, tested successfully with scite! See scite_screenshot.png -> the keywords colorized red are added by that ...
    But i feel the scintilla people won't acccept.

    Anyhow. I'm convinced the UDL is a very cool and good thing, so i'm waiting now for the v3 beta :-)
    How to get informed when it might be ready for testing?

    Best Regards,
    Peter
    (*) URL: http://sourceforge.net/p/scintilla/feature-requests/1013/

     
  • peterme

    peterme - 2013-11-04

    Regarding the original wish for a second keyword list for Delphi/Pascal:
    can anybody give advice if the following Scintilla change release 3.3.6
    (as of http://www.scintilla.org/ScintillaHistory.html) is directly usable
    in N++ ?
    Added functions to help convert between substyles and base styles and between secondary and primary styles. SCI_GETSTYLEFROMSUBSTYLE finds the base style of substyles. Can be used to treat all substyles of a style equivalent to that style. SCI_GETPRIMARYSTYLEFROMSTYLE finds the primary style of secondary styles. StyleFromSubStyle and PrimaryStyleFromStyle methods were added to ILexerWithSubStyles so each lexer can implement these.


    (The change refers to thread: http://sourceforge.net/p/scintilla/feature-requests/1013/)

     
  • Loreia2

    Loreia2 - 2013-11-06

    Hi Peter,

    unless someone changes Scintilla's Pascal lexer, you won't be able to see any difference in Scintilla's coloring of pascal files.

    Can't you make some Pascal expert interested in this? It shouldn't be too much work to add another keyword list to pascal lexer. Isn't there some big Pascal forum where you can find Scintilla users interested in the change?

    BR,
    Loreia

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks