OpenNefia VS pylance-release

The code for all these mods lives here, if you're curious to see what the modding system looks like right now. I think that, even if some of the mods are incomplete in their current state, they implement several of the useful features that I was wanting to port from the start, so having any amount of progress towards completing them isn't a bad thing. They're also implemented as separate mods, so if they get too buggy they can be disabled easily.

Well, it's not Elisp, but:

https://github.com/Ruin0x11/OpenNefia

It's an engine rewrite of an old roguelike I used to play in Lua. I'm trying to experiment with making a game where the engine is similar in flexibility to Emacs.

It has an Emacs frontend, and I designed it with the zealotry of an Emacs user, meaning it has advice, hooks, interactive evaluation and runtime module hotloading. You can run anything the engine can run from a REPL (and cause all the state to become broken easily).

I recently implemented nefias in my engine rewrite of Elona, called OpenNefia. Hopefully the ability to generate lots of new dungeons in addition to the ones in vanilla would make the game more interesting. Here are few I made, as part of a mod:

An engine rewrite of a Japanese roguelike I played a lot. I liked Emacs, so I decided to see what would happen if I tried writing it in the style of what Steve Yegge calls "living systems", where all the code is interactively callable in-game and reusable in mods. There is no scripting layer, the implementation and extension language are one and the same (Lua). I like to think of the engine as a massive programming runtime with a bunch of libraries and functions made for the sole purpose of modding the game. You could whip up a scratch buffer and start tinkering around with the game state or prototyping new mods fairly quickly.

The engine is not general purpose either, it's specific to the quirks of the original game. The number of weird ideas that I could graft onto it keeps increasing with each week. Yet, without feature parity and stability with the original, it's a long way away from having those things.

Another downside is going back and playing the original now isn't as fun, because I keep thinking I'm playing the rewrite and expecting bugs to pop up at ever corner. Working on a project like this for so long affects your perception of the end result in ways you can't easily unsee.

Also gets pretty lonely working on something alone for years you're not sure anyone will care about when it's playable.

[1] https://github.com/Ruin0x11/OpenNefia

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