SimpleComplete | General scripting plugin

[TimeFrenzied (Broken Spawn)]

@AlexanderLindholt

Might be, but the file and script name wasn’t updated either.

run --sc getsettings: global and see if the settings that just got added exist, if not then I guess it wasn’t updated

[AlexanderLindholt (Alexander)]

Okay it seems to be updated!
But he should probably update the version numbers lol.

[athar_adv (athar_adventure)]

@AlexanderLindholt

I have found an issue with the shared path feature.

It should not create a shared path variable for a singular reference, only for actual paths (meaning one or more . or [""]).

Here’s an example of the issue:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local replicatedStorage = ReplicatedStorage
local z3SCSignal = require(replicatedStorage.Z3SCSignal)
local signalPlus = require(replicatedStorage.SignalPlus)

Wdym by this? Like, limit the depth of variable sharing to a certain level? (sorry was asleep)

@AlexanderLindholt

Is there a way to have shared paths be a different case than module and service references?

Wdym by this?

@AlexanderLindholt

Is there a way to disable the referencing after importing?

After importing TweenService:

local TweenService = game:GetService("TweenService")

TweenService

What I want it to be:

local TweenService = game:GetService("TweenService")

This used to be a feature in the form of service shorthands however since removed since auto imports were really the main focus, i can readd it if u want lol

@AlexanderLindholt

Where can I find the newest version? The file at the top is only update 15.

It’s called SimpleCompleteU15 because I completely rewrote the plugin in update 15, so it’s a seperate file from the earlier versions :V , you’re right tho i should fix the versioning

[athar_adv (athar_adventure)]

Patch 17.3:

• Module and service auto imports now both use 1 and 2 \0 characters for the symbol instead of the big and annoying \1 and \2 characters

[TimeFrenzied (Broken Spawn)]

@athar_adv

@AlexanderLindholt

Is there a way to have shared paths be a different case than module and service references?

Wdym by this?

case as in camelCase and PascalCase I believe, if so, yeah I agree

[athar_adv (athar_adventure)]

Bro i still dont get what it means

[AlexanderLindholt (Alexander)]

@athar_adv

Wdym by this? Like, limit the depth of variable sharing to a certain level? (sorry was asleep)

Let’s say it finds the shared path “ReplicatedStorage”; that’s not quite a path, just a direct reference to ReplicatedStorage, so we ignore it.

Let’s say it finds the shared path “ReplicatedStorage.Modules”; that’s a path (one or more . or [""]), so we create the shared path variable.

@athar_adv

Wdym by this?

Just like how you can choose two different casings for modules and services, I’d like to be able to control the shared path variable casing.

@athar_adv

This used to be a feature in the form of service shorthands however since removed since auto imports were really the main focus, i can readd it if u want lol

Yes, please re-add it.

@athar_adv

It’s called SimpleCompleteU15 because I completely rewrote the plugin in update 15, so it’s a seperate file from the earlier versions :V , you’re right tho i should fix the versioning

[athar_adv (athar_adventure)]

@AlexanderLindholt

Just like how you can choose two different casings for modules and services, I’d like to be able to control the shared path variable casing.

But shared path variables are predetermined by the source text tho, you mean like the service auto inserts and stuff when you auto import a module?

@AlexanderLindholt

Let’s say it finds the shared path “ReplicatedStorage”; that’s not quite a path, just a direct reference to ReplicatedStorage, so we ignore it.

Let’s say it finds the shared path “ReplicatedStorage.Modules”; that’s a path (one or more . or [""]), so we create the shared path variable.

This doesn’t really make sense man, using existing service variables for module auto imports was always a feature; it just got generalized with shared paths
\

@AlexanderLindholt

Yes, please re-add it.

Alr

[AlexanderLindholt (Alexander)]

@athar_adv

But shared path variables are predetermined by the source text tho, you mean like the service auto inserts and stuff when you auto import a module?

Did not know they were predetermined by the source text.
Also now I can’t even get shared path variables thing working.

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local Banana = require(ReplicatedStorage.Bananas.Banana)
local Banana2 = require(ReplicatedStorage.Bananas.Banana2)
local Banana3 = require(ReplicatedStorage.Bananas.Banana3)

-- Everything was auto-imported, but there are no shared variables idk why.

@athar_adv

This doesn’t really make sense man, using existing service variables for module auto imports was always a feature; it just got generalized with shared paths

Does nothing look wrong to you here?

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ReplicatedStorage = ReplicatedStorage -- Should absolutely not be created.
local Z3SCSignal = require(ReplicatedStorage.Z3SCSignal)
local SignalPlus = require(ReplicatedStorage.SignalPlus)

[athar_adv (athar_adventure)]

@AlexanderLindholt

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local Banana = require(ReplicatedStorage.Bananas.Banana)
local Banana2 = require(ReplicatedStorage.Bananas.Banana2)
local Banana3 = require(ReplicatedStorage.Bananas.Banana3)

The way shared paths work is essentially if you have defined something like local a = ReplicatedStorage.Bananas, all module imports which would otherwise manually access Bananas would use a instead (and as ive stated earlier this is compatible with WaitForChild, FindFirstChild and any amount of instance accesses)

@AlexanderLindholt

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ReplicatedStorage = ReplicatedStorage -- Should absolutely not be created.
local Z3SCSignal = require(ReplicatedStorage.Z3SCSignal)
local SignalPlus = require(ReplicatedStorage.SignalPlus)

