Some very small part of me is afraid that this will turn into something like a technology blog, but perhaps that was inevitable once I started working at ORM. The predecessor to this blog, P ¬ P, was sometimes a technology blog, too, as I was then working for a software company as a tech writer. After that it was Danny Takes a Trip, which was pretty, er, explicitly about something else, but with this, as I was starting it in Wisconsin, reading a lot, writing a lot of books, engaged in the political shitstorm of late-2016, "bikes, books, and bullshit" made a lot of sense at the time. But now? I’ve got this job at a tech publisher. I’m spending most of my day in a code editor (which is not really all that new, but still--), and the new toy I bought myself to stave off quarantine boredom and to learn something (by which I mean: to continue procrastinating on a few writing projects) was one of the shiny new Raspberry Pis, on which I am working presently.
I’d say, "so much for bikes, books, and bullshit," but obviously this is still bullshit, you know? Anyway — I’ve had this idea for a while to cook up something like 'asciidoc for poets' or some such thing, and this could be considered a part of, or warm up, for that.
A Little Background (As Short as I Can Make it)
I have been doing most of my writing — save for school papers (until recently) requiring footnotes and bibliographies — in markdown for almost a decade. At first, it was because I was getting into "distraction-free" writing programs, having just bought my first typewriter at the tender age of 'my-first-poetry-class.' I didn’t think too much of it until I got into static-site blogging after college, and then later-later when I was building a new documentation system for a tech writing gig, and realized that I wanted nothing to do with DITA (the Darwin Information Typing Architecture), which I had been using before. tl;dr I’ve been working in plain text for a while.
As a part of researching this job I wanted (and did, fortuitously, get), I finally got around to learning asciidoc, which was starting to come up as a more modern alternative to DITA, taking some good things from markdown but avoiding its (many) pitfalls (when working with complex documents — it’s still great for blogging and non-technical things). So then I was writing asciidoc, learning about the Asciidoctor toolchain, writing templates and using asciidoc to write, format, and "build" my graduate thesis. Along the way I picked up some new tools, skills, and a new favorite code editor (which was not Geany). But new circumstances arise constantly, I’m always down to learn something new (i.e., procrastinate), and so, Geany.
So, Geany.
Geany is a lightweight, cross-platform IDE (integrated development environment), and it plays well with Raspberry Pi OS (while my preferred editor, Atom, does not). In part for fun, in part because (and this is really stupid) I don’t like having to completely move my work laptop off my desk to use my personal laptop with the fancy work-from-home monitor I bought, and in part because it does, in some respects, offer fewer sources of distraction, I’ve been working on the Pi at night when I do my writing, work on Response, correspondence, etc. So I’ve found myself in the position of using Geany, which isn’t really so great for writing asciidoc, though I’ve somewhat made it tolerable, and it’s starting to really get there.
Some things, out of the box, that I liked about Geany:
-
It’s a code editor! This means when I write python scripts it has syntax highlighting, it has some nice auto-complete and selection features, and generally is laid out in a way that I’m familiar with (and if it isn’t I can customize that).
-
It has a built-in terminal, which I actually greatly prefer to the Git nonsense built in to Atom (which, though occasionally very useful, I mostly ignore, preferring to keep a Terminal window open anyway).
-
It is (also) open source!
-
It works well on the Pi.
Some things, out of the box, that I disliked about Geany:
-
While it has some understanding of asciidoc as a filetype, there is no syntax highlighting. This shouldn’t be a big deal, from an asciidoc philosophy point of view, but I still find highlighting useful, especially at work when I’m editing whole chapters.
-
Part of the problem was I’m moving from a mac to linux, but in any case I didn’t find the built-in key commands particularly intuitive (they can be changed; see below)
-
Like many editors, you need to add plugins to make it useful. Because it’s an open source project, the docs aren’t exactly…great, if you don’t already know a lot about IDEs and so forth. There is a learning curve.
-
It’s written in C, on C-like technologies, and I do not write C, and therefore have to rely on others to do things (unlike in Atom, which is built on Javascript, and I write enough Javascript to make it do useful things on my own).
So, you know, good and bad.
First Impressions
At first I was fighting with it a lot. A lot of the features don’t really google well. It has it’s own ecosystem and nomenclature and I am real lazy about remembering certain kinds of bash commands and how to use them (again, see below).
I spent far too long trying to find an asciidoc syntax highlighter for it, and then I spent time trying to hack one in before realizing I was far out of my depth with that.
I found a file tree thing for the sidebar, but didn’t find the right one, and so was disappointed when it didn’t do what I needed it to (a different plugin was the trick, turned out).
I wrote some things but because of my insistence on re-writing as I write, involving a lot of jumping back words and so forth, I was super slow because all the keycommands built into my fingers after how-many hours writing in a different editor were all wrong, and though I’m sure you’d think it wouldn’t slow me down, it did. It shouldn’t have, perhaps, but I am only human.
In any case, I frankly hated it. I downloaded code-oss, the closest thing to Atom I could find, but don’t really love it. It’s kind of like getting vanilla when you really wanted chocolate, so you’d almost rather just have avocado ice cream instead because it’s at least really different. So I thought I would at least try to give Geany a proper go, and now here I am: using it regularly, mostly not even that annoyed with it anymore!
Making the World (OK: Geany) Conform to Me
The thing that I find most exciting about programming isn’t the possibility to get rich or change the world or anything like that — it’s to make my life easier. Need to add a <span class="x">
over and over again around words in a document? Write a little coffeescript into your init.coffee file! Need a random number? import random
-→ random.randint(0,x)
! Want to display how many words you wrote in a given writing session onto a little eInk display you impulsively bought and that you have no real practical use for? Spend a really, really long time googling git hooks and writing bad python code until it works!
As mentioned before, I was hoping that Geany would let me do something similar — if I couldn’t have syntax highlighting, maybe I could at least be able to use CMD-i to wrap a word in characters to make it asciidoc-italic, right? (God forbid I actually spend the time to type
characters around words I want to italicize.)
I am very pleased to say that, after a lot of googling and a lot of real dumb mistakes: yes, you can do that. Here’s how:
-
Spend a lot of time googling until you stumble upon the MiniScript plugin for Geany.
-
Realize that it’s not behaving as you’d expect it to, so do more googling.
-
On a Geany GitHub issue, scroll until you discover that someone else has had this problem, and was directed to a "Set Custom Commands" feature.
-
Read about this feature in the Geany docs.
-
Write a python script to read standard in, wrap text, send it to standard out.
-
Realize that the "Set Custom Commands" refuses, for some reason that you still haven’t figured out, to let you do this.
-
Spend a lot of time googling why this might be, until finally accepting that you are at last forced to learn about the
sed
utility. -
Read the
sed
docs. Google other alternatives. Find none. Read thesed
docs again. -
Write a
sed
command, cross your fingers, and it half works! Spend the rest of half-an-hour getting the other half to work. -
Huzzah! You’ve gotten it to work! Now hurry and write as many words as you can before it’s time for bed (because obviously you do all your computer-play-time when you should be writing).
So, in case you ever want to use Geany to write asciidoc (or markdown, tbh), you can enter the following commands into the Edit -→ Format -→ Send Selection to — > Set Custom Commands:
sed 's/^\|$/_/g'
-
For italicizing text, e.g.,
text
sed 's/^\|$/*/g'
-
For making text bold, e.g.,
text
(add a second*
if working in markdown)
There’s more I’ll need to do, but that was the bare minimum I wanted. It doesn’t work if there isn’t a word selected (so arguable typing _
may still be faster in many, if not most, circumstances) due to the way Geany processes the commands' standard-in/out, but still: it’s something.
After I got the commands sorted, it was simply a matter of setting new key commands in the regular preferences for these new formatting tasks. Nice, right?
So now that I had my minimum key commands (aside from reassigning a bunch of others, e.g., moving between word parts, certain selection things, etc.), there was enough to work on. Beyond that it was cosmetic: downloading a slightly less (forgive me) open source-looking fixed-width font, figuring out the difference between Line Wrapping and Line Breaking, that sort of thing.
Though I still wouldn’t use Geany for my professional editing work (I am far too reliant on the multi-cursor feature, which doesn’t (yet?) seem possible in Geany from all I’ve read, to use it for that), for day-to-day writing, perhaps some web work (TBD: I’ve got some work to do on Response next week, so we’ll see), and what little scripting I do, it seems perfectly good for now.
Am I still looking for alternatives? Yes. Am I happy enough for the time being? Does it work? Does it get the job done? More or less, yes.