I really like live-editing documents. Interactively seeing the results of your edits makes editing more fun. For tools made by others, this would mean WYSIWYG, but for tools made by (and for) myself, I prefer the approach
of editing a text file and having the conversion process kick off automatically on every file save.
For some reason, I mostly prefer editing text in a plain/small editor as ASCII. My markup needs are usually restricted to bold and italics, with a sprinkling of images and links. I don't have particular layout needs - most of that is covered by a template.
The main idea is to have two programs, one program for editing (commonly, a text editor) and one program for converting and displaying the rendered file. Instead of having a program that does the display and editing for
one or more file formats, this separation allows me to use the convenient text editor that I've customized to my liking instead of a built-in text editor. It also
allows me to add arbitrary intermediate steps to convert from the source to the display.
This idea is nothing new - the Emacs Flymake mode
does recompilation (and other recreation) in the background whenever a source file changes as well.
With File::ChangeNotify ( and Linux::Inotify2 on Linux, respectively File::ChangeNotify::ReadDirectoryChanges for Windows, writing such tools that auto-update the viewer whenever the source file changes is really easy.
One of the programs that implement this idea is live-edit.pl.
This program runs make whenever a file in a given directory or its subdirectories changes. The Makefile
should contain the rules to regenerate the interesting content. The default rules
are only for converting LaTeX files into PDF:
# This is the default Makefile to be used by the asset reloader
# if no Makefile is found in the current directory
OPEN=xdg-open
MAYBE_OPEN=perl /home/corion/Projekte/App-LiveEdit/scripts/maybe-open.pl
.PHONY: all
all: .pdf
.pdf.tex:
pdflatex -interaction=batchmode "$<"
$(MAYBE_OPEN) "$@"
make solves the problem backwards, given a file that I want, regenerate everything
intermediate. live-edit.pl solves the problem forwards, given a file that changed, regenerate everything that depends on it.
Maybe live-edit.pl should be named ekam instead.
maybe-open.pl - this is an offshoot program that opens a file using xdg-open
if no process
is running with the file name on its command line. Highly convenient for launching
a .pdf file once in its viewer.
It's a really hard sokoban-style puzzle game about grilling sausages, with very little handholding. It does not tell any story but simply drops you into the puzzles without any explanation. On the flip side, the levels are well thought through and build on each other.
It seems to sell for €30, but I got it for 5€ in a sale, which is quite worth the money.
I struggled with the first "world", averaging maybe one or two levels a day with light play. The second world introduces three new mechanics, which make for complex puzzles again.
Unfortunately, the biggest level in the second world introduces three further mechanics and in addition also is very long and tedious, which put me off the game. I watched the solution on Youtube, and maybe I will revisit the game but that level introduces too many new mechanics without a way to play around with them, and in a setting where each of the new mechanics must be executed flawlessly in a 60+ move sequence.
It's weird but currently I draw most of my programming satisfaction from using
(and enhancing) App::sqldisplay.
It is a simplistic app that allows me to write and display SQL queries against
a spreadsheet.
I mostly use it to do the accounting for the Perl club. But doing that made
doing the books much more fun actually.
Here I edit a cell in the spreadsheet, and the SQL query in the browser
automatically updates and highlights the changed rows:
Also, I've now started exploring
HTMX
for that, and it works surprisingly well for the use case I have, removing
20+ lines of code in favour of 1 line of configuration and small Perl-side
code changes.
The one thing I don't like about HTMX is that for every component of your page
that you want to update individually, you need to create an HTTP accessible
endpoint. But for push notifications, you can just push the new HTML instead,
which is good enough.
But "even" with this hobby project, I see feature creep, as just today I thought
about exporting the collection of queries as an Excel sheet. And the UI now has
tabs, just like an Excel sheet and I wonder if I should keep an Excel
sheet/spreadsheet for data entry or just (also) write my own editing UI. But
writing an editing UI is makework for little gain. I would
want it to have mostly Excel-like UI, keyboard bindings and autofill.
Revision 2026 - Compo - PC 64K Intro
2nd place, Squidopus Famelica, a very nice story-driven 64K intro:
And third place - what is it with the Amiga balls ?
Descent by Hork
If 64K is too large, the 8K intros pack more music than a 4K intro.
LIA - Aenigma
I like (watching) live shader programming as a form of interactive programming. These showdowns
aren't that great for displaying the craft IMO because there is no interaction with the music. But obviously
the results still are quite impressive. The live shader programming mildly is what 4K PC intros are
nowadays anyway, except that the 4K PC intros are not created in front of a live audience.
The Revision 2026 demo party ended, and they've already released the videos. From the main demo competition, there
is one long video, even with commentary. My two favourites are
Golden Egg by Gaspode - technically maybe not that challenging, but very nice composition and design
Razor1911 - Razor1911 - Depeche Mode casts a long shadow, but still a great demo
