I heart Latex, but I don’t really write with it these days since I’m no longer in grad school. Markdown, though, I use all the time. So, on the occasions that I need to use math in my markdown file, I like to be able to have a math mode that’s identical to Latex’s math mode.

Turns out, when I’m converting from markdown to HTML in Pandoc, I really only need to add one option to it– --mathml. There’s also an option for MathJax, but I’m not quite as fond of that because I need to specify the source file and it also means adding JavaScript to the HTML output.

So, pandoc --mathml myfile.markdown -o myfile.html will convert my file to HTML with Latex math support. $$ is the delimiter for math mode and $ is the delimiter for inline math mode. Pretty simple.

Of course, it’s not nearly as robust as a proper Latex setup, but if I need something more powerful than what’s available, I’ll probably just switch over from markdown to Latex.

Update: I also don’t like the block equations in the middle of the page (I don’t like that with Latex proper, either), so I put some css directly into the markdown file at the very top:

<style>math[display="block"] {display:block;padding-left:4em;} </style>

(Note: The information from this post comes from this SO question. I’m just collecting what I found to be the best parts of it.)

(Note 2: I’m using Linux with Bash, and the commands here probably won’t work in Windows. They may work in MacOS, though.)

They say that coding is 99% boredom and 1% pure terror.

I experienced that terror today when I had meant to type git stash pop, but accidentally typed git stash drop.

It turns out that the solution is much easier than you might expect, though finding it was a minor challenge. Upon dropping a stash, Git does not delete the information in the stash– It looks like it just deletes the reference. If you can find the hash, you’ll be able to still restore the stash.

If you only just now dropped the stash and still have the hash listed on your screen, skip ahead to the section involving actually applying the stash (just one command). Otherwise,

Finding the hash that matches the stash.

If, like me, you already tried some commands and no longer have the hash on the screen, the first thing you’ll need to do is figure out which hash is the one from the dropped stash.

The first thing you’ll want to do is echo out a whole bunch of information from git diff. You can echo it into a file (which is what the link above does) or you can pipe it into less, which is what I’ll do here–

git show $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' ) | less

At this point, you’ll need to know something unique (or nearly unique) about your particular stash that you can search, and you’ll need to be able to recognize the changes well enough to identity which stash you need. Something unique like this could be the name of the stash, if you remember it and it’s unique, or the date (in format Fri Jun 28 15:09:54 2019 -0400), or maybe a function name that you wrote. Just anything that you can use to search via less to find the stash you need.

To search with less open, press the / key, and remember that search is case-sensitive. In my case, I had written a function that I distinctly remember writing, radval. (Also note that to move to the next match in a search, hit n, to go to the previous search, hit Shift+n. Scroll with arrow keys, but look up more details for less if it’s a program you plan to use a lot, as I do.)

Once you find some code that you know is in the stash you need (or just found the title or something), scroll up, if needed, to the heading of the stash. This will be four lines starting with “commit”, “Merge”, “Author”, and “Date”. The long alphanumeric string following “commit” is the hash, and it’s what you’ll need.

The hard part is done.

Applying the orphan stash.

This part is easy. If you have the stash hash, and for this example I’ll use 73d46febad13327963c7e0bf95ce2829fe35042d, simply put this in the command prompt–

git stash apply 73d46febad13327963c7e0bf95ce2829fe35042d

It should be done now, so you can breath out.

A little bit of background for this post.

I love VirtualBox. Though, to be more specific, I love having a virtual machine to use for testing. Discovering bridged ip addresses was a revelation for me.

But I also love ssh. I regularly ssh from my laptop in my living room to my desktop in my office because I’m too lazy to get up. So, I want to be able to set up virtual machines via ssh.

Docker is pretty neat, but it’s not really designed for what I want it to do. I tried it, and decided it wasn’t really worth fidgeting with it to set up a bridged IP address, which I’m not 100% sure is possible in a Docker container anyway. I used Vagrant from Hashicorp for awhile, which is pretty good, but I’ve encountered a versioning problem– My version of VirtualBox was too new for my version of Vagrant, so it wouldn’t start. So, why not cut out the middleman and just manage VirtualBox via CLI? The only feature from Vagrant I really care about is starting a VM, anyway.

I thought it would be difficult, but it’s actually surpisingly easy. To do this, you’ll need install VirtualBox extensions from their website. Make sure to get the extentions for the right version of Virtualbox– If you’re installing VBox from a repo, it’s probably in the “VirtualBox older builds” page. Also, I’m not bothering with actually creating virtual machines via CLI from scratch, but instead making a base VM to copy when needed. Creating from scratch, I don’t think, can be done via CLI, though I could be wrong about that. So, I created a base VM while physically at the host machine, and can now clone that machine, and can now create a new test server via CLI.

And these are the commands that I use to manage them, in no particular order. “Ubuntu Server” is just an example name, matching whatever the name is that you’ll see when you open the VirtualBox Manager.

IP addresses:
It doesn’t seem to be possible to get a VM’s ip address using VBoxManage if they’re a bridged adapter. (The listed solutions online don’t work.) The best I can find is “nmap -sP 192.168.1.*”, which will list all IP addresses on the network. If it’s run both before and after the VM is started, the IP should be found.

