intellij-community VS pylance-release

Also, no BuSL stupidity, they're all Apache 2 AFAIK: https://github.com/JetBrains/intellij-community/blob/idea/23...

And the "all you can eat" toolbox license is just a staggeringly good deal, IMHO, which also comes with a "you can keep your license forever, just no updates" which is way different from setting subscription-based licensing money on fire when your license expires. Whoever came up with that should be applauded because it really drives down my "what about" anxiety of paying subscription money for IDEs

I readily admit I am not familiar enough with fossil to know about the impedance mismatch, but I'll point out that https://github.com/JetBrains/intellij-plugins/tree/idea/241.... https://github.com/JetBrains/intellij-community/tree/idea/24... https://github.com/JetBrains/intellij-community/tree/idea/24... https://github.com/JetBrains/intellij-community/tree/idea/24... may a long way toward finding how they think about those operations

There is quite a bit going on in our view’s class, so we'll take it slow and go through its functions one by one, according to their importance. The first thing we need to do is to create the structure our items will fit into. com.intellij.ui.treeStructure.Tree seems to best match our needs, and that’s what we’ll use. In order to prepare it for what is coming, we need to configure it.

I think it's time to wrap it up. We've made a pull request to the IDEA developers, and I've accomplished the tasks I set out to do. I'm really happy to help the developers of my favorite IDE.

I offer, again, my JetBrains GrammarKit counterpoint from the last time that assertion came up <https://news.ycombinator.com/item?id=38192427>

>>>

I consider the JetBrains parsing system to be world class and they seem to hand-write very few (instead building on this system: https://github.com/JetBrains/Grammar-Kit#readme )

- https://github.com/JetBrains/intellij-community/blob/idea/23... (the parser I'll concede, as they do seem to be hand-rolling that part)

- https://github.com/JetBrains/intellij-community/blob/idea/23... (same for its parser)

- https://github.com/JetBrains/intellij-community/blob/idea/23... and https://github.com/JetBrains/intellij-community/blob/idea/23...

- https://github.com/JetBrains/intellij-plugins/blob/idea/233.... and https://github.com/JetBrains/intellij-plugins/blob/idea/233....

I had the same experience with OmniGraffle, https://www.omnigroup.com/omnigraffle

It just worked. There was support. I wouldn't dig a hole in the ground with my bare hands, why wouldn't I use good tools. Of course I would like to use F/OSS for various reasons.

The model I absolutely love is Jetbrains, their core product is OSS, Apache licensed. The whole thing, totally usable. https://github.com/JetBrains/intellij-community

The money I send their way does both, it pays for developers and it puts an amazing artifact in the world that others can use and learn from. If they weren't open source, I wouldnt pay for it. I don't know how many others are the same as me, but Jetbrains really deserves credit here.

# https://github.com/JetBrains/intellij-community/blob/idea/233.9802.14/json/src/jsonSchema/schema.json#L52

and also FOSS (Apache 2): https://github.com/JetBrains/intellij-community (as well as PyCharm found in the "python" subdirectory)

One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release

While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.

It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.

(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)

Anyone know how can we fix this issue if we build the vscode locally

Do any of these issue tickets explain the behaviour you're seeing? https://github.com/microsoft/pylance-release/issues/4341, https://github.com/microsoft/pylance-release/issues/4071

Maybe they "are the same thing" in terms of behavior (I don't know), but "A uses B" doesn't mean that "A is B".

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

There's this one: https://github.com/microsoft/pylance-release/issues/4174 (rules don't apply properly, and ovverrides don't work even after being set, this is especially for the more generic ones like )

The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close it down on a whim.

Does anyone know where the open xlang reimplementation of MIDL went[3], by the way? (Unlike 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs.)

[1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there

[2] https://github.com/microsoft/pylance-release/issues

[3] https://github.com/microsoft/xlang/pull/529