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?
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
\
Alr
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.
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)
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)
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
I have a few suggestions for making the autocompletion better looking.
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
}
}
local item: Editor.AutocompleteItem = {
label = validName,
kind = Enum.CompletionItemKind.Function,
detail = path,
textEdit = {
newText = `{MODULE_ID}{validName}`,
replace = replace
}
}
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
}
}
local item: Editor.AutocompleteItem = {
label = name,
kind = Enum.CompletionItemKind.Variable,
detail = `game:GetService("{name}")`,
textEdit = {
newText = `{SERVICE_ID}{name}`,
replace = replace
}
}
Hi, theres a few reasons why I chose the current way of doing autocomplete items
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)
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
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
Not sure what you mean.
I’ve had zero issues with the modified autocompletion.
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:
No idea where you found the EnumMember icon for module importing.
I know, the main point is that
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
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 
Wait that’s for snippets though, not auto-imports?
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 
Why do you have a tiny custom tweening module in SimpleComplete lol?
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)
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.
