wordwarvi VS rainbow-delimiters

Word War vi - side scrolling shootem-up kind of like Williams Defender.

At a very high level, set up an array of objects in your game. Each object has the ability to draw itself, and move itself. Each iteration of the game, move all the objects, and draw all the objects and sample user input. Set up a timer to iterate the game 30 or 60 times per second. Here's one game I wrote in C that works in this way: Word War vi If you dig through old commits in the repo you can follow the development from the very beginning, which begins with just creating a GTK window with a button). Almost every commit in that repo should compile and run. There may be the odd one here or there that crashes, but 99% of them should be fine, so if you want to advance through the commit history and see how the game progressed over time, you can do that. I wouldn't presume say the code is exemplary by any stretch, but it's fairly straight forward, and it works.

> Semantic Bovinator

Heh. A long time ago I wrote a video game[1] somewhat similar to Williams Defender, and casting about for some sort of "theme" for the game, I hit upon the "editor wars", the ancient storied battle between vi and emacs. You are ostensibly "vi", (a little spaceship vaguely reminiscent of the Vipers from Battlestar Galactica) cruising through system memory, evading system processes, GDB instances, etc trying to recover your ".swp" files. How to represent Emacs? Obviously, via a giant blimp! and I could display all sorts of messages on the side of the blimp, singing the praises of Emacs, and disparaging fans of vi. And the Emacs blimp had a "memory leak", which meant that pieces of the xemacs source code would literally leak out of the back end of the blimp, with the letters floating lazily away, like smoke. So that meant I had to take a look at the xemacs source, dig through it and try to find some funny bits to put in. Of course, "semantic bovinate" jumped out at me.[2]

[1] https://github.com/smcameron/wordwarvi

Honorable mention probably goes to Word War vi

I'm a big fan of rainbow-delimiters, available on Melpa.

rainbow-delimiters ( https://github.com/Fanael/rainbow-delimiters/ ) does this for parenthesis/braces etc but is somewhat bound to the syntax tree of whatever major mode is currently in use, it also scans on a per-character basis, where I'd need to scan for regex.

> Lighting up the active scopes

As you had guessed a little later, there are a few different emacs packages that do this. One of them is "rainbow parentheses" that gives every bracket a different colour (remember that emacs supports lisp, so differentiating between lots of different parentheses is arguably more useful in emacs than any other editor). [0].

Another one is highlight parentheses [1] which highlights all parens that enclose the cursor position, and gives a darker colour to those "further away" from the cursor.

[0] https://github.com/Fanael/rainbow-delimiters

[1] https://sr.ht/~tsdh/highlight-parentheses.el/

This article is especially interesting to me, as it shows how VS Code still doesn't have the "Emacs nature". Even though I'm a 30-year Emacs user, I do hesitate to recommend it to younger programmers because it's so alien, and VS Code has one of the essential characteristics of Emacs: the extension language and the implementation language are the same. But this article is a great example of how it doesn't — extensions are limited to using an extension API, rather than having full access to the application's internals. Maybe a good thing, if you're a mass-market product worried about malicious extensions. But I'll note that [rainbow-delimiters-mode](https://github.com/Fanael/rainbow-delimiters/) dates back to 2010, and has never noticeably slowed down loading or display of source files, even in languages with lots of delimiters like Lisp.

Using highlight-parentheses-mode, which is an additional package, helps. There are also show-paren-mode (build in) and rainbow-delimiters (additional package), whose could help there.