OpenNefia
use-package
OpenNefia | use-package | |
---|---|---|
4 | 67 | |
99 | 4,370 | |
- | - | |
9.6 | 2.3 | |
over 2 years ago | 3 months ago | |
Lua | Emacs Lisp | |
MIT License | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
OpenNefia
-
OpenNefia progress update - Lots of vanilla and variant features added
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.
-
Emacs is the 2D Command-line Interface
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).
-
OpenNefia Progress - Custom Nefia support
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:
-
What is your “I don't care if this succeeds” project?
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
use-package
-
Use-Package & different key bindings based on host computer
Another way would be to redefine parts of the bind-key macro or its use-package support functions
-
Can't remove Emacs as "cask emacs is not installed"
The package-install call installs use-package that provides a utility of the same name to make it easier to manage packages. It's admittedly a little overkill for this specific config, but it's a cheap investment that sets you up for later success.
-
symbols function definition is void: map!
Granted, the Doom macro makes your code looks nice and compact. But you can get very close to that just by using do-list and define-key together. Or by using the bind-key.el package, which is included with Use-package.
- 'org' is already installed (use-package)
-
Clojure Turns 15 panel discussion video
> Deps is well documented.
> The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool.
This strikes me as a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it.
My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them.
I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal.
To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head. And it has really nice documentation with tons of examples.
https://github.com/jwiegley/use-package
-
Newbie here! Need Help!
Since you are doing code development, the first things to go for would be setting up your emacs packaging (installing use-package and melpa (use-package's documentation covers this) so you have more packages to choose from (do be careful to not just pick things willy nilly but research them a bit first)) and then setting up lsp-mode. lsp-mode lets you use LSP servers for the specific programming languages you work with in a somewhat unified fashion. You then need to install and setup the LSP servers for the languages you use, and possibly install language specific Emacs packages as support (note, Emacs has builtin functionality for many).
-
Unable to display ligatures in Emacs
I'm using use-package as my package manager and the package ligature for the ligatures.
-
Boilerplate config
I have been crafting my emacs config for about 10 years. I started with vanilla and intentionally stayed away from frameworks. About two years ago I declared config bankruptcy and went down for a rewrite using use-package and straight.
-
what is basic alghoritm/logic of installation packages to emacs?
ref: https://github.com/radian-software/straight.el https://github.com/jwiegley/use-package
-
Visual code folding?
use-package! is a macro over use-package, and respect its syntax, with a few additions. Useful reference on use-package keywords.
What are some alternatives?
3DreamEngine - 3DreamEngine is an *awesome* 3d engine for LÖVE.
leaf.el - Flexible, declarative, and modern init.el package configuration
transient - Transient commands
straight.el - 🍀 Next-generation, purely functional package manager for the Emacs hacker.
rotLove - Roguelike Toolkit in Love. A Love2D/lua port of rot.js
emacs-overlay - Bleeding edge emacs overlay [maintainer=@adisbladis]
max-downforce - Pseudo 3d racer written in Lua and LÖVE
nano-emacs - GNU Emacs / N Λ N O - Emacs made simple
VimMode.spoon - Adds vim keybindings to all OS X inputs
org-super-agenda - Supercharge your Org daily/weekly agenda by grouping items
WaveFunctionCollapse - Bitmap & tilemap generation from a single example with the help of ideas from quantum mechanics
melpa - Recipes and build machinery for the biggest Emacs package repo