This is the home of bad.el, boxing after dark, which is an Emacs Lisp graphics program for GNU Emacs. It comes with a drawing program, the studio, plus ascii games and interactive demos.
bad-el.rss
↓ source bad-6 2025-05-25 ↓
↓ old news new 2025-01-24 ↓
The bad.el studio is a drawing program for GNU Emacs.
bad.el runs on top of Emacs but doesn't look like it.
background image: SDXL
Help I accidentally built a shelf
Drawing board:
A fancy drawing increases the coolness and precision of any DIY project,
it also kickstarts the subconscious mind.
Logotype:
To stay in the picture, a change in orientation.
(Note asymmetric effect.)
This is the `defun' of my life.
rave image: SDXL
The studio running in a text-only, no-graphics terminal, the poor man's transparency works in mysterious ways.
At the opposite end: running in kitty, that only runs in X.
Ascii art produced with the bad.el interactive editor, the studio, that still has many features yet to be implemented.
A minimal demo of bad.el. Draw ascii art in and from Lisp, insert into a buffer.
This isn't just another demo.
ascii pyramid: __20h__
gradient: color.el by Drew Adams & Julien Danjou
An animated ascii game! With very simple animations. And a puzzle to be solved. The skyline of Toronto, a new version of an old work.
original ascii art: jgs
The familiar snake game, looking unfamiliar.
ascii art: josuah
This demo is for display purposes only.
One of the first ones with color.
Frida Maple, the rest inspired by the 1985 game Déjà Vu.
snapshot image: Dalle
If you'd like to contribute to bad.el, there are many areas where it can be improved.
Here are a bunch of resources from other Emacs projects as I stumble upon them or people tell me about them - new items are appended, so it isn't sorted other than that.
I'm happy to integrate awesome features and neat modules into bad.el. Neat means one is able to call a function, be it a `defun' or `cl-defmethod', and something interesting immediately happens - this is by far the best way. The second best way is: one is able to call a function, then useful and/or interesting data is returned for further inspection 😄
I'm currently working on a minimal [1] version of bad-el. This version already runs much faster thanks to more cognitive algorithms for drawing. But this isn't yet a release. I have other ideas before it skyrockets.
bad.el now has transparency. If you don't believe me, take a look at the above screenshot. And I have been pretty open about it!
The screenshot shows 8 boxes that are transparent both on the foreground and background levels. They show the ansi colors - in the expected order, only I shifted it one step all around to make it start with white, instead of ending with it - for aesthetic reasons 😄
The quote in the box is from a manga about the immense Japanese manga/anime industry itself - a meta-manga if you will - a business which is mechanical and automated to an amazing degree BTW, on the tech - as expected - but also on the human level, what they do and how they work and how it is all organized and carried out in practice, and they describe it very well in the comic - as a programmer, and as a man, that impressed me a lot. Anyway, drawing is done, and in a boxed way, and the quote reads:
The world is all about money and intelligence.
Maybe!
The algorithm works like this. Simple, it polls the below color whenever it draws a transparent object on top of it. Then it makes a mix out of the old, below, and the new, above, color, this by adding the RGB components one by one, multiplying by a factor to specify what weight to assign each color. What is seen in the screenshot, there is only a slight advantage (56.25%) given to the upper color.
Advantages:
A simple and robust solution, it gives an honest result for an
easy-to-fathom definition of transparency, and it is a definition that
makes sense for this application; it looks good, and it gives you the
possibility to experiment with color blending.
Downside:
Performance. Especially if one moves a large transparent object around
and over such a stack as seen in the screenshot, the FPS drops big.
Everyone does their own computing and polling so it builds up.
[1]
A proposed definition of minimal software is that it isn't longer than
8 files * 256 lines/file =
2^3 files * 2^(2^3) lines/file =
2^(3 + 2^3) = 2^(3 + 8) = 2^11 = 2048 lines.
Sticking to that definition means bad.el isn't minimal, it is too big. Instead, it is small software, where the same rules would apply only not for 2^3 but for 2^4, which would mean not more than 2^4 = 16 files with each no longer than 2^(2^4) = 65 536 lines.
It has however been hinted this day and age, those definitions are too strict, 16 short files is still very minimal or minimal enough, intuitively to most people. But we still cannot change it because that would mean minimalism would be something that can grow, YUK!
Instead what we do is call the 8 file definition above "class 3 minimal", as 2^3 = 8. Moving up and down both ways to complete it, the whole list ends up like this:
Indeed, that means that any program not minimal, i.e., distributed over 17 source files or more, isn't called "small" or anything else for that matter, it doesn't ever get "big" and certainly never ever becomes a "huge" piece of software, the only thing we can say about it in terms of its size is that it isn't minimal. And how true how true, because it absolutely isn't! But we don't say it too often 😄
This is an introduction to bad.el, in the form of an interview, with an AI bot asking questions and bad.el's creator answering them, the instructions to the AI being ask eight questions with the purpose of finding out about the bad.el software. As it happened, the AI came to ask nine questions, after a stern reprimand from the user it had neglected an obvious one; I answered them all in a live session, which the AI made use of in the form of follow-up questions.
1. What inspired you to write bad.el?
I was hitting the complexity wall over and over with Elisp. I think that's what happens to a lot of guys, and that's the reason for the software developed being all yet another tool, yet another interface, processing text. Two problems: handle complexity, get things done. Here, functional programming isn't strong as it tends to pass the information around endlessly while complexity grows, and nothing happens. I found eieio.el, an OOP package for Emacs, which makes it all possible. Realizing that, I felt the sky is the limit, let's finally do something completely different! With bad.el, I think that whole theory is pretty much confirmed.
2. What problem does bad.el aim to solve for Emacs users?
I'd say that's the old approach, not necessarily applicable to bad.el. It does graphics, what I've done with it so far is games, demos, and a drawing program, the studio. Boxy and colorful graphics is what it produces for me, typically. Not really artistic ASCII art, although it is char-based. ASCII art, but geometric and conceptual, computed, rather than artistic, that plus colors and the possibility to import images - that is maybe a good summary.
3. What is the "studio" you mentioned, and how does it relate to bad.el?
It comes with a drawing program, you can draw interactively from there.
4. Is bad.el designed to be a general-purpose graphics library for Emacs?
Not really, I just started to draw with chars, and the result surprised me to say the least. After one month, I had two small games and a drawing program, very limited but still. Some months after that, some of the images I have on the web page. I'd say they are pretty unique, and look absolutely nothing like Emacs, if someone else did that kind of stuff, I'm unaware of it, and I looked a lot. That said, is it really useful? Does it do anything better than some other software? Not sure, don't know what to compare to, maybe not.
5. Does bad.el have any dependencies or requirements beyond Emacs itself?
Not to my knowledge. In Emacs, it uses eieio.el for OOP, to handle complexity, what some people call managing state, and to get things done. Other than that, it uses `image' (written BTW by RMS) to load images from files, and then to display, rotate them, move them around and stuff, it is all integrated with bad.el's other features, so now they can mingle as well. For its own graphics, bad.el doesn't rely on any library inside or outside of Emacs. But all of it is written in a modified version of Elisp, called `luki-lisp'.
6. What is `luki-lisp', and how does it differ from standard Elisp?
It is much less verbose as it contains a lot of one-char, seemingly cryptic renaming of common stuff, as macros, the purpose is to reduce typing, make Elisp programming less error-prone, besides you can express (and read) more on a single line without it overflowing to the east. It's just a bunch of macros and aliases, but the impact is pretty big since it focuses on really common things like `message', `format', and some longer ones I won't say as I probably add a typo or get the words out of order, as that is what happened to me all the time. So if you count char by char and compare, it reduces normal Elisp code length with a lot already.
It isn't exactly "Lisp with syntax" - I wish! - it just looks like that.
No, that is something we should have, of course, a modern "Lisp with
syntax" that is self-aware, error-detecting and
auto-correcting even as you type, or do nothing for that
matter. If it fancies you, you can check out `luki-lisp' in its one Elisp
file
luki-lisp.el - so far, I have
used it for bad.el, but also for
el-pa, and all my
init, config, and extension
(which BTW used to be more than 100 files, now it is ~50, but I did other
pruning as well, not just luki-lisp it; yes,
ll- prefix refers to it).
So I know it works well, for those who enjoy that style. The name refers to the fourclover, as you know a charm of good luck if you find one, so I thought it would be appropriate after all the bad blood, bad luck, and so on for some luck. So, I thought further, everything should be four or less, as something that is one, two, or three are very easy to remember, and if they are very easy, how difficult can it be with just one more? So four chars max even in the title, that's why it is "luki" and not "lucky". When I got into writing it tho, I realized it was enough to just make everything shorter - why not as short as possible?
7. How does bad.el handle user input, such as keyboard and mouse events?
For example, in the studio, the drawing program, you hit a key, and something happens, like a box appears. You hit another key, it moves or changes color. As for the mouse, there is support for that only on the prototypical level, unfortunately, but it would be a natural thing to add, yes.
8. Are there any plans to add more features to bad.el?
I heard there is a dynamic module for Emacs doing OpenGL. I'll try that before I continue with bad.el, and maybe decide to stop depending on the fallout. If they got it to work well, that's much faster. Speed is bad.el's biggest problem, not the limitation in char-based graphics, as I'm confident one can do much, much more with that, and I got such a promising start! But the speed issue appeared quite quickly. See the transparent ANSI colored boxes on [this] web page, already at that point, it became slow even for an 80x30 terminal, just 7 FPS for not native-compiled, but byte-compiled Elisp. Also, OpenGL is much more powerful than just drawing cool things with chars, it's the industry standard or one such at least.
9. Why is it called bad.el?
I thought it was a bad idea! Nah, there was once a boxing show on CBS called that, BAD, for Boxing After Dark, a very good show I might add. But here, we don't box but draw boxes, and while not adult-only per se, I like to work late at night as many other programmers. So compact and easy to remember on the surface, bad.el, below, an elegant juggler with Russian dolls and Chinese boxes? Maybe not, what about all of GNU Emacs then? It is where I like to place the bar.
AI note:
Interview questions asked by a meta-llama llamafile, locally on and from
a live crux Linux distribution on a USB stick with the AI running
on a similar stick, only bigger, 64GB. Enough to hold the AI model which,
to be exact, the model was
Meta-Llama-3.1-8B-Instruct.Q6_K.llamafile. The only problem
I had was the file system, it was initially msdos a.k.a. vfat a.k.a.
fat32 and that has a file limit size of 4GB! So beware of that, and change the
filesystem to
ext*, if you happen to acquire such a stick yourself -
I don't know - maybe for llamafile purposes 😄
Thanks for reading this far! See you around 😄
send a mail
↑ start over ↑