List all VMs:
VBoxManage list vms

List all running VMs:
VBoxManage list runningvms

Start VM:
VBoxManage startvm "Ubuntu Server" --type headless

Pause VM:
VBoxManage controlvm "Ubuntu Server" pause --type headless

Restart paused VM:
VBoxManage controlvm "Ubuntu Server" resume --type headless

Shut down VM:
VBoxManage controlvm "Ubuntu Server" poweroff --type headless

Change network adaptor to bridged:
VBoxManage modifyvm "Ubuntu Server" --nic1 bridged

Clone vm:
VBoxManage clonevm "Ubuntu Server" --name "New Ubuntu Server" --register

• If forget the “register” option, the “registervm” command is supposed to fix that, but I can’t get it to work. In that case, best to start over and delete the newly-created folder in ~/VirtualBox\ VMs
• If forget the “name” option, it will just have the old name plus “clone”.

Delete vm:
VBoxManage unregistervm "Ubuntu Server" --delete

(Just when you thought WP couldn’t get more irritating, they add “blocks”, as well as deleting content after minimizing windows.)

Found on StackOverflow, thought I’d post here for future reference and possibly to help others:

Make windows sizes in Vim equal with Ctrl+w,=

Probably every good program has a few irritating anti-features. One of Vim’s aggravating quirks is that it loads plugins after vimrc, which means that some of those plugins may or may not override some settings. (The most frustrating one for me is that I like to have formatoptions set to nothing, but many plugin devs have decided that they know my typing habits better than I do.)

Customizability is extremely important to me, and these plugins really begin to wreak havoc on my workflow.

Probably the best thing to do would be to track those plugins down and edit them manually. Whenever you find a setting that’s being overridden, in this example we’ll use formatoptions, run :verbose set formatoptions?. This will tell you what offending script set it.

Unfortunately, this will likely only be an option if you have root access, because the plugins are in /usr/share/vim/vimXX/* (where “XX” is the Vim version). I have this problem in Termux’s default Vim installation, but that’s resolvable because I have root access to edit these files. However, I’m currently in a situation with a client in which I don’t have root access.

There is a good workaround that I found online, but it’s not perfect. Unfortunately, the website has been down since before I even found the site, but the search results looked promising enough that I checked Google’s cache, and it revealed a pretty good solution. Kind of an obvious solution, but a good one nonetheless.

The direct link is here, but, as I write this, I haven’t been able to reach it (including while using a proxy server).

At any rate, since I don’t know how long Google keeps their cache up, I thought I’d go ahead and duplicate it here (with a few minor changes), in case the website is gone for good.

What we need to do is take advantage of Vim’s “after” functionality, so it will reload $HOME/.vimrc after every plugin is loaded. (You may have some luck with $MYVIMRC, but I’ve found that there are many cases in which $MYVIMRC isn’t even set.) There’s a simple BASH script to do this, and it’s so short that I usually just type it directly into the terminal instead of making an individual script file.

(TL;DR version: Start here)

Please note that there’s a good chance that you’ll need to change the directory path from /usr/share/vim/vim74 to something else. It was only recently that Vim updated to 8.0, and a lot of systems (mine included) don’t use it, and some are still on 7.1. You’ll just need to figure out what directory to use.

    mkdir -p ~/.vim/after/ftplugin
    rm -i ~/.vim/after/ftplugin/*
    for file in /usr/share/vim/vim74/ftplugin/*.vim; do
        ln -s ~/.vimrc-after ~/.vim/after/ftplugin/`basename $file`
    done

Now, Vim will automatically load whatever’s in $HOME/.vimrc-after after loading any plugin. I just put source $HOME/.vimrc in mine. This means it’ll resource my vimrc every time it loads a plugin.

This is not ideal because it means resourcing a settings file every time you open a new file, but, from a pragmatic standpoint, it helps a whole lot more than it hurts.

I went through a headache today when I discovered that emails were no longer being sent from Threadstr. I couldn’t figure out what had changed because I haven’t actually touched it in quite awhile. Both my local development and threadstr.com had stopped working and with the same error message: “Error: Invalid login: 535 5.7.0 Incorrect username or password.” I had changed no settings since the last time it was working on either, I had made no changes to the domain registration, and the username and password were correct.

Well, it turns out that something changed on FastMail’s side. I’m not exactly sure specifically what they did, but they no longer let you programmatically send mail using the same password that you use to log in to the frontpage. You now need to create a new password specifically for your application.

It’s actually a good idea, but I sure wish they had let me know about this before they implemented it, because it completely broke Threadstr functionality. I can’t even find an announcement for it– I had to dig through the settings in a wild madcap adventure to find something, anything that could have caused the service to suddenly stop working.

(Irritated as I am, I’m making no plans to change to another email provider, because they’ve still been great so far.)

At any rate, I thought I’d make a post in case this helps anybody else. If you can’t get FastMail to work with something like NodeMailer or PHPMailer, or if it suddenly stopped, it could be this. Below are screenshots of the FastMail settings that will solve the problem.

Use the password generated here instead of the regular password in your application, and you’re golden.