Ah crap, I generally use the web interface during the day so I don’t have this. I’m completely the same though with regards to writing ideas down in the startup file. I’ll try this tonight when I get home. Thanks!
edit: to avoid multiple posts in a row - is there a way to spell check the entire document? I guess variable names would be a PITA but if the word count is able to distinguish between code lines and prose, would it be remotely possible to spell check just prose lines en masse?
I have noticed a problem with the text coloring: while *if (in a choice), *selectable_if, and *hide_reuse are all the colour of the choice text, *disable_reuse isn’t, and is instead the same colour as a standard command. I assume this isn’t supposed to be the case?
Their color depends where in the body they are, I thought…
With *if, yes, but the others can’t be used out of a *choice, can they? (So *disable_reuse should never be that colour, unless there’s some other use for it I don’t know of…)
Both *hide_reuse and *disable_reuse can in fact be used (e.g.) on a line of their own near the top of a file, to apply that state to all #options within that file by default. (Indeed, *allow_reuse exists as an option-specific command to allow you to override that hide/disable default state for one or more specific options, where required.)
As for CSIDE’s highlighting of in-line #option commands (selectable_if, hide_, disable_ & allow_reuse), you’re correct in spotting that *disable_reuse is not at present being color-coded properly; nor are *hide_reuse and *selectable_if when used together on the same line (but those two are at least displayed correctly when used individually). All being well these aberrations will likely be tweaked in the next update.
Interesting! I just use a separate project within CSIDE, literally called ‘Notes’, in which I stick everything not an actual (game) scene file. So long as I never try to run or Quicktest that particular project, all is fine. 
Oops, I forgot you could do that. (And I didn’t even know about *allow_reuse…)
From the Wiki:
*disable_reuse works in the same way as the *hide_reuse command, with two major differences:
Instead of completely hiding the used option like *hide_reuse, it will just grey the option out (it will still be displayed, but unselectable)
Unlike *hide_reuse, *disable_reuse cannot affect an entire scene and must instead be added individually to each option you wish to disable the reuse of.
So just to double-check, the wiki is incorrect on this point, then?
Now that you mention it, it is indeed. At what point *disable_reuse was tweaked to work more like *hide_reuse, I couldn’t honestly say. It’s also possible that the Wiki has always been wrong on that particular subject, but the way that particular piece is written suggests to me that this was specifically tested for, and at that time they did indeed work differently.
[…and so saying, he dashes off to fix it.]
I’ve been trying to replicate your problem, to no avail: CSIDE simply used my current Settings to change a vagrant space to a tab, or vice-versa, so if I had the correct number in the first place it isn’t actually introducing any new indentation errors (for me, at least).
Are these two existing, imported files (e.g. imported using tabs initially, while your Settings since then have been using spaces for indentation)? If so, have you tried the scene context menu option (right-click on that scene, select Edit, then choose tabs-to-spaces or vice-versa), to see if that auto-fixes things for you?
If it’s a large scene, to be on the safe side create a backup copy of it first (e.g. by simply dragging & dropping a copy to a separate new ‘Notes’ project, or similar).
I’m not entirely sure what you mean here, since the spell-checking (if On under Settings) is always kinda… constant. If any word in the displayed file is currently underlined, it doesn’t exist in either the defined dictionary or your User dictionary. If it’s not underlined, it exists in one or the other. Likewise, it constantly checks each and every new word as you type, removing the underlining when spelled correctly.
They are scenes that have been edited in CSIDE. My settings are currently set to use tabs for the spacing and I manually use tabs too (I’m not using auto indent - I thought this issue was related to that before so I’ve turned it off but it’s happened again). I did try last time it happened to use the tabs to spaces etc but everything also broke. I’ll create a backup and try again one day when I’m feeling brave. Thanks 
In Word you get things underlined when you spell things wrong but you can also press F7 and it will run through each spelling mistake in the entire document. This saves scanning the entire document by eye, especially since so many variables are underlined as standard (which I’m learning is useful!), it can be quite a pain to run through. Yes in theory I should be spotting spelling mistakes as I go but they always seem to sneak through when I’m in the middle of writing a tricky bit of text.
Since some people like variables to be underlined … can we perhaps have them underlined in a different color - which we could then flag as a variable
In longer words: if I have guntype as a variable, when I right-click now i can add it to the dictionary or whatever but I’d like to mark it as a variable and have the red underline turn into green … That would be a really used feature for me.
Hmm. It sounds like you’ve inadvertently inserted spaces occasionally (been there, done that) which CSIDE switched to tabs when prompted, meaning that there were now too many tabs for the proper indentation on a particular line—hence the indentation errors during a run / auto-test. I can’t think of anything else that would actually explain it (e.g. Smart Indent wouldn’t do it—it’s generally ‘smarter’ than we are when it comes to getting it right!).
The quickest fix I can think of is simply to run Quicktest over & over again, fixing each indentation error it finds. The hotkeys CTRL-S (save the current displayed file) and CTRL-T (run Quicktest on current project) would probably make things easier.
Of course, doh! (Shows how long it’s been since I’ve used Word for anything more than a short snailmail). It’s not an option currently available but deserves to be on the “Would be nice to have…” list.
I know that @CJW would very much like to eventually make the Code Editor highlighting entirely configurable by the user, presumably also including highlighting variable names to suit our own individual preferences. I think it’s fair to say that this is however a major undertaking, so there’s no telling just how long it may take to accomplish. Watch this space! as they say?
Hey everyone, just a quick note to say thank you for ALL the feedback, there’s some really invaluable suggestions here! I’m somewhat delayed in writing up an article and going through feedback in detail due to some health issues, but rest assured I am reading and making a mental note of everything. Hoping to push an article and a patch update shortly.
Thanks again everyone, it’s fantastic to see so many people using and getting involved with CSIDE! I’m looking forward to working alongside you all to make it the best app it can be 
Here’s the weird bit. It doesn’t fail a quick or random test. That’s why it’s only annoying but that’s also why I have absolutely no idea which line is at fault to stop the message coming up. To clarify, I only get the message when I first start up CSIDE (both web and desktop version)
edit: unless you meant to let CSIDE make the changes, and then run through quick test. If so I can but 1. It’s a major chore as pretty much all of my indentation goes out for the entire scene. 2. It has happened more than once.
I’m sure I must be doing something stupid but I have no idea what it is.
Hope you feel better soon. No rush on the updates, it’s already amazingly useful to us all.
Thank you :)!
Would you mind PMing me some culprit files? I’ll take a look and see if I can replicate any dodgy behaviour.
So…
What about my syntax highlighting? 
I don’t want them high-lighted - that would drive me batty. Just the underscore of the “misspelled” word (aka variable) change from red to green.
The squiggly under CJW go from :red: to :green: (when editing or writing)
This is a good example of the challenge CJW faces with any sort of configurable syntax highlighting, to be honest—everyone has different ideas of what works for them, and what doesn’t. For instance, scroll down a bit on this earlier post for one person’s idea of nirvana and note the specific difference between your preferences and theirs.
My personal preference would actually be a third one—I would prefer just the variable text itself color-coded in a color of my choice, with no underlining (otherwise my one-track mind would forever be trying to ‘correct’ the ‘misspelling’!) and certainly no icky box around the word. Then again, a fourth person might in fact prefer no highlighting at all of their variable names, to avoid having just too much in the way of contrasting colors, or different highlighting styles, on their screen.
And here we’re just talking about variable names. Now let’s multiply that by everything else one person or another may like the ability to highlight within the Code Editor, in one way or another (or not at all, if that’s their preference)… I really don’t envy CJW this mammoth task.
The other point of view, of course, is that the likely time spent on fully implementing “User-defined Code Editor Highlighting” could possibly be better spent on implementing a host of other improvements and new features—of potentially far greater benefit to many more users than what color (if any) a particular word is, or whether or not it’s underlined, or indeed if a given word can be surrounded by an icky box. That’s the toughest decision of all for him to make.
Have you noticed the ‘Show’ option on issue notifications? I feel a forced transition would be very intrusive.
