========================
== Experimental Emacs ==
========================
Corwin's Emacs Blog


Emacs Sandwiches

So far we've been building dungeon purely in Emacs lisp. Dungeon-masters will be able to use org babel blocks to implement custom game play "automation", but all the code we've been thinking about as "comes with" (including automations for the sample game) have been in Emacs Lisp.

After messing about with NodeJS and ComicChat for a bit, I'm starting to have more thoughts about how to get dungeon-mode to a reasonably play-testable state. In fact, a core complexity I've been trying to work out is "incrementally" updating remote files (remote from the DM or arcade perspective, so the players copy of the their own character when ) has to do with only updating parts of copies of files sitting on players computer, when those files are under the control of the DM/game.

--more--

Generating README.json

I'm using the README.org as a "container" to structure simple projects as literate programms. The programs for each project are contained in and built by (tangled from) the file that documents them. Meanwhile, I provide documentation in other formats such as Markdown, generated using org-export.

People sometimes offer edits to those generated files.

Naturally, this leads me to try exporting README.org as JSON. Thanks to ox-json (and Jared Lumpe), it's easy!

Creating JSON

When I'm trying to see if something works (meaning does what i need, I assume a given program does what someone wants) I usually prefer the command line, if not an actual script.

--more--

Using README.org

The last few months have been rough. Today I "finished up" one of a set of small "feel good" projects I have been doing to learn things and, you, know, feel better. Much quick project: org-git-hooks.

#more While admittedly tiny, it's nice to consolidate some code that I'd duplicated and fun, in that the 400 line ~README.org file contains all of the code, documentation, "build" configuration, and licensing.

Why Would You Do That?

I'm using the README.org structure some projects and I often forget to regenerate README.md from it when I commit.

--more--

FOSS Resume Sample

Describing FOSS engineering practices in the form of a resume sample.

Valentines

Valentines

Dee and I met for the first time in 1991. Susan is Dee's older sister by a little more than I am older than my sisters: i.e., let's say 5-10yrs. She managed the pavilion stage, easily heard blaring rumples and rumbling kettle drums from my station at

%TITLE

%TITLE

blah blah

foo

bar

baz

qwx

Example:

  #+BEGIN_SRC perl
  say "Hello, org-babel!"
  #+END_SRC
(message "xyzzy")
  say "Hello, org-babel!"
  which env
/usr/bin/env
pscp -r d:/projects/bla/corwin.bru.st/public/* dh_aw28jd@corwin.bru.st:/home/dh_aw28jd/corwin-emacs

#+RESULTS:

%TITLE

%TITLE

Considering that information technology seems likely to remain a part of our culture for the foreseeable future, I think we must be in it's infancy. Perhaps that attitude helps explain my reflexive eye-roll when coming across "modern" used to describe or contrast technology (especially software). Consider "User Experience", for example.

How much of the "digital user interfaces" that you regularly interact with do you hope/expect to have staying power over generations of users?

--more--

COMPLEXITY FIRST DEVELOPMENT

COMPLEXITY FIRST DEVELOPMENT

Let's face it, complexity is fun. It's also where lie the demons that demand the extra eighty percent of our time for the "final" twenty percent of our requisite functionality.

Requirements are Quicksilver

Speaking only for myself, my passion projects and so on, (and in no way for any business stallholders, technology partners, or vendors with whom I may have had the honor to work over my varied professional life), the goals of a technology project on which we seriously focus attention will tend to "wiggle", vacillating about the available surface of user experience and maintainer ingenuity to the extent we don't go to lengths to, as it were, limit debate. Iterative development is, in a sense, intended to run with this problem more than to prevent it, especially with practice such as user experience testing that may involve end-users in early phases of development before a software project is bug free, perhaps working from prototypes and mock-ups thus before anything works.

--more--

Simple Emacs 29 Windows Build Script

Simple Emacs 29 Windows Build Script

ABSTRACT

TL;DR This "literate" post generates a shell script to make a new Emacs 29 and get it ready to publish.

The program the post generates, although simple, is actually kinda sweet.

It doesn't rebuild Emacs unless there have been changes upstream since the last successful build. It doesn't require any special caches or data-files. It also has some limited resume capabilities, in that it can skip completed steps along the way, to continue on a later failing bit without repeating earlier things that worked fine. It stores output in an "install" folder. Each sub-folder under install contains a ready-to-run version of Emacs 29, filed by git short revision ID. It also creates an "upload" folder. Sub-folders under upload have you need to upload Very Nearly Officialâ„¢ versions of GNU Emacs (assuming you've got your authorization and credentials and such setup with FSF/GNU).

--more--

ComicChat

I stumbled upon ComicChat recently and have been having a great deal of fun learning node.js while messing around with it.

So far I've added:

  • UI/UX

    • inline linkification
    • mIRC color, bold, italics, and underline formatting
    • force wrapping for longer phrases
    • ability to break panels based on total character count (patched upstream)
    • rotating backgrounds (patched upstream)
  • IRC relay (relay.js)

    • ability to join multiple channels (patched upstream)
  • Custom IRC relay (relay+.js)

    • ability to command join/part via PM to bot
  • Discord relay (discord-comicchat on Sourcehut)

    --more--
Previous Page 2 of 3 Next Page