In Roblox Studio, the Lua lexer has started displaying my custom require function in yellow instead of the normal blue syntax highlighting. This makes it visually inconsistent with the standard require function.
Steps to Reproduce:
Create a script where you override require, such as:
local require = require(script:FindFirstAncestor('Honeypot') or game.ReplicatedStorage:WaitForChild('Honeypot'))
Observe that the custom require is highlighted in yellow, unlike the default require, which is normally blue.
For the past few years my custom require statement has always been the same as the require keyword (blue). And I believe this is the preferred behaviour for all developers who overwrite the default require function.
Thank you for this post. We have recently released an improvement to the Script Editor that lets us correctly highlight built-in types (a long requested feature) and while doing it we took the opportunity to fix our syntax highlighter as well to be based on the Luau parser.
What you see is the result of this: as @SomeFedoraGuy mentioned, now the require is correctly highlighted as a custom function after being redefined.
Weâre currently collecting feedback about this change and are going to address the feedback in the upcoming weeks.
Knowing if a built-in has been redefined can be beneficial, on the other hand, some prefer highlighting them the same as before, like you.
One option to address this could be to color them the same using one of the currently available Function Name Color and Built-in Function Color Script Editor Settings.
Weâre also open to other suggestions, so please let us know.
Currently, changing the function colour in settings is how im coping with this change, however itâs far from ideal. Like I said I get from a logical perspective this change is better, and in some cases from a usability perspective I prefer it:
However, Specifically relating to ârequireâ and to some extent âselfâ. Id challenge you to find a single developer who actively redefines these variables who prefers this new syntax highlighting.
Example of self (lots of developers like to store new classes in a variable named self for consistency, so this change really makes it less consistent.):
Also as a side note, regardless of which behaviour you go with, this screenshot of the above example is simply broken, thereâs no reason for one instance of âselfâ to be coloured like a normal variable then other to be highlighted as a built-in.
Id greatly appreciate if we could at least have a setting to allow us to access the old highlighting behaviour / if thatâs not possible then some way we can change studio files to achieve this, as a really really really hate the new highlighting for ârequireâ
As things are looking right now, the benefit of highlighting built-in types is too great to just âturn offâ the new functionality. On the other hand weâre going to make sure that we donât lose fidelity, and weâre going to make sure that your problem is addressed.
Besides require and self, are there any other keywords that might benefit from special highlighting?
Options for solving this include a setting to exclude all redefined built-ins from custom coloring, having a whitelist, or creating another category of colors â and if you have any other ideas or preferences, please let us know.
This is the most simply option that while not perfect, does at least give the effective choice between the new and old behaviour (as you could just set redefined built inâs to be the same colour as built ins).
that being said:
This would also work.
As I mentioned id even be happy if there was just a value I could change in studioâs files.
Just thought I would link to this post (which you already seem to have acknowledged, yay!) about the type keyword not being highlighted as a keyword when using the export keyword. Even if not redefined in a script, it is still not being properly highlighted. Just wanted to link it into this main thread.
Also, in terms of redefined built-ins from being colored differently based on context, I think a toggle or new color category would work best with how we currently customize the editor. I am slightly leaning to preferring a custom color category for redefined built-ins, as long as normal use of built-ins remain their original color. This route would also give folks who want distinction between using a redefined version of a word and ânormalâ use of the word.
& 