Updates for Studio's Text Editor: Colored Sections & Overview

This is a thread suggesting updates for Studio’s Text/Script editor.
Note: Please stay on topic for this thread

[size=4]Suggestion 1: Colored Sections [/size]

[spoiler]What’s it look like, Dean?

Reason for Implementation
This takes “Color Coding” to a whole new level. It’s code, color coded. So this is for organization purposes, for anything in the world, if you want to be more organized, you might end up color coding it. This is no different, I suggest Colored Sections so that we are able to color code our code. Code can get to a point where it’s made up of very different sections with very different tasks, I believe it’d be a lot easier to navigate if it was all color coded rather than thinking: “oh that’s that function, which is right next to this function, which is next to this set of variables, if it’s also next to this one big function then it must be the heavy-networking section”

instead, it’d be “the blue area, which is the networking section”. A lot faster.

But this is a labeling feature, it can be used for much more than just knowing which part of the code does which. It can also be used to label which areas need re-writing. Which areas need optimizing. Which areas you’re not exactly sure about so you need to get back to it. Which areas need to be updated to your code-philosophy, or framework. Which areas are broken, or areas that are working to give you some self-esteem. (You know next time you’re upset because of how much isn’t working, think of how much is :))
Colored Sections can do all that labeling, but even without all that labeling, just being able to color-code the sections by task is already incredible enough. I believe this feature would be excellent for organization.

Prototype Mechanics
To apply a colored section, just left click on this bar.

It will color that part of the bar with the currently selected color. You can select a color by either going to the Script Menu tab or middle clicking a colored section. To erase you right click.
Left Click - Color
Right Click - Erase
Middle Click - Select Color

Left Click and Hold to keep coloring, Right Click and Hold to keep erasing. This feature is primarily for more organized perception.

That’s Colored Sections[/spoiler]

[size=4]Suggestion 2: Overview [/size]

[spoiler]What’s it look like, Dean?

Reason for Implementation
At some points, I feel claustrophobic whenever I’m in a big script. Big script being something more than 500 lines, most of the time however I’m dealing with scripts much larger than that. Whenever I get this feeling, it makes me feel out-of-touch, or really distant with the entire script. And when I feel really distant, or out-of-touch with the script, I get intimidated. And when I get intimidated, I get nervous, and when I get nervous, production slow down, and at that point, I am overthinking the situation. However, it’s still a pretty big script, and it can be easy to get lost in it when working in it for long periods of time, say a week or more. To prevent these feelings, and to make the script feel more in unison with the coder, I suggest the Overview.

Not get what I mean when I feel claustrophobic? Here’s a situation where I get claustrophobic:

Not get what I mean yet? How about now, this is precisely what that feels like:

It feels like my peripheral vision is very limited, this Overview feature would make the coder’s eyes the eye in the sky.

Feature Details
By clicking anywhere on the Overview it would take you to that spot in the script. And thanks to the overview giving you a decent idea of what the script looks like, you’ll quickly know where to click, as opposed to scroll spamming where you have to skim-read as you scroll so you know when to stop. And thanks to Colored Sections, knowing where to click will be lightning fast. Colored Sections would also be adapted in the Overview. Need to get to the blue area? Just click the blue area. Done.

So, Overview would make organization better, navigation faster, and keep large-script-intimidation at bay.

Prototype Design
I suggest the text be small enough be so that only small bits can be made out but not letters, the purpose of the Overview is the give an image-overview of the script, not to be read letter-for-letter. Here’s how it would look with Colored Sections. Also the overview shouldn’t be textwrapped (if you need me to explain that please ask, basically it’s unnecessary)

The Overview would be toggled by this button. Toggle because not everyone deals with large scripts or some coders are just talented in navigating massive scripts, thus not needing it.

I understand that the entire script can’t always be overviewed in 1 frame, so there would be a scroll system.

That’s Overview [/spoiler]

3 Likes

Yes please to both of those suggestions. Even though I don’t do a lot of scripting I have done a few longish scripts and I know how you feel. It can be really difficult sometimes to load all that script into your head at once so you know where you have to go in the script to make things work. These suggestions would make scripting a LOT easier, at least in terms of understanding what each section deals with and what code you need to deal with at the moment.

Both of those sound like great ideas!

