Syntax highlighting in the IDE

[TLis]

I have noticed, that the IDE does not highlight the "then", "else", "to" (in a DO loop) keywords. Why aren't they coloured as "iff", "endiff" or "do" are.

 

[rconn]

None of those are keywords in a DO statement. (Except for "to", which is only valid in 1 out of 13 possible DO syntaxes -- and the editor isn't able to determine when that is true.)

 

[TLis]

None of those are keywords in a DO statement. (Except for "to", which is only valid in 1 out of 13 possible DO syntaxes -- and the editor isn't able to determine when that is true.)

I see, I wasn't clear enough. Only "to" may be a keyword in a DO statement, that's right. What about IFF statement then? The "THEN" keyword is mandatory, so I believe it could be recognised properly. The "ELSE" keyword, when present, must be alone on the line - this, I presume, gives also the editor to ability to recognise it as a keyword. It is just weird to see them not coloured, as keywords ...

 

[rconn]

Can you provide an example of the syntax you're using?

 

[TLis]

Can you provide an example of the syntax you're using?

Sure:
For "to" with DO ("to" not coloured):

do j=1 to %nSources
set sourceName=%@xmlxpath[/Tasks/Task[%i]/Sources/Source[%j]/@name]
set source=%@xmlxpath[/Tasks/Task[%i]/Sources/Source[%j]]
gosub handleSource
enddo

For "then" and "else" not being coloured:

iff %maxSubBackups==0 then
set backupType=full
set fullNo=%@eval[%lastFull+1]
if %fullNo==1000 gosub renumber
else
set backupType=%subBackupType
set fullNo=%lastFull
endiff

 

[vefatica]

That was easy to repro. In BDEBUGGER I typed what appears below. "Then" and "else" were not highlighted.

iff 1 == 1 then
    echo foo
else
    echo bar
endiff

 

[TLis]

That was easy to repro. In BDEBUGGER I typed what appears below. "Then" and "else" were not highlighted.

iff 1 == 1 then
    echo foo
else
    echo bar
endiff

Same goes for "elseiff" - not highlighted either

 

[rconn]

Same goes for "elseiff" - not highlighted either

Keywords inside an internal command (like DO or IFF) are not colorized; only commands, operators, strings, variables, and comments. The colorizing lexer cannot differentiate between something like a "then" or "to" and any other command argument. Doing that would require a custom lexer for every command; not a feasible approach.

 

[TLis]

Keywords inside an internal command (like DO or IFF) are not colorized; only commands, operators, strings, variables, and comments. The colorizing lexer cannot differentiate between something like a "then" or "to" and any other command argument. Doing that would require a custom lexer for every command; not a feasible approach.

I have tried some incorrect syntax in the IDE, as e.g.

iff 1==1 to do then else elseiff
else then if do 1==1

and found that the statement/command keywords are colored regardless of the syntax ("iff", "do", "if" only). This suggests that the colorizing lexer in the IDE does not care much about the syntax of the actual command. That's OK, I believe. Then, however, it sounds feasible to me, if the lexer just colored specific additional keywords also whenever they are encountered, hence coloring "to", "then", "else" and "elseiff" as well. I gather the arguments of commands are not very likely to match these keywords exactly, the closest match that comes to my mind is when such a keyword is preceded by "/", "-" or "%" prefixes. If these prefixes would be present, the keywords would not be colored. That could be the maximum level of the required lexer's "inteligence".

I believe, that by applying the above scheme we can gain more legibility of the TCC source code than without it, where it is difficult to recognize the starts and ends of command sections (then - endiff, then - else, then - elseiff, else - endiff, etc.) and some parts of the command, vital for its understanding are less visible, than they could (e.g. do ... to).

UPDATE: If we would like to have some syntax-dependent coloring, then I another idea comes to my mind, based on the assumption, that the lexer does recognise (and color) the main commands and statements, so it knows, when it is INSIDE such a command or statement. The statements and commands could provide a dictionary of additional keywords to color in the context of that particular statement or command. Then, they would be just colored, whenever they come within that statement or command. I am not sure, though, if the benefit are big enough to justify the effort in comparison with the first idea presented above ...