Key word "Continue" does not mark up ? lazarus / 9-Editor ---------------------------------------------------------------------- jamie · 2024-10-18 12:22 I noticed a common key word "Continue" does not mark up its color in the editor.  Is there a reason for this other than preference by the DEVS? ---------------------------------------------------------------------- Thaddy · 2024-10-18 12:29 ??? what do you mean,Jamie? ---------------------------------------------------------------------- PascalDragon · 2024-10-18 12:30 That's because Continue is not a keyword. Neither is Break nor Exit. All three are identifiers from the unit System and for example the following code is perfectly valid (though it shows that the highlighter of the forum has a bug, cause it shows Break in bold ): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program tkeyword; var  exit, break, continue: LongInt;begin  exit := 1;  break := 2;  continue := 3;end. ---------------------------------------------------------------------- Martin_fr · 2024-10-18 12:31 Technically it is not a keyword (as in "reserved words"). In the doc its listed under modifiers. Though its the odd one out in that list. https://www.freepascal.org/docs- html/ref/refsu3.html#x14-130001.3.3 That aside, I acknowledge that it might be useful. But it hasn't yet been done. You can add it as word in "used defined markup". And then in normal colors increase the priority for comment and string, and set the priority for the user defined markup between 0 and the comment/string priority. => That will do 99%. ---------------------------------------------------------------------- Martin_fr · 2024-10-18 12:33 "break" seems to be in ExtendedKeywordsMode => that can be toggled somewhere in the options. Same for: Exit and Continue ---------------------------------------------------------------------- jamie · 2024-10-18 12:59 It's strange that you say that about BREAK because BREAK isn't always marked from my obversions? I just inserted a BREAK in some code I am looking at and it did not markup. So maybe there is a problem elsewhere. Its seems that I remember Continue, Break being marked in Delphi, which is why I asked about it? ---------------------------------------------------------------------- Martin_fr · 2024-10-18 13:05 As I said, there is a setting. I had to look up the name "Highlight control statements as keywords" (in "Markup and Matches") ---------------------------------------------------------------------- jamie · 2024-10-18 13:14 I don't have that checked. But in any case I just noticed something. I went into the USER markup, selected AddList, there was before I did that an empty window to the right, but then I exited out of there before actually adding anything to the list. I saw what looked like some updates taking place, and now I don't see "Break" in bold any more. Now when I go into that option, it shows as a list with nothing in it. strange. ---------------------------------------------------------------------- carl_caulkett · 2024-10-18 13:23 Quote from: Martin_fr on October 18, 2024, 02:31:10 pmYou can add it as word in "used defined markup". And then in normal colors increase the priority for comment and string, and set the priority for the user defined markup between 0 and the comment/string priority. => That will do 99%. Ooh! I didn't know about "user defined markup". Now I can get "integer" show up in colors like "string" does 😉 Thanks Martin_fr 🙏🏽 UPDATE: However, there is a slight problem. Guess what happens if I set "char" to be a different color? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   else  begin    PrePtr := PresetTree.GetNodeData(Node);    case Column of    0: CellText := PrePtr^.PresetName;      1: CellText := PrePtr^.CC0.ToString;      2: CellText := PrePtr^.PGM.ToString;      3: CellText := PrePtr^.Characters;       // HINT <== here it is      4: CellText := '';    end;  end;  I can get round the problem by setting the custom color to be "case sensitive", but it would be good if the "user defined markup" code did not try to work for substrings... ---------------------------------------------------------------------- Martin_fr · 2024-10-18 13:46 Quote from: jamie on October 18, 2024, 03:14:44 pmI don't have that checked. But in any case I just noticed something. I went into the USER markup, selected AddList, there was before I did that an empty window to the right, but then I exited out of there before actually adding anything to the list. I saw what looked like some updates taking place, and now I don't see "Break" in bold any more. Ok, up until this post, I read your other posts as: You don't see break in bold, but you would like to see it in bold? You even did not get it bold, after PascalDragon observed it was bold... I am not sure how your "Add list" in user define markup may have changed that. Did you have other lists in the drop down already? The list in the config shows the pre-added words. If you define key-combos you can add session-specific words (but they will not be kept on restart). However you only get that if you have a list, and if some colors or style are defined on that list (and key combos, if words aren't pre defined). Quote from: carl_caulkett on October 18, 2024, 03:23:31 pmQuote from: Martin_fr on October 18, 2024, 02:31:10 pmYou can add it as word in "used defined markup". And then in normal colors increase the priority for comment and string, and set the priority for the user defined markup between 0 and the comment/string priority. => That will do 99%. Ooh! I didn't know about "user defined markup". Now I can get "integer" show up in colors like "string" does 😉 Thanks Martin_fr 🙏🏽 UPDATE: However, there is a slight problem. Guess what happens if I set "char" to be a different color? Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i       3: CellText := PrePtr^.Characters;       // HINT <== here it is I can get round the problem by setting the custom color to be "case sensitive", but it would be good if the "user defined markup" code did not try to work for substrings... You can check that word-boundaries should be matched (needs to be done for each word). You can also set priorities for colors, and put the markup at priority = 1 Then set strings and comment to priority = 2 And "char" wont color in strings and comments. ---------------------------------------------------------------------- carl_caulkett · 2024-10-18 14:34 Quote from: Martin_fr on October 18, 2024, 03:46:08 pmYou can check that word-boundaries should be matched (needs to be done for each word). You can also set priorities for colors, and put the markup at priority = 1 Then set strings and comment to priority = 2 And "char" wont color in strings and comments. So THAT'S what "Set bound at term start/end" means... I DID wonder 😉 ---------------------------------------------------------------------- jamie · 2024-10-18 14:59 @Martin_Fr I meant to say, "I never had that checked" ! But after entering the ADDLIST for the USER markup and not actually adding anything, I notice now I have a note in the right pane window "Add new Item", that was note there the first time in that menu.  And I no longer see "Break" in bold like I did randomly.  I suppose I could look at the source code of that section, but I think my old eyes will get glossed over before I notice anything relevant ---------------------------------------------------------------------- Martin_fr · 2024-10-18 15:27 Ok, I did not understand that you had it randomly bold. Not sure what may cause that. (You don't have "word at caret highlight" to set it bold, when you are at any break occurrence?). What you describe in the user-defined-markup sounds normal, but unrelated. https://wiki.lazarus.freepascal.org/IDE_Window:_Editor_User_Defined_Wo rds Except, I don't know why it made the break non-bold => but maybe it just caused a recalculation, because settings changed, and whatever else had been the cause got corrected. That you did not see  the "Add new item" before, means you had no list before, and therefore there would have been no highlights, and break would not have been affected. The markup can have any amount of "item lists" (item = word, part- word, phrase). All items in each list are highlighted with the color set in that list. Additionally session temporary items can be added from the editor via key-combo, if you define key combos (but that again needs a list, on which to define the keycombo) ---------------------------------------------------------------------- Thaddy · 2024-10-18 15:28 You should not have to check. Continue is part of the core Pascal syntax.(meaning it should never be modified or even modifiable) You are very right to raise that question. (That is not a display issue, but a real bug in the compiler, it seems, rather strange answer from PascalDragon) As usual I might be wrong, but in this case highly unlikely. (although it is not in ISO 7185) ---------------------------------------------------------------------- ASerge · 2024-10-18 15:44 Quote from: jamie on October 18, 2024, 02:22:25 pmI noticed a common key word "Continue" does not mark up its color in the editor. IDE Options/Editor/Display/Markup and Matches/Highlight control statement as keywords ---------------------------------------------------------------------- Thaddy · 2024-10-18 15:46 It is more fundamental than that.... ---------------------------------------------------------------------- WooBean · 2024-10-18 17:50 Quote from: Thaddy on October 18, 2024, 05:28:38 pm... As usual I might be wrong, but in this case highly unlikely. (although it is not in ISO 7185) @Thaddy, you are absolutely right (except unlikely). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Break;var Continue: integer;begin  Continue:=1;  while True do begin  inc(Continue);    if Continue>3 then System.Break;  end;  writeln(Continue); // prints 4  while Continue>0 do begin    dec(Continue);    if Continue=2 then System.Continue;    writeln(Continue); //2 omitted  end;  readln;end. ---------------------------------------------------------------------- Joanna · 2024-10-18 22:57 Quote from: ASerge on October 18, 2024, 05:44:50 pmQuote from: jamie on October 18, 2024, 02:22:25 pmI noticed a common key word "Continue" does not mark up its color in the editor. IDE Options/Editor/Display/Markup and Matches/Highlight control statement as keywords This is neat I got to add some more colors for begin ends  For those who aren’t Lazarus ide experts I’d like to add that it’s  tools/Options/Editor/Display/Markup and Matches ---------------------------------------------------------------------- MarkMLl · 2024-10-19 19:33 Quote from: Joanna from IRC on October 19, 2024, 12:57:21 amFor those who aren’t Lazarus ide experts I’d like to add that it’s  tools/Options/Editor/Display/Markup and Matches Putting in a quick "how to get there" is always valuable, although (and please note that I'm not finding fault here, just trying to suggest a documentation style) that could be improved by noting what version of the IDE the sequence applies to. MarkMLl ---------------------------------------------------------------------- Martin_fr · 2024-10-19 20:36 Quote from: MarkMLl on October 19, 2024, 09:33:33 pmQuote from: Joanna from IRC on October 19, 2024, 12:57:21 amFor those who aren’t Lazarus ide experts I’d like to add that it’s  tools/Options/Editor/Display/Markup and Matches Putting in a quick "how to get there" is always valuable, although (and please note that I'm not finding fault here, just trying to suggest a documentation style) that could be improved by noting what version of the IDE the sequence applies to. tools/Options/Editor/Display/Markup and Matches => Highlight control statement as keywords Since Lazarus 1.0.15 (or probably before) Up to an including 4.99 ---------------------------------------------------------------------- Thaddy · 2024-10-19 20:44 @WooBeanCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type bool = (maybe, notsure);const  false:bool = maybe;  true:bool = notsure;begin  writeln(false:6, true);// but  writeln(100 < 99);end. ---------------------------------------------------------------------- MarkMLl · 2024-10-19 21:03 Quote from: Martin_fr on October 19, 2024, 10:36:31 pmSince Lazarus 1.0.15 (or probably before) If you insist... it's not in the longlived 0.9 series, which didn't have a Tools -> Options menu entry. So somewhere around the laboured 0.9 -> 1.0 transition. MarkMLl ---------------------------------------------------------------------- WooBean · 2024-10-20 05:33 Quote from: Thaddy on October 19, 2024, 10:44:40 pm... @Thaddy, remark noted. Nice to share an opinion  that something obvious can be a little bit more complicated in fact. ---------------------------------------------------------------------- Joanna · 2024-10-20 08:08 Is it really ok to reuse true and false like that? It will interfere with boolean things. I’ve unintentionally hid things that shouldn’t be hidden when declaring keys for my resource strings . I really wish it wouldn’t let me do that.. ---------------------------------------------------------------------- MarkMLl · 2024-10-20 08:19 Quote from: Joanna from IRC on October 20, 2024, 10:08:45 amIs it really ok to reuse true and false like that? It will interfere with boolean things. I’ve unintentionally hid things that shouldn’t be hidden when declaring keys for my resource strings . I really wish it wouldn’t let me do that.. They're not reserved words. /Now/ do you see why some of us grumble that Pascal's type handling etc. is sloppy? MarkMLl ---------------------------------------------------------------------- cdbc · 2024-10-20 08:19 Hi @Joanna: Look at it this way - It's a compiler, /not/ a babysitter... Regards Benny ---------------------------------------------------------------------- MarkMLl · 2024-10-20 08:23 Quote from: cdbc on October 20, 2024, 10:19:28 am@Joanna: Look at it this way - It's a compiler, /not/ a babysitter... But you could apply the same argument to all type checking etc., hence "real men" use C or assembler, not Pascal. Anyway, this is getting /way/ off topic for the topic cited by OP, and if we want to get into "coding horrors" we should start a new thread. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2024-10-20 09:02 Quote from: jamie on October 18, 2024, 02:59:18 pmIts seems that I remember Continue, Break being marked in Delphi, which is why I asked about it? At least in Delphi 10.2 they are not. Though they have another nice gimmick: Continue has an arrow that points up after it and Break one that points down (see attached screenshot). Though it's not very intelligent, cause that errors will also appear at a variable declaration named Break or Continue. 😂 Quote from: Thaddy on October 18, 2024, 05:28:38 pmContinue is part of the core Pascal syntax.(meaning it should never be modified or even modifiable) You are very right to raise that question. (That is not a display issue, but a real bug in the compiler, it seems, rather strange answer from PascalDragon) As usual I might be wrong, but in this case highly unlikely. As usual you are indeed wrong. Neither in FPC nor in Delphi (did not check TP however) Continue, Break and Exit count as keywords. They are instead symbols declared in the System unit, just like Writeln or TypeInfo and thus one is free to redeclare them. Delphi behaves the same here. Quote from: Thaddy on October 18, 2024, 05:28:38 pm(although it is not in ISO 7185) Of course not, cause ISO Pascal does not know about them and neither does ISO Extended Pascal. Quote from: Joanna from IRC on October 20, 2024, 10:08:45 amIs it really ok to reuse true and false like that? It will interfere with boolean things. I’ve unintentionally hid things that shouldn’t be hidden when declaring keys for my resource strings . I really wish it wouldn’t let me do that.. True and False are not keywords, they are symbols inside the System unit thus according to the rules of the language one is free to redeclare them in other units. Just like for any other symbols the usual lookup rules will be followed. ---------------------------------------------------------------------- carl_caulkett · 2024-10-23 19:20 Just as a follow up question to this. How do you set a user defined term to show the defined color in live code but not in comments? I thought it had something to do with the priority setting, but a given setting value seems to be shared by an entire list. Here it is. @Martin_fr said... "You can check that word-boundaries should be matched (needs to be done for each word). You can also set priorities for colors, and put the markup at priority = 1 Then set strings and comment to priority = 2 And "char" wont color in strings and comments." ... but I'm having difficulties in making Martin's words correspond with what I see on screen! ---------------------------------------------------------------------- Martin_fr · 2024-10-23 20:06 Quote from: carl_caulkett on October 23, 2024, 09:20:46 pmJust as a follow up question to this. How do you set a user defined term to show the defined color in live code but not in comments? I thought it had something to do with the priority setting, but a given setting value seems to be shared by an entire list. You can have multiple list. All words that should be code only, but not comments => go into one list (or several for diff colors). And that list then gets the priority. However, you can not do - some words only source - other words only comments Because for only source, the comment must have higher prior than source. And for only comments it would be reverse. First: (Assuming you want to change foreground color / otherwise substitute foreground for what ever you need) - Go to Display > Colors - In the color tree find the entries for comment and string (as if you wanted to change their color) - For each of them   - At the bottom directly above the color-boxes, find the button "priority"   - change the priority for foreground to:  2 - Then go to User Defined Markup - Select your list - For the foreground color select priority: 1 In Lazarus 5.0 you will be able to add words for sources to the HL directly (up to 10 lists). However only full words, no part words, nor multi word. (Yes I mean 5.0 / not 4.0) ---------------------------------------------------------------------- carl_caulkett · 2024-10-23 21:40 Quote from: Martin_fr on October 23, 2024, 10:06:26 pmYou can have multiple list. All words that should be code only, but not comments => go into one list (or several for diff colors). And that list then gets the priority. I'll have to study your comment tomorrow, It's getting late and I'm feeling quite tired Quote from: Martin_fr on October 23, 2024, 10:06:26 pmIn Lazarus 5.0 you will be able to add words for sources to the HL directly (up to 10 lists). However only full words, no part words, nor multi word. (Yes I mean 5.0 / not 4.0) Interesting! Perhaps the Lazarus people are mindful of the fact that Delphi version 4 was a complete farce (as I recall) and didn't want to tempt fate by repeating the same version number ---------------------------------------------------------------------- Martin_fr · 2024-10-23 22:27 Quote from: carl_caulkett on October 23, 2024, 11:40:46 pmQuote from: Martin_fr on October 23, 2024, 10:06:26 pmIn Lazarus 5.0 you will be able to add words for sources to the HL directly (up to 10 lists). However only full words, no part words, nor multi word. (Yes I mean 5.0 / not 4.0) Interesting! Perhaps the Lazarus people are mindful of the fact that Delphi version 4 was a complete farce (as I recall) and didn't want to tempt fate by repeating the same version number You misread that. There will be a 4.0, and the branch for it has already been made. And because of that new features added now, will be for 5.0, as 4.0 is feature complete. ---------------------------------------------------------------------- Sieben · 2024-10-24 10:29 Another follow up question, if I may - why is ReadOnly marked up? I am always a bit irritated when I have a property name boldfaced, it somehow doesn't feel right, just like an abuse of a keyword. ---------------------------------------------------------------------- Martin_fr · 2024-10-24 12:46 Quote from: Sieben on October 24, 2024, 12:29:34 pmAnother follow up question, if I may - why is ReadOnly marked up? I am always a bit irritated when I have a property name boldfaced, it somehow doesn't feel right, just like an abuse of a keyword. Example code? Also test with Lazarus 4.0 (rc1 is coming soon) Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type  TFoo = class    property readonly: readonly read readonly write readonly;  end; "readonly" is not highlighted in 4.0 ---------------------------------------------------------------------- Sieben · 2024-10-24 13:11 I'm currently still stuck with 2.20 and can only provide a screenshot. Has it already been changed in 3.x...? ---------------------------------------------------------------------- Martin_fr · 2024-10-24 13:23 I only have the fixes-3 branch at hand... But it is very similar to 3.6, and should be the same for the HL. I tested my above code snippet, and "readonly" was not highlighted. So yes, that is fixed in 3.6 I do recall there were several fixes about keywords/modifiers in various expressions (including properties). I don't know which was fixed in exactly what version. Afaik there is some Pascal dialect / $mode in which a property can have a readonly keyword somewhere. I don't recall the details. (All I could find is a comment in codetools). So that is, why it was considered at all for HL, but wrongly so if it was an identifier. ---------------------------------------------------------------------- Sieben · 2024-10-24 13:27 Thanks a lot, that's good news. Maybe time to upgrade... although I'm still quite happy with 2.20. ---------------------------------------------------------------------- Zoran · 2024-10-27 16:19 Quote from: WooBean on October 20, 2024, 07:33:06 am... Nice to share an opinion  that something obvious can be a little bit more complicated in fact. Yes, it can be a little bit complicated... everybody's got an opinion. As there is a documentation mistake on reserved words (break, continue, exit, true, false are listed), I'm opening the discusion about keywords in separate topic: https://forum.lazarus.freepascal.org/index.php/topic,69065.0.html.