Precisely how I feel, editing or continuing to work on a script means to understand it first so that your edits don’t break anything. These suggestions aim to make that “refreshing your mind to the script” process quicker, which is a process you honestly have to go through every time you return to the project’s code.

Could it color the background of the text as well a little? like off by 5 points? it would be nice to color zones, and for you to be able to see which area you’re in at any one time

also, instead of being a color picker, could you assign colors to number keys, and clicking with a number down makes the color of that number kinda thing? that way it’s quicker to access all your color presets

Colored Sections is a really bad idea. If you need that feature it’s a sign that you should really consider reorganizing your code / breaking it into smaller modules / libraries. And even if you think you do want it I think you would find it highly tedious to organize / apply to code. Also, what do you do in the case of copy / pasting? Those sort of code-annotations-that-aren’t-in-code things never catch on because of that sort of issue even if they are nice.

Overview would be nice to have, but probably require a good bit of work as a feature to do right, so I don’t know if it would be worth it over other possible code / editor features.

[quote] Colored Sections is a really bad idea. If you need that feature it’s a sign that you should really consider reorganizing your code / breaking it into smaller modules / libraries. And even if you think you do want it I think you would find it highly tedious to organize / apply to code. Also, what do you do in the case of copy / pasting? Those sort of code-annotations-that-aren’t-in-code things never catch on because of that sort of issue even if they are nice.

Overview would be nice to have, but probably require a good bit of work as a feature to do right, so I don’t know if it would be worth it over other possible code / editor features. [/quote]

I dunno, I’m good with having organized code, and am commonly praised for how clean it looks, and my rigid and easy to read style, and haven’t gotten a complaint yet that I don’t comment my code, showing it’s easy for everyone to read, it’s not that we want color because it’ll cover for our mistakes, it’s that we want color so that it can compliment our styles, although it isn’t needed, I could color the sections of the code I’m giving to other people, or doing for hire/team projects, and it’s almost like passing my style along to them, so that if they want to modify or read, it’s easy at a glance, with no annoying three line block comments that declare a new area of the script(I found these so annoying, I stopped doing them altogether, except for libraries I write)

[quote] Colored Sections is a really bad idea. If you need that feature it’s a sign that you should really consider reorganizing your code / breaking it into smaller modules / libraries. And even if you think you do want it I think you would find it highly tedious to organize / apply to code. Also, what do you do in the case of copy / pasting? Those sort of code-annotations-that-aren’t-in-code things never catch on because of that sort of issue even if they are nice.

Overview would be nice to have, but probably require a good bit of work as a feature to do right, so I don’t know if it would be worth it over other possible code / editor features. [/quote]

I dunno, I’m good with having organized code, and am commonly praised for how clean it looks, and my rigid and easy to read style, and haven’t gotten a complaint yet that I don’t comment my code, showing it’s easy for everyone to read, it’s not that we want color because it’ll cover for our mistakes, it’s that we want color so that it can compliment our styles, although it isn’t needed, I could color the sections of the code I’m giving to other people, or doing for hire/team projects, and it’s almost like passing my style along to them, so that if they want to modify or read, it’s easy at a glance, with no annoying three line block comments that declare a new area of the script(I found these so annoying, I stopped doing them altogether, except for libraries I write)[/quote]

To Weeve
“it’s easy at a glance”
Pretty much! that’s what Colored Sections aim for, instead of these ridiculous things.

As for background coloring the entiring line, I think that would be the point of too much highlighting, too much stealing the spotlight. It’d be distracting, is coloring on the side not noticeable enough? I think color selecting by middle click or going to Script Menu tab is simple and easy-to-reach enough, so I wouldn’t go for selection-via-hotkey-combination.

To Stravant
I use libraries of commonly-used functions (functionLibrary) and libraries for item specifications (weapon stats, item prices, monster stats) (contentLibary) and I still end up with a lot of diverse, necessary code to do. I just have a lot of content to work with. Since FE, my code only gets larger and it looks like it’s going to stay that way, there might as well be new features to reduce the overwhelming-ness that comes from it, which makes me think that this is a good idea.

As for tedious-ness, it should only be as tedious as you make it, coders should only use it if need be. If a project group start forcing a certain style of coloring to their members then they ought to be aware of the tedious-ness that may come from it, as with any other philosophy they may want to force. Are the controls to apply it not simple enough, click to apply? Any tedious-ness is due to the user I would say.

