I ended up tweaking my Vim syntax highlighting earlier this week (after my first post), to be more in line with what Ben had posted. Here’s what I’ve come up with so far (with the disclaimer that all of this code is internal and wasn’t written with the expectation that it would ever be seen by anyone else) (and I’m also still fairly new at writing Go and Rust):
And some Rust, Go, and HTML:
These are certainly more soothing to my eyes, which was something I didn’t realize I needed. While these aren’t perfect in the least — with enough variation between languages to look almost like entirely different color themes, though I think I see that as a feature and not a bug — I’m happy with the tweaks for now and plan to stick with them.
Over the weekend I read Ben Kuhn’s post on syntax highlighting and thought the idea sounded intriguing, so I tried it out.
Here’s what I had before (and let me add that I was tweaking my Vim colors a few days before this, so this wasn’t technically my normal setup) (and let me further add that this is fairly old code and not anything particular exciting):
And after, where comments are bold and brighter than the rest of the dim code:
Hmm. This isn’t a perfect implementation of the idea in the least, but even so, I don’t know that I like having comments so predominant.
This does, however, give me several ideas for modifying my existing color scheme (or starting from scratch, which is feeling a bit more likely right now). Something more soothing, less garish. And still some way to make comments stand out more — italics or a somewhat brighter color, probably. (Sidenote: nvim-treesitter has caught my interest.)
I’m getting a bit of a nostalgia kick reading through the Standard Ebooks process. I haven’t made anything with them (though they do good work and I’m reading two of their editions right now), but years ago — in a former life, it seems — I used to make ebook editions of old books.
As far as I can tell, the first ebook I made was Chesterton’s The Ball and the Cross, which I typed up by hand and posted to Project Gutenberg. Around that time I worked on a handful of other books for PG, including Henry Sweet’s An Icelandic Primer, which was much more involved (Old Icelandic characters, tables, etc.) and incredibly fun.
Somewhere around five or so years ago I stopped, partly from working on other things, partly from repetitive strain injuries. (Even with Vim macros to help, there’s still a multitude of repetitive keystrokes in cleaning up texts, at least for me.) With reading about Standard Ebooks and writing this post, though, I’m tempted to get back into it. I built Fledge years ago as an attempt to script away more of the repetitive work, and I suspect wiser use of both it and Vim might be enough to minimize the RSI.
On a related note, I’ve been wanting to rewrite md2epub. It’s a decent-enough Python script that takes Markdown files and turns them into an EPUB, and it’s worked well. But it’s an old codebase, and I don’t like the name anymore, and it could be faster, and I have a few ideas on how to make it more ergonomic, so I’m planning to dub it Caxton and rewrite it in Go or Rust. (Primarily so I’ll have an easier way to make EPUB editions of my fiction.) This part is the most likely to actually happen, I think.
As I’m now starting to get more serious about writing novels, I recently made a list of the next few books I want to write after the one I’m working on, and I ran into an unexpected side effect: knowing what the next few items in the queue are has somehow made writing a novel feel far more doable. It’s now a task that has an ending, rather than being something with no end in sight.
Sidenote: I’m not sure how much I’ll talk here about the novel in progress, at least not until I finish a full draft, but I do plan to talk about tools and process. (For example, I’ll write more about this later, but I’m using Vim with a Git repo and a post-commit hook that generates a print-ready proof PDF of the full book via TeX whenever I commit.)
Neovim 0.1.0 was released yesterday. I’ve been using an earlier version for a month or two now and all things told, I’m happy with it. My old .vimrc worked fine (though with 0.1.0 the .vimrc has been moved to ~/.config/nvim/init.vim, which will take a bit of getting used to), and everything I’ve needed to use has worked. Vim-plug is nice for managing plugins. I haven’t switched from Syntastic to Neomake yet, but that’s on my todo list for the near future.
Vim has a steep learning curve, but it’s worth it. Here’s a cheat sheet of sorts showing some of the more useful commands (I put it together for a presentation at work):
There’s still a lot more to Vim, of course. And by a lot I mean a huge, massive mountain of things. Our goal here was to introduce some of the basics of Vim and provide a foundation for learning more. :help is your friend.
Occasionally I run across weird characters in Vim that show up as numbers in angle brackets — <95> or <97>, for example. They’re just curly quotes and em-dashes and such, but they’re encoded oddly, and there’s no way easy to do a search and replace on them.
Except that there is.
Yank the character. (That’s Vim talk for copying to the clipboard.)
Start typing your search-and-replace command — :%s/
Hit Ctrl-R followed by " (double quotes) to paste the character.
Finish out the rest of the search-and-replace and hit Enter — :%s/<97>/--/g
Voila. (There might be a way to fix these characters with iconv or some other encoding app, but I haven’t been able to get it to work other than this way.)
