Script editor mega list

Here is a collection of various issues I’ve been experiencing with the studio script editor. While the editor has come a very long way in terms of functionality, it still has a number of UX issues that make it difficult to use. My apologies if any of these are features and what’s shown is intended behavior but that intended behavior feels like a bug. I encourage anybody who has issues not listed on this thread to contribute either on this thread or in a new bug report post.

I can repro all of these behaviors 100% of the time. I’m running the most up to date version of Roblox Studio (0.406.0.351423 64bit) on a Windows 10 computer.


Intellisense Prediction

The above gif shows the prediction swap from “RunService” to “RuntimeScriptService” despite the inputted text “RunS” better matching “RunService”. Continuing to type out “RunSe” then re orders the list to put RunService first.

The expected behavior would be to match “RunS” to “RunService” as the first option, and not have “RuntimeScriptService” show up in its place during a single input change. More accuracy in prediction ordering.


Inconsistent Intellisense Displaying

The above gif shows an inconsistency in display behavior for certain types of prediction. You can observe:

  • case1: “UserInputService” remaining on screen despite the field being fully typed out.
  • case2: “Enum.KeyCode.A” closing the prediction list despite more options matching what’s been typed.

The expected behavior would be to always show the list when predictions are available regardless of if what is typed is a full prediction match (case 2). I should not be shown the prediction list if what’s been typed fully matches the only available option (case 1).


Inconsistent Function Argument Displaying

The above gif shows the function arguments helper does not consistently trigger when inputting arguments. The current behavior would indicate one argument has to be “set” via a comma before the display can appear, but clearing all arguments without exiting the parentheses shows the display is capable of recognizing the first argument and displaying it.

The expected behavior would be to display the arguments of the function at all times if the user is typing within the parentheses.


Spaces, Tabs / Pushing Lines In

Seen in the gif above is a bug with pressing tab while a selection has been made. Shown first is the space key being used, the created characters being selected, then space being pressed to overwrite the selection causing the text to the right of the selection to be pulled left. Tab does not follow this same overwrite behavior and instead selects the entire line and shifts everything to the left, inserting tabs at the start of the line.

The expected behavior is that Tab presses should mirror the functionality of Space presses. From experience I can say it used to work like this and at some point long in the past it stopped.


Comments

image

At some point not long ago we lost the ability to add and remove comments )with respect to our selection) in the right click editor menu. Toggle comment is the only option now available to us. Toggle is not an acceptable solution for the analog Add / Remove buttons. I am not able to test if the following bugs apply to Add/Remove comment buttons as they no longer exist.

The gif above shows toggle comment being used to do it’s namesake. It works fairly well until you start mixing in lines that are not commented out / empty lines. The current behavior will result in everything being commented out if a single line does not begin with a comment, regardless of if other selected lines being comment prefixed.

The expected behavior is that toggle comment should work on a per line bases, not per selection basis.

The gif above shows toggle comment does not properly search the line for existing comments. The current behavior seems to only check the line for a prefix of “–” to determine if the line is commented or not. This can compound with the previously mentioned issue.

The expected behavior is that if whitespace is ignored and “–” are the first two characters found, the line can be considered commented, else it is uncommented.


Autocomplete

Autocomplete is a mixed bag of problems. It’s awesome when it works, but rarely does it seem to work without creating some form of mess. The lack of auto overwrite for autocompleted closure characters often results in the following messes:

image

Where I pressed Enter because I saw autocomplete fill ") and assumed it positioned the cursor after the parenthesis, but instead it was positioned after " and assumed I had more arguments to type still.

image

Where I was typing out a metatable structure and it auto closed all the correct openings, but did so in a way and position that made none of the characters formatted “correctly” or in a place that was easily editable.

image

Where it auto completed )end)) after I began typing the opening parenthesis and hit enter after typing out “hit”. This is a similar problem to the first case.

Adding new lines seems to be a huge catalyst for problems with auto complete and is often the source of the problems seen above.

Expected behavior for all of these cases varies but the tl;dr of it would be to avoid the tail messes autocomplete consistently makes.

21 Likes

Can confirm that these issues are very bothersome.

This happens because when you add one parenthesis, it adds the other and your selection is put in the middle. Most people have a tendency to press enter right away so they don’t realize that the selection is currently in between the parenthesis.

2 Likes

I’d be surprised if this wasn’t intentional. It makes it really easy to indent/un-indent entire blocks of code, and I use it almost every day. I suppose it would be nice to have a setting to switch between the two behaviors for those who don’t like it.

1 Like

The bug refers to the single line behavior, not multi line / code blocks.

I agree, it should indent/un-indent multiple lines of code, but on a single line it should mimic space bar press behavior.

1 Like

This post is gold!

5 Likes