It's super nice to see this random submission of mine ended up being a meeting point of sorts :) It is one of my favorite design documents, probably 'THE' one now that I think about it. Thanks for all the hard work put into the document -- or well, the game in general, still a favorite of mine.
I use GNOME with week numbers shown in[0]! Find it super useful.
I am also a big fan of setting yearly goals. Been doing this for a couple of years now. This has sort of converged into a tradition of having ~12 goals per year.
Each item is something quantifiable and achievable. For example, a goal of mine is 'losing x amount of weight', as opposed to 'becoming fit' - this I won't expand into other domains however, if the context is making a game, it would be 'publishing a game', and not 'publishing a game that sells a million copies', as the latter depends on factors outside of your control, luck, etc.
The way I set up my own goals, they are achievable if I were to focus on these for a quarter alone. They are not big, huge deals. But I don't focus on these for a quarter of course, I have to go to work, and I have a family and loved ones that I enjoy spending time with. Yet it is also an anchor I look at occasionally, and if the list is having too little progress, I get the message that I should work on these for a while. I find it to be a nice balance.
0: gsettings set org.gnome.desktop.calendar show-weekdate true
This is something I used a whole lot, many years ago while making WarCraft maps.
The code is unminified and the basis is relatively simple.
I find the general idea of these curves interesting while finding the curves that are perfectly balanced uninteresting.
Put more simply, if I'm playing a game and there's a cost/reward curve such that 2 gold results in +2 attack and 4 gold results in +4 attack and so on, that often creates situations where min-maxing is trivial via focusing towards few simple attributes.
Whereas a payoff at an arbitrary point seems to add, although potentially artificial, point of "expertise" for lack of a better term.
Even the trivial example isn't that trivial though, in most multi- or even single-player games there's the timing aspect and payoff ratios.
With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.
Neovim feels indeed the proper future-proof evolution of a standard. Its still a bit cumbersome to setup (fonts, lots of plugins to configure, opinionated and overly decorated UI etc.). The acid test of maturity is the dry functionality you get out of the box in a fresh linux. It should be "just right", introducing the new thinking and functionality of neovim without getting in the way.
I actually like `nvim --clean`, which is just the basics. Early on in the Neovim project, a lot of heirloom defaults were changed to be more modern, resulting in a better (IMHO) out-of-the-box experience. I use `nvim --clean` as my man-page viewer:
MANPAGER=nvim --clean -c "colo sorbet" +Man!
Startup speed is blistering.
My current config is pretty stable, and not that large. But if it were causing issues, I'd seriously consider only doing LSP setup, which is not that onerous with the latest APIs (it was already fairly easy with `vim.lsp.start`, but `vim.lsp.config` and `vim.lsp.enable` make it easier still: https://neovim.io/doc/user/lsp.html).
Emacs seems to be a local maximum that is difficult to overcome. An entire Lisp Machine environment would be better, but it would be a tremendous undertaking and the specialists, i.e. emacs devs, don't seem to be interested in such a thing.
A multithreaded version of emacs would also be an interesting addition; I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.
> I read some arguments against moving emacs to a multithreaded model, but I don't really remember them.
Everyone including the maintainers would like this to happen. The arguments against it are technical hurdles. Emacs is a large ball of global state and the lisp evaluator hooks into everything, including the display engine, so it's not clear to anyone how to disentangle things to the point where the interpreter lock can be released.
There’s (arguably) an argument to be made that Emacs configuration distributions fit that niche - Doom Emacs, Spacemacs, and Prelude provide varying flavours for different kinds of Emacs users.
Apart from that, I don’t really know what an application would be to Emacs as nvim is to Vim. It’s more like nvim is to Vim what Emacs is to nano, except Emacs came first.
Let's not forget that GNU Emacs also had his competitor, XEmacs which spurred GNU Emacs to improve. Similar with GCC and EGCS where the EGCS later became the new GCC.
This already happened, decades ago. Xemacs was widely deployed for a while. For that matter, vim is the most popular of several editors that did this to vi. (Elvis, stevie, nvi, others probably.) At any rate, I think Xemacs is still more or less maintained, but I haven’t seen anybody use it in decades.
