[Feature Request] More colors for syntax highlighting

[laees]

I have a request that hasn't left me since I started working with Delphi.

Put into words it's the idea of assigning colors to

• local variables
• class variables
• Objects
• procedures/functions (maybe italic for class procedures/functions)
• Interfaces
• etc.

I am still new to Delphi and since I've only ever written in languages that support color schemes like this I think it would help to make the code easier to read at a glance, especially for people coming from other languages.

I would like to write this myself but after briefly looking at the ToolsAPI I'm not sure if I'm up to the task. Please let me know if this idea is possible at all.

The concept is best explained by the picture below.

[mgcd-jed]

Up. This functionality would be invaluable, even if it's very barebones and doesn't work in complicated cases..

[the-Arioch]

Frankly, this would kill the already existing "vertical" highlighting of nested blocks.

That "vertical colouring" is a kilelr feature for me, it maybe the one single thing making it for me unthinkable to work without CNW (i know, Lazarus and most recent Delphi had re-implemnented it too, but since i am mostly working with D2007 and XE2 - i need CNW)

So, well, if CNW team would decide to make TWO highliters engines and switch between them on the go - that's okay. But please do NOT kill the already existing highlighter!

[cnpack]

In fact, the more colors requirement will break our current highlight parse mechanism. Because current highlighters only use "Token" or “Grammar”. It works on keywords and basically OK even code can't be fully correctly compiled. But the newer requirement seems need Semantics analysis, we must know what is a Type Identifier, what is a Local or Global var. It will bring much difficulty to implement.

[the-Arioch]

will break our current highlight parse mechanism

even if it won't it would still be a non-starter

there are only so many colours can be used there that looks good and yet are instantly told from one another by human eye

make a combinatorial explosion - and the difference between adjacent colours would be so small no one would be able to see it.

that is why i told above about having TWO colouring engines, separate and switchable, as a possible avenue. You just can not have both at once and it is not engineering limitation.

[the-Arioch]

the picture below.

actualyl a subset of it - string literal and number literal - are already there, it is standard Delphi Editor setting to make them coloured.

[mgcd-jed]

will break our current highlight parse mechanism

even if it won't it would still be a non-starter

there are only so many colours can be used there that looks good and yet are instantly told from one another by human eye

make a combinatorial explosion - and the difference between adjacent colours would be so small no one would be able to see it.

that is why i told above about having TWO colouring engines, separate and switchable, as a possible avenue. You just can not have both at once and it is not engineering limitation.

Literally every modern programming language comes with syntax highlighting. The problem of "what if the colors are too close" either simply doesn't exist, or has been solved in a way that's satisfactory to millions of programmers. You can simply emulate the color choices of your go-to language if you'd like.

Secondly, you and @cnpack say this will break the existing parser. I must say I don't think I understand what you mean. How is adding capabilities to a parser "breaking it" ? In any case, having your own parser is an outdated option, as Embarcadero now provides a language server. Just use that and build the highlighting on top of it.

[the-Arioch]

having your own parser is an outdated option, as Embarcadero now provides a language server

good one

so how can one legally use Embarcadero LSP together with Delphi 5 (that version form 1999) which is supported by CnW ?

every modern programming language comes with syntax highlighting

you confuse syntax highlighting (a very broad term) and semantic highlighting.

the syntax highlighting was addded to TurboPascal 7.0 in 1992, before any Delphi yet. https://upload.wikimedia.org/wikipedia/ru/c/c8/Turbo_Pascal_7.1.png

All Delphi releases have it out of the box, you can just remove CnW (it's extra highlighter, or the whole pack) and the syntax highlighting would still be there.

You can simply emulate the [prior art] color choices

Since you warranted us the problem is solved, provide please samples of those IDEs/editors you said implement both "vertical" colouring of nested blocks and the semantical colouring at the same time.

It would be interested to see how they approach the combinatorial explosion.

[cnpack]

@mgcd-jed In a simple way, "breaking" means CnWizards' simple and fast syntax parser does NOT support semantic analysis. And it's very hard to ADD it in our wizard, for speed, for architecture limitation, for workload, etc.

[the-Arioch]

AFAIR there are 3 LSPs in VSCode plug-ins depot

You probably could try to use some of them. But yes, the amount of boilerplate, testing and maintenance would be... Significant.

It would be nice if someone implemented semantical colouring on top of those, just to have more choice. As a separate plug-in.

OTOH I wonder if you invented that nested blocks colouring or saw it somewhere. I know Lazarus having it out of the box, and the most recent XE 11 Delphi also copy-catted it from you and Laz. Which seems indirect proof this structural colouring has much more demand than semantic gimmicks.