$ifdef highlighting lazarus / 9-Editor ---------------------------------------------------------------------- 440bx · 2025-12-05 03:15 Hello, Normally, when code is in a {$ifdef } {$endif} the highlighting intensity of changes depending on whether of not is defined. when using {$ifdef 0} {$endif} the is highlighted as if 0 is defined, which it isn't (0 is not an identifier that can be defined.) IOW, whatever is between {$ifdef 0} and {$endif} should probably be in low intensity to indicate it is not "active" instead of high intensity (which normally indicates code the compiler will compile.) comments welcome. ---------------------------------------------------------------------- Thaddy · 2025-12-05 06:04 Do you mean {$IF 0} // which starts a comment {$ifdef 0} does nothing. ---------------------------------------------------------------------- H₂SO₄ · 2025-12-05 06:06 I think it makes sense to treat  {$ifdef 0} / {$if 0}  as a special type of comment that allows for comment nesting without involving any strange compiler switches ---------------------------------------------------------------------- Thaddy · 2025-12-05 06:12 Yes it makes sense since you can define 0Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i begin{$define 0}{$ifdef 0}  writeln('test1');{$endif}{$if 0}  writeln('test2'); // never reached...{$endif}end.The two have completely different meaning...... This is also not a bug, but intentional. ---------------------------------------------------------------------- 440bx · 2025-12-05 06:34 this isn't about whether 0 is defined or not.  It is about the highlighting. whether 0 is defined or not the highlighting stays the same and, it shouldn't.  When defined what is in its domain should be bright otherwise it should be dim.  That's what happens with normal identifiers but does not happen with numerals (no reason why it shouldn't.) ---------------------------------------------------------------------- Thaddy · 2025-12-05 06:45 That is a shortcoming in the Lazarus IDE that does not handle {$if 0} correct. It is not treated as a comment. It does handle {$define 0}{$ifdef 0} correct. (As 0 is just like any other identifier as far as {$ifdef} is concerned.) ---------------------------------------------------------------------- 440bx · 2025-12-05 07:25 again: it's about the highlighting, nothing else. ---------------------------------------------------------------------- Thaddy · 2025-12-05 07:33 This was about the highlighting...nothing else. The observation you made is just releated to the highligthing of {$if 0} style comments. It does not affect code, only display is not correct. ---------------------------------------------------------------------- Martin_fr · 2025-12-05 10:26 The $IF and $IFDEF conditions are evaluated by codetools. There are a few that codetools currently doesn't handle. If 0 is one of them, the report it as an issue.  Actually for IFDEF that seems to be any numeric constant? ---------------------------------------------------------------------- 440bx · 2025-12-05 16:38 Quote from: Martin_fr on December 05, 2025, 11:26:52 amThe $IF and $IFDEF conditions are evaluated by codetools. There are a few that codetools currently doesn't handle. If 0 is one of them, the report it as an issue.  Actually for IFDEF that seems to be any numeric constant? That makes sense and, yes, the problem occurs for any numeric constant. ETA: reported. Link   : https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41944 Ticket:41944 ---------------------------------------------------------------------- Thaddy · 2025-12-06 18:26 There is nothing that I did not explained: all of this is intentional and documented. Maybe that the docs can be made clearer. ---------------------------------------------------------------------- paweld · 2025-12-07 07:49 @Thaddy: @440bx is right, for identifiers that are numbers, the highlighting does not work properly, regardless of whether the identifier is defined or not - see the attached screenshot. ---------------------------------------------------------------------- Thaddy · 2025-12-07 11:44 Yes, I never wrote otherwise, but the bug report by martin ---------------------------------------------------------------------- Thaddy · 2025-12-07 11:59 The "problem" with {$ifdef} is that everything that comes after a legal identifier string consisting of the  ' _', 0..9,'A..Z','a..z' is treated as a comment, so {$ifdef 5+1=true} resolves to 5 because +1=true is a comment. The string is cut off at the first character or symbol that is not in that set. In this case +. OTOH {$if 5+1=6} resolves to true because {$if} allows expressions. And there is where the whole discussion went wrong. All this is documented. The compiler handles the options correctly but codetools doesn't. Codetools should parse  ' _', 0..9,'A..Z','a..z' correctly, which is basically the set for any valid pascal identifier char except the escape char & ---------------------------------------------------------------------- paweld · 2025-12-07 13:47 Quote from: ThaddyThe compiler handles the options correctly but codetools doesn't. @440bx didn't mention the compiler at all; his report has been about highlighting in the editor from the very beginning. ---------------------------------------------------------------------- Martin_fr · 2025-12-07 13:52 Quote from: Thaddy on December 07, 2025, 12:59:03 pmThe "problem" with {$ifdef} is that everything that comes after a legal identifier string consisting of the  ' _', 0..9,'A..Z','a..z' is treated as a comment, so {$ifdef 5+1=true} resolves to 5 because +1=true is a comment. The string is cut off at the first character or symbol that is not in that set. In this case +. OTOH {$if 5+1=6} resolves to true because {$if} allows expressions. And there is where the whole discussion went wrong. All this is documented. The compiler handles the options correctly but codetools doesn't. Codetools should parse  ' _', 0..9,'A..Z','a..z' correctly, which is basically the set for any valid pascal identifier char except the escape char & Neither is the "+" syntax mentioned? So while your statement is correct by itself, it has nothing to do with this thread. Not sure what the purpose of it is meant to be.... ---------------------------------------------------------------------- Thaddy · 2025-12-07 14:11 The + syntax is part of the accepted expression syntax for {$IF} {$ifdef does not know expressions... In {$ifdef} it is the start of the comment in your example. Valid identifier characters are documented and is simply the set for any pascal identifier character,  _,0..9.A..Z,a..z (with & excluded since it is an escape) Is this so hard to follow? ---------------------------------------------------------------------- Thaddy · 2025-12-07 14:29 It has everything to do with the syntax highlighting which is not correct because it is not parsed correct: all I tried to explain the hwhole time. The compiler and fcl-passrc parse it correctly but are not highlighters. The colorizer should not {$ifdef and {$if the same, which it does now. ---------------------------------------------------------------------- 440bx · 2025-12-07 15:52 I find it disconcerting that the preprocessor accepts {$define 0} I expected that whatever follows the $define would be required to follow Pascal's valid identifier rules. That's not the only unexpected value it allows.  It allows just about any character, e.g, + For instance, the preprocessor "sort of" accepts 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 {$define +}{$ifdef +}  {$FATAL + is defined}{$endif} The define is accepted, OTH, the ifdef is rejected (unlike with a numeral.) The "variability" in what the preprocessor considers a valid identifier can make for some ambiguous and confusing situations. All that said, this thread's topic wasn't what the preprocessor considers a valid/possible name but, maybe that should be given some thought because it is currently a rather nebulous area, i.e, nowhere in the documentation does it say what is and isn't a valid preprocessor name/identifier. Conclusion 1, a $define should probably apply the same rules the $ifdef applies (it currently doesn't.) Conclusion 2, a valid preprocessor name/identifier should probably be limited to valid Pascal identifiers. ---------------------------------------------------------------------- Thaddy · 2025-12-07 16:43 Quote from: 440bx on December 07, 2025, 04:52:34 pmI expected that whatever follows the $define would be required to follow Pascal's valid identifier rules. But it does: anything in _,0..9,A..Z,a..z is a composing character of a valid Pascal identifier: what makes you think otherwise? Also: all macro elements are strictly not Pascal, but bolt-on's working with a separate parser/tokenizer (in this case two separate ones) The highlighter should do the same... You can unite {$ifdef} and {$ifopt}, but {$if} needs a different parser/tokenizer in the highlighter. One is a simple state machine, the other one is an expression parser. ---------------------------------------------------------------------- 440bx · 2025-12-07 17:00 Quote from: Thaddy on December 07, 2025, 05:43:47 pmBut it does: anything in _,0..9,A..Z,a..z is a composing character of a valid Pascal identifier Apparently you need to be informed of the obvious: the numeral zero is not a valid Pascal identifier.  Maybe you need to read the manual again to refresh your memory about what is an isn't a valid Pascal identifier. ---------------------------------------------------------------------- Thaddy · 2025-12-07 17:08 It is for the purpose of the macro language for {$Ifdef} completely valid. I simply do not understand your point at all: If you want the highlighting fixed, the highlighter *must* be able to parse both flavors. What you simply fail to admit is that the zero in {$define 0} can never leak to Pascal code: it is a macro definition. It is not part of the Pascal language. You are all being stubborn. Fix the highlighter by having two separate parser/tokenizers for the two types of defines. ---------------------------------------------------------------------- 440bx · 2025-12-07 18:09 Quote from: Thaddy on December 07, 2025, 06:08:05 pmIt is for the purpose of the macro language for {$Ifdef} completely valid. Nice try but, no cigar. Quote from: Thaddy on December 07, 2025, 06:08:05 pmI simply do not understand your point at all: Of course you don't.   Very convenient for you. Since you're on a roll... explain why {$define +} is acceptable given that {$ifdef +} is not.   It's going to be quite amusing to see what non-sense you come up with to justify that and, if you say "macros" again then provide an example that supports your point.  There is your homework... get to work!.