I have come to the conclusion that SynAnySyn works exactly as programmed: wrongly. Perhaps this wasn't the intent, but the silly attempt at optimization, or whatever you'd call it, resulted in both obfuscation and an easily prevented bug. Who wrote this flawed code I don't know, but it is very irritating to have to rebuild Lazarus to fix one component that should have already been tested and repaired.

The negligence in maintenance, translation, and or testing could be so bad as to drive potential newcomers to Lazarus away. This was completely preventable.

The flaw in the logic has to do with binary math. They add the first with the last element indices and then shift right all the way through the loop. Given which string doesn't match in the comparison either the beginning or ending index is manipulated, the start grows and the end shrinks. Don't you think that this could cause a few bugs? Why not do a for-loop?

Using for-loops is approximately the same speed but without the bug, so I have repaired the unit.


The other problem is native to the compiler, and foolish. Lazarus uses BGR notation in hexadecimal colors and doesn't tell you this anywhere. The only way you learn this is by trial and error. So my colors were flawed because they were in RGB notation, like you would expect to have used. RGB is the "standard" in other pascal compilers, so why not Lazarus? This deviation prevents any cross compiler reuse of syntax highlighter configuration for SynAnySyn.

If you want to download a working copy of SynAnySyn you may do so here.