That’s it really. Any ideas how to stop this, or do I need to raise a bug report?
Is it only the BOM? If it is… could you detect it (binary read), and then decide to read in (and write out) the file yourself and run from there?
Sounds like a bug anyway, although I’m sure there’s not many unicode (UTF-8) scripts out there
Hey Richard,
Crikey, sounds like a pain, but an interesting workaround if it works! Thanks for the tip.
Anyone know where I submit a bug report?
Cheers
Dave
Crikey, now I’m also finding that unicode characters are throwing off the highlighting of offending lines of code!!
If I use my comment headings tool with full block characters, when max throws an error, the line that is highlighted is WAY off!
A short test reveals that the more block characters you add, the worse it gets:
rollout roTest "Test"
(
-- ████████████████████████████ -- the more █ characters you add to this line, the worse the offset becomes
function test = -- this line will get highlighted on error!
(
someFunction() -- but it should be this line
)
on roTest open do test()
)
createdialog roTest 300 300
I know Comment Headings is a bit gimmicky in some ways, but a) it makes navigating large scripts a total breeze and b) that really isn’t good from a “this product works well” point of view.
Argh!!!
well that sucks :\ I figured if it was going to do something it’d be a full-on script error (perhaps only in certain max localizations), but what you’re mentioning is pretty crazy… that’ll make debugging hell.
Sadly, none of the standard ASCII chars have the same graphical appeal
Yeah, I’m pretty pissed actually!
It’s been SO much easier whizzing up and down 1000 or so lines of script with big ol’ words in them, but with #s or @s they do kinda blend in with the backgorund when you’re dragging the scrollbar.
Buggeration.
I can’t make heads nor tails of how on earth I would configure the SCiTE bits and pieces to do a custom syntax highlighting… otherwise I’d suggest that maybe you can write your header comments in a specific form and have the syntax highlighter deal with that form by increasing the font size.
/me looks around for somebody who knows how on Earth that would be done, if at all
All I’ve found is keywords12 which is reserved for user-defined key words to syntax highlight… but I haven’t spotted whether you can specify wildcards/regex in those, or whether you can add, say, keywords13 (a quick test shows that does zilch, but I might be missing a reference somewhere that keywords 12 does – creating a style.MAXScript.24 certainly wasn’t it)
Edit: P.S. How on Earth!?
Now that is a good idea! I’ve submitted a report to Autodesk anyway. Maybe something will come of it!
I think it has something to do with the language-specific “lexer”s, which I assume are written in C++. A bit out of my league…
Well that was an interesting road…
So I can change the size of comments, for example adding this to the user options file…
font.comment=font:Courier New,size:50
Gives me massive comments, but all lines go to 50 as well! Not so readable. And a little searching for “SCITE line-height” brings me to this:
All lines of text in Scintilla are the same height, and this height is calculated from the largest font in any current style. This restriction is for performance; if lines differed in height then calculations involving positioning of text would require the text to be styled first.
So there wo go. Good thoughts though Richard!
yeah, I had poked at adding…
style.MAXScript.2=$(colour.code.comment.line),Comic Sans MS,size:18,eolfilled
To the user properties… so that all – comments would be big, while /* */ would be the same as usual… but alas… no luck with the lineheight… was actually looking for a way around that, but no-go, I guess.
Back to the drawing board… which is looking pretty full of stuff that has been wildly crossed through in frustration