@lordirishdas
No problem, just wanted to make sure I was on top of any bugs on my end.
It is rather strange behavior, but it’s not game-breaking.
Just indent it anyway, for best practice (and on the off-chance it is a bug and is ever fixed).
Here I am moving the bug reports I erroneously placed in the thread on the old tester:
1.If I’m using the IDE for one scene, then paste in a whole new scene. “Run” still runs the old one, and I had to reload the page to get it to run the new.
-
Hitting the tab key doesn’t put in a tab
-
I tried to go to the settings a second time, but hitting the button didn’t do anything. If I hit “Raw” and then “Settings,” then I could go to settings.
@CJW’s reply:
I can’t replicate any of your bugs related to the settings panel, tab key or running scenes.
What browser are you using? It should work in all the latest (popular) desktop web browsers, but I test it most regularly in Firefox and Chrome.
For the tab key, make sure your ‘Tab Type’ is set to tabs on the settings panel, else you’ll get a number of space characters, not an actual \t (tab) character.
My new reply:
I’m using Opera. I did have it set to tabs in the settings. Here’s how to replicate: Right now, I was using it, and it was working fine. Then I went to the settings to turn word wrap on. After I did that, I hit Raw to go back to editing, and the highlighting had disappeared. “Run” didn’t reflect changes I put in. Pressing “Settings” or “Vars” didn’t do anything. Hitting “Raw” again brought back the settings panel, and then I believe hitting Settings again brought back the view with highlighted syntax. The changes I’d made on the raw version were in place, and now running it reflected them. I had spaces mixed with tabs at this point (my error, not the IDE’s), and when I erased the spaces and hit tab, tab worked but put two instead of one. I erased them and believe I got it down to one tab like I wanted, but if I hit the left arrow to go from the beginning of my text to before the tab character, it only went halfway.
Ah… That’s not a bug, but rather a misunderstanding of the buttons - which isn’t your fault, they could be a bit more intuitive.
To hide the settings panel you actually need to click ‘settings’ again. The ‘RAW’ button doesn’t reshow the editor it actually opens a new editor over the old one (and any panels) with the ‘raw’ value of the scene. This is necessary/useful as the nature of the syntax highlighting and tabbing can cause problems with some browser features such as spellchecking (that’ll only work in raw mode).
Does that about solve all your problems?
In the latest development version I’ve added close/cross buttons to the panels (as I’ve now realized double clicking them isn’t overly intuitive).
Thanks for the in depth reproduction steps by the way, best I’ve seen - it makes my troubleshooting so much easier ^^
Yes, I eventually figured out I was meant to hit Settings again to go back to edit mode. 
Glad to hear you’re making it more intuitive. Will this prevent the weird things that happened after my misunderstanding led me down the wrong path? For example, changes in the raw editor not taking until going back to the highlighted editor? And the buttons no longer working and tab not working in the raw editor. Finally, the line beginning problem is still there. Everything works fine as I type along adding new lines of code, but if I have to go back and edit something already written, it’s as if the line begins too far to the right, and the tabs are the size of spaces. IOW:
Should be:
|–||–||–|Line of my code
Looks like:
…|-||-||-|Line of my code
where |–| is a tab, |-| is a squished tab, and … is whitespace as if the margin is too far to the right.
@Flurrywinde11
The buttons will still work, I’ve just made the raw field to take visual precedence over everything else (i.e. it’s on top of everything, so you won’t see what’s going on beneath it, like the tab swapping).
I finally get what you mean about edits not being read, and yes, the IDE will only take the highlighted editor’s value - not the raw editor’s value.
The raw value was a rather recent (and hasty) addition, it’s not really meant to be used for heavy editing or the like, it’s there to allow people to spell-check (or similar) if they’re having trouble doing it from within the primary editor, that’s really all.
The changes are transferred upon swapping back but tabbing, highlighting and everything else won’t work in it (line wrapping is always on in the RAW editor for example, regardless of your setting).
There is a visual glitch/issue with the tabs and spaces wherein it appears that you’re not selecting all the appropriate indentation when highlighting lines, but that shouldn’t affect functionality in any way, shape or form.
If your cursor isn’t in-line with the end of your text or it it causing some sort of hardship in highlighting or the like, then that is most likely a glitch or bug, and if you could give me some reproduction steps I’ll get straight on to looking for that.
Ah, so it looks like you already know about these things. I’ll let you know if I find any bugs like you describe. Great tool, BTW!
Ah, here might be something. I have "
*finish" at the very end of my file. (Replace
with an actual carriage return.) I’m writing code above it. It seems that if what I’m writing is at the very bottom of the textarea (with the
*finish below the visible area), sometimes if I type a command and then hit space, the textarea scrolls so that the line I just typed on is also below the visible area. If I type more, though, it pops back up. It seems to happen consistently if I put an *if on the line right after a *choice.
@Flurrywinde11
I’d rather be told about all the things I know ten times over, than not be told about any bugs or glitches at all. Glad you like it, if you suspect you find any other issues or have any feature requests, I’d love to hear them
I’ll also hopefully push out the (majorly) revised version sometime this century, so keep an eye out for that! It should prove to be a vast improvement.
EDIT:
I have to be honest, I have no idea about that one.
The only time (that I can think of) that you’ll get an automatic scrolling is when you try to run it and it detects an error (it’ll attempt to scroll to the location of said error).
If you can, try a different browser for a while and see if you get the same problem.
Ok, I just tried it in Chrome, and it happens there too. It didn’t happen until after I turned on word wrap. Oh, but it happens as soon as the keyword is completed. Pressing space (or enter) after fixes it (i.e. I can see the line again). It requires I be editing somewhere not at the end of the file, and the line I’m editing has to be the very last visible line at the bottom of the textarea.
@Flurrywinde11
I’m still struggling to replicate this, could it be related to window size/resolution perhaps? Still if it’s a matter of a one second blip (before you hit enter or space) which only occurs on the very last line of the editor, IF you’ve got content to scroll to underneath that - it sounds like it’s probably not going to prove all that much of a nuisance to anyone (if they even stumble across it at all)?
Strange that you can’t replicate it. I just replicated it in IE now, window maximized. I did it in Opera again, both non-maximized and maximized. I think just about anyone will encounter it, and though it doesn’t make the IDE unusable, it’s still a noticeable nuisance. Anyone who has to edit the middle of their file will likely reach the bottom of the textarea, and then they will see it (unless I’m a strange anomaly, but it’s happened in 3 different browsers now). Here’s how to replicate: type “asdf” (or anything) until there’s more text than the textarea can hold. Back up a couple lines. Start typing * commands like *choice, *if, *label, *goto, etc. one per line. When you get to the bottom of the textarea, it might not happen the first time, but it will the second. You’ll type *, then the command, and the textarea will scroll, making what you just typed disappear. Then space or enter will bring it back.
@Flurrywinde11
Ah hah! Got it, thanks for the guide!
Now to find out was causing it…
I played around a little bit, and - if I’m not mistaken - it only seems to happen when the font-size is 12px? I didn’t seem to be able to reproduce the problem outside of that font-size (but could quite easily swap back and produce it again).
Is there any chance you could confirm (or not confirm) this for me?
Yup, confirmed. Didn’t happen at 14px, still didn’t happen at 10px, and then started to happen when I switched back to 12px.
@Flurrywinde11
Great, thanks for that.
It seems to be fixed now (let me know if its not, though try clearing your browser cache first).
Yay, seems fixed over there too! Out of curiosity as a fellow programmer, what was the problem?
@Flurrywinde11
1 pixel’s worth of CSS positioning 
@CJW Would it be possible for you to pin this? I think a lot of people would the IDE very useful. I know I do. If you are waiting for it be in a more finished state before though, that’s understandable.
@_jl it is listed on the pin
It is also listed on www.choiceofbox.com
@Lordirish Ah I see. Thanks for that!
As Irish said, but thank you, it’s really nice to know you find it helpful.
I am (slowly) working on an update, one that aims to improve pretty much every aspect of the current IDE build (and then some).
I’ll be sure to post here when I’ve got something more to show or say about that