New Syntax Highlighter

Token Torpn

I'm a little confused wasn't there a screenshot before there aren't any arrows for seeing additional

I removed that one because it was outdated.

It's great but I think you should still stick to the default SmileBASIC color scheme that we all know and love That is, if this is going to be smilebasicsource's new [code ][/code ] look I know you probably didn't want to hear that

The problem is that SB's colors don't cover operators and variables, so I have to pick other colors for those even if I use the SB colors for everything else (and there's no easy way to actually check what colors SB uses, at least not since miiverse ended). The current styles are just for testing right now, and they're easy to change anyway. (since it's all done using CSS) I don't think this will be used for [code] (at least not any time soon) because there are a lot of bugs and things to fix, and we would need a way to disable highlighting if you want to post code in another language, or something that isn't a full program in SB.

Default SB colors: #ffffff text #f77bb5 numeric #a5ada5 string #7b7bf7 statement #7bb5f7 keyword #10bd42 comment #f7a500 label #000000 back I took this screenshot right after resetting all settings to default to make sure I hadn't nudged them at some point. (On a side note, it's weird that the black borders around some of the colors aren't even.)

The color picker in SB is the worst I've ever used by far

Now I'm wondering... Should I add features that aren't necessary for highlighting? For example, only allowing variables to be used in FOR (so something like FOR 7=0 to 3 is an error). Before I would just read FOR <expression>=<expression> TO <expression>, which works fine for highlighting. It's not too complicated to add, but every new feature that gets added brings more potential for bugs/decreased speed, and makes the code harder to work with. Basically, am I making a syntax highlighter, or a code syntax checker? (or the very beginnings of an interpreter???)

Another problem is that most of the error messages aren't very good, and making them good would be incredibly complicated. for example, something like A = ( B# + 1 ) * 2 if you accidentally typed A = ( B # + 1 ) * 2 It would give a missing ) error, since # ended the expression and there wasn't a closing parenthesis.

If you really want to make an interpreter that could be the right way to go.

I'll probably keep the strict error checking, but maybe remove/hide the error messages, since usually they aren't helpful (the LOCATION of the error is typically helpful, though) It would still be better than the SB error messages, which are just a vague "syntax error" and don't even give a location.

Ok, I switched to the default SB colors (along with light yellow for operators and light pink for variables).

Apparently DIM and VAR are not identical.

BEEP DIM A'this works fine
BEEP VAR A'this doesn't work

I assume SB is trying to read an expression, sees VAR, and tries to read the VAR(name) form. Since there's no parentheses, it throws an error.

BEEP DIM A'this works fine
BEEP VAR A'this doesn't work

Oh

BEEP DIM A'this works fine
BEEP VAR A'this doesn't work

Potential bug?

BEEP DIM A'this works fine
BEEP VAR A'this doesn't work

It doesn't seem like a bug, since using VAR or DIM with nothing after it is a user error It's just strange that SmileBASIC detects that

Keep pointing out weird things you find Because I'm about two thirds done with my obfuscator program, and I'm running into the same issues you are.

No hah He's above all of us when it comes to coding