Their extensions API is still a bit lacking, but Jupyter support in the style of vscode should be possible with the current capabilities.
This would unblock people to write their own Jupyter integration for example, or whatever else they want. There's load of cool stuff like Argus https://github.com/cognitive-engineering-lab/argus that rely on creating buffers with custom UI, and Flowistry https://github.com/willcrichton/flowistry that rely on graying out some code, and I want this stuff on Zed too
we all want something.
Second, in the case of people making feature requests, it could be a net-societal-gain [2] if feature requesters made some kind of binding commitment. (See also the hold-up problem [3].) Perhaps a potential customer would commit to "if/when feature X gets added, I will commit to using the product for 2 hours." or "... I will spend $10 on the associated cloud services." (The question of what happens if the customer reneges also has to be agreed upon up front.)
[1]: https://en.wikipedia.org/wiki/Revealed_preference
[2]: known as social welfare (not to be confused with welfare programs -- this is the neoclassical economic framework after all!): https://en.wikipedia.org/wiki/Social_welfare_function
[3]: this paper discusses the hold-up problem in the context of vaccine investment and development: https://www.nber.org/system/files/working_papers/w28168/w281...
This is actually super interesting. Thank you so much for sharing.
So...where does that leave the Zed team? If existing LSPs aren't good enough, that's not a Zed problem: they're building an editor, not LSPs for your favorite language.