Recently, support for Revise.includet was added to the VSCode extension. I know this is slippery slope, but I think this should be strongly considered even if through a prototype unstable plugin mechanism.
I am personally not a FromFile.jl user. I actually prefer to explictly order includes.
However, I do think it would be easier to add support for FromFile.jl in the vscode extension than it would be to incorporate this into the langauge. Given that this was recently done for Revise.jl, I think this should be reconsidered. Meanwhile, we should also consider Chris’s question in order to give better guidance to the vscode extension developers.
FromFile.jl is quite different though. It introduces implicit nonlocal behavior with undefined results in many trivial to construct cases. Generally, having one way to do things and having that way be explicit and well defined is preferable in programming. I think it’s fine for people to introduce personal shorthands which have undefined behavior on edge cases they purposefully avoid, but I don’t think it’s good to make such a behavior to be considered standard language semantics because then the undefined parts become only defined through implementation and is prone to breakage. We can see the unpythonic results this has had on Python (and the tie to CPython it creates) and so I think we should really consider a more robust design given we know the flaws.
I agree with you, Chris. There may some case for an intermediate solution such as a super-pkgimage consisting of multiple (sub)packages. However, I think our tooling may need to have a more expansive perspective of the language and that it would be better to transiently adapt the tooling rather the language itself.
Let’s not confuse my petition for FromFile.jl to be recognized by the julia-vscode extension with adopting FromFile.jl as the solution for #4600. It’s actually because I do not see any end resolution of #4600 in sight that I think the vscode extension should consider supporting FromFile.jl. In particular, I think this we relieve the language from pressure to adopt a solution.
Given that a pull request exists for this, I think we should consider it rather than rejecting on the basis of it not being a standard part of the language.
Just as a curiosity: can something like that be another extension in VSCode? Or something like a plugin? I guess I will be easier to maintain and upgrade VScode functionality targeting packages if they are more or less independent of the main VScode extension.
Not really, no. We could come up with a plugin system for the linter (as mentioned here), but imo that’s not reasonable considering StaticLint.jl’s implementation.
Is there a mechanism to “develop” and hot patch the extension? How easy would it be for someone to maintain a light fork while we wait for a better plugin system to be developed?