Both are named ReplicatedStorage, it actually has a little bug/feature where it only uses the one defined as game:GetService() for shared paths :V

[AlexanderLindholt (Alexander)]

I have a few suggestions for making the autocompletion better looking.

Modules

Old:

local item: Editor.AutocompleteItem = {
	label = validName,
	kind = Enum.CompletionItemKind.EnumMember,
	detail = "SC: AutoImport",
	documentation = {
		value = `Define module <strong>{path}</strong> as <strong>{validName}</strong>{docstring and `<br><br>{docstring}` or ""}`
	},
	textEdit = {
		newText = `{MODULE_ID}{validName}`,
		replace = replace
	}
}

New:

local item: Editor.AutocompleteItem = {
	label = validName,
	kind = Enum.CompletionItemKind.Function,
	detail = path,
	textEdit = {
		newText = `{MODULE_ID}{validName}`,
		replace = replace
	}
}

Services

Old:

local item: Editor.AutocompleteItem = {
	label = name,
	kind = Enum.CompletionItemKind.Text,
	detail = "SC: AutoImport",
	documentation = {
		value = `Define <strong>{default}</strong> as <strong>{name}</strong>`
	},
	textEdit = {
		newText = `{SERVICE_ID}{name}`,
		replace = replace
	}
}

New:

local item: Editor.AutocompleteItem = {
	label = name,
	kind = Enum.CompletionItemKind.Variable,
	detail = `game:GetService("{name}")`,
	textEdit = {
		newText = `{SERVICE_ID}{name}`,
		replace = replace
	}
}

[athar_adv (athar_adventure)]

Hi, theres a few reasons why I chose the current way of doing autocomplete items

1. The docstrings provide added clarity about what you’re importing before you press enter (the path and what it’ll be defined as, tho ig it is redundant because well the label is there xd)

2. The detail values allow for different SimpleComplete features to recognize other features easily
   For example, lets say i set import shorthands and snippet shorthands to the same thing, I’d wanna remove all other autocomplete items without removing both snippets and modules; and I need a way to identify what things are SC features and what things are just there. Though maybe I’ll start using the docstring value instead, for now this is why

3. The reason why I chose the Text kind for services is because it’s easy to identify and also is the same as GetService:
   
   I also chose EnumMember for modules for the same reason, so it isn’t confused with the likes of global functions

So theres just many reasons why I decided to go with a more verbose instead of more minimalist route for completion items, tho might add some way to customize these in the future

[AlexanderLindholt (Alexander)]

@athar_adv

The detail values allow for different SimpleComplete features to recognize other features easily
For example, lets say i set import shorthands and snippet shorthands to the same thing, I’d wanna remove all other autocomplete items without removing both snippets and modules; and I need a way to identify what things are SC features and what things are just there. Though maybe I’ll start using the docstring value instead, for now this is why

Not sure what you mean.
I’ve had zero issues with the modified autocompletion.

@athar_adv

The reason why I chose the Text kind for services is because it’s easy to identify and also is the same as GetService:

The reason game:GetService("") shows that is not due to the function itself, it’s just because it’s a string type autocompletion. String as in text. Since you’re not really typing in "" (a string) when using SimpleComplete, it should not be a text icon.

Also:

@athar_adv

I also chose EnumMember for modules for the same reason, so it isn’t confused with the likes of global functions

No idea where you found the EnumMember icon for module importing.

[athar_adv (athar_adventure)]

@AlexanderLindholt

The reason game:GetService("") shows that is not due to the function itself, it’s just because it’s a string type autocompletion. String as in text. Since you’re not really typing in "" (a string) when using SimpleComplete, it should not be a text icon.

I know, the main point is that

1. It’s similar
2. It’s easily recognizable

When you’re coding fast you don’t really wanna be sifting wether or not an autocompletion is an auto import or a regular thing :V

@AlexanderLindholt

Not sure what you mean.
I’ve had zero issues with the modified autocompletion.

Huh, I’ll try it then; it’s because of this piece of code that filters the list when a shorthand is present

Yeahh i’ll probably change it

[AlexanderLindholt (Alexander)]

@athar_adv

Wait that’s for snippets though, not auto-imports?

[athar_adv (athar_adventure)]

No, this is the filtering for auto imports, which aren’t supposed to filter out snippets if they have the same shorthand (which is the only reason why snippets would be present in an autocompletion list), as the comment says it’s extremely janky and im finding a better way to do this rn

[AlexanderLindholt (Alexander)]

Why do you have a tiny custom tweening module in SimpleComplete lol?

[athar_adv (athar_adventure)]

I’ve used Transform a ton of times in my games, the only reason it’s there is because the module used to use a custom command line dock widget ui which needed some easy tweens and i just kinda forgot to remove it ever since :V (This is also the reason why PluginButton is there)

[AlexanderLindholt (Alexander)]

I have a few suggestions for the shared path logic:

• Automatic shared path variables:
  When a module is auto-imported, it should scan all module variables in the script, ensuring they reference any variable that can make the path shorter — currently already a thing, just only happens for the newly auto-imported module.

• Automatic shared path variables:
  When a module is auto-imported, it should scan all module variables in the script, find the longest shared paths and create variables, ensuring that the module references use these new variables (not only the newly auto-imported one).

Let me know if I need to clarify.

[athar_adv (athar_adventure)]

Patch 17.4:

• Cleaned up module and service docstrings, adding default docstrings and learn more links for services
  

  

• Shared paths now work for script-relative paths