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
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.
Cleaned up module and service docstrings, adding default docstrings and learn more links for services
Shared paths now work for script-relative paths
Fixed docstring display issues for module imports
Added SC_CodeSample as a valid string attribute which can be applied to modules
Added shallow (wont parse docstrings inside modules inside modules required by the current document) docstring parsing & caching for modules which return tables (Currently trying to figure out how to parse docstrings for like modules that return other datatypes)
Readded the AncestorIncludeTags settings, courtesy to Queln from the HiddenDevs discord :V
Changed the <docstring> identifier for identifier docstrings to <doc>
Sorry to the people whom this update broke their docstrings, just do CTRL + SHIFT + F and replace all your <docstring> with <doc> :V
Removed the need to use $…$ delimiters for setting attribute values, this is the lead-up for the addition of the @param attribute which is being released in the next patch 
NNnevermind, turns out there is just 0 way to access the function tooltip while you are inside a function call of it (The window ontop is what i mean by function tooltip:)
@server_only and @client_only tags not working with LocalScriptsTagExcludeBehaviour = "all" to exlude any module which has a tag group (including its own) instead of straight up excluding all modulesStartupMessageEnabled) via directivesIf anyone can tell me why when I try to post this plugin to the marketplace it gets insta taken down please tell me, I really do not like distributing this via rbxm as it means you have to redownload it every update
Edit:
Ok so i tried posting a blank Script with the Docstrings module inside it and it instantly got took down… maybe that’s the cause?
Edit 2:
Nvm, tried publishing a blank Script with the rest of the modules and it still got taken down, oh well…
Nevermind, I removed a few more modules (in particular LuauGlobals, DefaultServiceNames and DefaultServiceInfos and it stays up! That’s probably the reason, I’m guessing the main offender here is LuauGlobals… can’t believe I have to do detective work instead of Roblox telling me… stupid…)