Not sure what you mean by the copypasting issue you bring up, re-word?

Would definitely consider other features of course before implementing. I post this without any prejudice of how difficult it would be to implement, just advocating ideas I believe would help or solve issues I’ve had while coding.

“Not sure what you mean by the copypasting issue you bring up, re-word?”

Consider this: When you’re working with your code you often copy paste / drag around / reorganize snippets of code. How is the editor supposed to know what coloring to bring with the code that you move / copy?

Suppose I copy a piece of code out of the “middle” of a blue region into the middle of a green region. Should the code now be blue or green?

Also, recall that this is not going to be semantically aware (That is, it has no way of realizing that this color corresponds exactly to the scope of this while block), since the Roblox editor in general does not work with much semantic information currently, it just uses some general hints such as lines ending in do / then to know when to auto-insert tabs. That means that it’s not going to be able to get when to “extend” colors exactly right.

The root of the problem is: You know exactly what code you want a color to correspond to, but the editor does not, it’s going to have to guess, and do a bad job, making managing colors like that painful.

[quote]
Also, recall that this is not going to be semantically aware (That is, it has no way of realizing that this color corresponds exactly to the scope of this while block), since the Roblox editor in general does not work with much semantic information currently, it just uses some general hints such as lines ending in do / then to know when to auto-insert tabs. That means that it’s not going to be able to get when to “extend” colors exactly right.

The root of the problem is: You know exactly what code you want a color to correspond to, but the editor does not, it’s going to have to guess, and do a bad job, making managing colors like that painful. [/quote]

Code lines added in the middle of a color block should be that color, copy-pasted code should have the color of where it’s pasted, new lines at the end of a color block should be colorless, the reasons:

Middle same color because it’s congruous
Pasted code change color because the paste-bin doesn’t have color information, and the assumption is you’re changing section
End of lines colorless because the only time you’re adding onto the end of a set of lines is usually after an end, which means there’s no way to know what type of line the new lines are(perhaps have this one toggle-able, because I chose this because my code style is to type the loop/if statement, then to fill in it’s contents, and that may not always be a safe assumption)

[quote] “Not sure what you mean by the copypasting issue you bring up, re-word?”

Consider this: When you’re working with your code you often copy paste / drag around / reorganize snippets of code. How is the editor supposed to know what coloring to bring with the code that you move / copy?

Suppose I copy a piece of code out of the “middle” of a blue region into the middle of a green region. Should the code now be blue or green?

Also, recall that this is not going to be semantically aware (That is, it has no way of realizing that this color corresponds exactly to the scope of this while block), since the Roblox editor in general does not work with much semantic information currently, it just uses some general hints such as lines ending in do / then to know when to auto-insert tabs. That means that it’s not going to be able to get when to “extend” colors exactly right.

The root of the problem is: You know exactly what code you want a color to correspond to, but the editor does not, it’s going to have to guess, and do a bad job, making managing colors like that painful. [/quote]

I don’t suggest for colored lines to retain their color after copypasting, I figured that’d be significantly hard to do, so because of that and since I don’t find it necessary to retain colored lines after copypasting I didn’t suggest it. It’d be cool to have but I think the Colored Sections concept would be fine without it due to the ease of control.

“Suppose I copy a piece of code out of the “middle” of a blue region into the middle of a green region. Should the code now be blue or green?”

Neither, pasting that code in made new lines, new lines do not have color. I actually didn’t specify how it would work in terms like that, in terms of lines moving around. Now that I look more into it, it’s really at the choice of the developers that implement this to decide whether Colored Sections have a way of persisting and acting smart/automatic like you describe. I don’t think it’s too much trouble to color in the new lines since Middle Click selects color, so I personally wouldn’t implement “smart automatic behavior” Colored Sections.

As someone who likes to visually and conceptually “see everything at once”, this would be a dream come true

I’d go as far as saying the website needs an “overview widget” or an approach to design which considers spatial awareness (I know that sounds ridiculous…)

Why not just have C#-like [tt]#region/endregion[/tt] directives to indicate color-coded sections? They could have arguments that specify a name and a color, and be put inside comments so that they don’t affect the Lua parser. I’m not sure how intricate the editor is, but it might be possible to make the bit of text clickable to bring up a color dialog. If you specify a name, then it could be displayed with large text in the Overview. That would be neat.