Pro-tip: The first step is always to inspect the log file produced by the compilation. In my case, I saw that the journal’s version of TeX Live is from 2013 — 6 years old! This turned out to be the source of both problems below.

1. Fixing old versions of TeX Live with fixltx2e

The first problem was that I kept getting an error regarding my use of \textsubscript. It took me longer than I care to admit to just google the issue. The first result was this Stack Exchange thread, which reveals that before 2015, you needed to use the fixltx2e package to properly use \textsubscript. So I added

% Fix LaTeX2e (needed for JoS's 2013 version of TeX Live)
\usepackage{fixltx2e}

to my preamble.

If you’re using an up-to-date version of TeX Live, this will produce a warning letting you know that you don’t need this package anymore.

2. Using a package that the journal doesn’t have

The second problem was that the journal doesn’t have the ExPex package. (This package was only written in 2014, a year after the journal’s version of TeX Live, and only available as part of TeX Live since 2017.)

In theory, this shouldn’t pose a huge problem, because the journal allows you to upload “supplementary TeX/LaTeX files” — meaning you can just upload the source files to any package that’s missing.

In the case of ExPex, those files would be:

expex.sty
expex.tex
epltxfn.sty

(expex.sty is just a wrapper for expex.tex. There’s also epltxchapno.sty, but that’s for works with chapters.)

The problem I encountered was that the journal was trying to convert expex.tex to a PDF, which was producing a bunch of errors — because that file isn’t intended to be converted into a PDF — and the system won’t let you complete submission if there are any unconverted TeX files.

On a hunch, I renamed expex.tex to expex (i.e. I removed the extension). Thankfully…

1. The journal didn’t complain much. (It did give me a warning about no extension, but it let me continue anyway.)
2. It no longer tried to convert expex to PDF.
3. The missing ExPex package worked seamlessly even with the missing .tex extension on the main file.

3. Re-running Biber (or BibTeX) to fix citations

This is something I couldn’t solve: although the system produced a PDF, it didn’t produce proper citations, or print a bibliography. Usually, this means that Biber (or BibTeX) needs to be re-run, but I couldn’t force the system to do that from my end.

The problem could be because I use Biblatex/Biber instead of the traditional BibTeX. I tried forcing the Biber backend by adding the directive

% !BIB TS-program = biber

to the top of the TeX file, but that didn’t work. (This is apparently only for TeX Shop, which I guess the journal doesn’t use. I’m not sure if there’s a more general directive, or a directive for latexmk, similar to the %&pdflatex directive that I discussed in my previous post.)

The problem could also be because the journal uses plain pdflatex rather than something like latexmk, which takes care of Biber/Biblatex and multiple compilations.

In any case, I was able to complete my submission (along with my own PDF, with all the citations and bibliography), because of the solutions to the first two problems.

%&pdflatex
\documentclass{article}
\begin{document}
Hello, world!
\end{document}

In my case, I was getting errors along the lines of

! LaTeX Error: Cannot determine size of graphic in figure.pdf (no BoundingBox)

This is an indication that the backend compiler is plain latex (trying to create a DVI), which is unable to determine the size of PDF, PNG, or JPG images. (If this is your only problem, then another solution is to use EPS images instead, which should be handled just fine by plain latex.)

More info in the following TeX StackExchange threads:

• Cannot determine size of graphic
• Cannot determine the size of the image
• pdflatex producing dvi output instead of pdf

I had begun in 1733 to study languages; I soon made myself so much a master of the French as to be able to read the books with ease. I then undertook the Italian. An acquaintance, who was also learning it, us’d often to tempt me to play chess with him. Finding this took up too much of the time I had to spare for study, I at length refus’d to play any more, unless on this condition, that the victor in every game should have a right to impose a task, either in parts of the grammar to be got by heart, or in translations, etc., which tasks the vanquish’d was to perform upon honour, before our next meeting. As we play’d pretty equally, we thus beat one another into that language. I afterwards with a little painstaking, acquir’d as much of the Spanish as to read their books also.

I have already mention’d that I had only one year’s instruction in a Latin school, and that when very young, after which I neglected that language entirely. But, when I had attained an acquaintance with the French, Italian, and Spanish, I was surpris’d to find, on looking over a Latin Testament, that I understood so much more of that language than I had imagined, which encouraged me to apply myself again to the study of it, and I met with more success, as those preceding languages had greatly smooth’d my way.

From these circumstances, I have thought that there is some inconsistency in our common mode of teaching languages. We are told that it is proper to begin first with the Latin, and, having acquir’d that, it will be more easy to attain those modern languages which are deriv’d from it; and yet we do not begin with the Greek, in order more easily to acquire the Latin. It is true that, if you can clamber and get to the top of a staircase without using the steps, you will more easily gain them in descending; but certainly, if you begin with the lowest you will with more ease ascend to the top; and I would therefore offer it to the consideration of those who superintend the education of our youth, whether, since many of those who begin with the Latin quit the same after spending some years without having made any great proficiency, and what they have learnt becomes almost useless, so that their time has been lost, it would not have been better to have begun with the French, proceeding to the Italian, etc.; for, tho’, after spending the same time, they should quit the study of languages and never arrive at the Latin, they would, however, have acquired another tongue or two, that, being in modern use, might be serviceable to them in common life.

The idea to use the outcomes of chess games as a way to learn languages is pretty cool (and amusing), of course, but I was particularly struck by Franklin’s progressiveness regarding the classical languages. I can’t imagine that many people at that time shared that view.

What to do? Abandon Git when collaborating? (No!) Force your collaborators to learn Git? (Ye… No!)

Solution: Use both! All you need to do is tell Dropbox to ignore all Git-specific files, and tell Git to ignore all Dropbox-specific files. While that sounds pretty simple, there are a few important caveats to watch out for. Here’s how to do it.

Step 1: Get the Dropbox command-line program

The first thing you’ll need is the Dropbox command-line program. Depending on your Linux distribution, this program may already come with your Dropbox package, or it may be available as a separate package (on Arch Linux, the package is separate and is called dropbox-cli). Or you can just download the Python script directly. For concreteness, I’m going to call this program dropbox, but on your machine it may be called dropbox.py, dropbox-cli (Arch Linux), etc.

dropbox provides a number of commands. Run dropbox help to see them all.

The one we care about is the exclude command, which allows you to exclude specific files/directories from sync’ing to Dropbox.

You can run dropbox exclude list to list all excluded files, dropbox exclude add [file] ... to add a file to the exclude list, or dropbox exclude remove [file] ... to remove a file from the exclude list.

By the way, even though dropbox help exclude mentions only directories, you can actually exclude both directories and plain files. (That’s probably because on Unix, everything is a file.)

See this article on the Dropbox wiki for more information.

Step 2: Start Dropbox

At this point, you can already start Dropbox. So, in a terminal, run:

$ dropbox start

Protip: Use the command

$ dropbox start && watch -n1 dropbox status && dropbox stop

to continually (every second) watch the Dropbox status, or better yet, create an alias for it called db, as I previously described in this post.

Step 3: Start a new project

Now we start our new project, e.g. LaTeX manuscript. (If you used the db alias/command above, then fire up a new terminal.) Let’s call the project project, because we’re not creative:

$ mkdir ~/Dropbox/project
$ cd ~/Dropbox/project

From here on out, I’m going to assume that every command is run from inside ~/Dropbox/project.

Step 4: Exclude Git files from Dropbox sync

With Dropbox running, we’re going to preemptively exclude two Git-related things: the directory .git and the file .gitignore, both of which will be created in the next step.

# Run this from inside ~/Dropbox/project!
$ dropbox exclude add .git .gitignore
Excluded:
.git
.gitignore

Dropbox confirms that it excluded the files, but you can double-check that it worked by running:

$ dropbox exclude list
Excluded:
.git
.gitignore

Note that .git and .gitignore don’t even exist yet! In other words, you can tell Dropbox to exclude stuff before even creating it. In fact, you should do this. More about that at the end.

Step 5: Exclude Dropbox files from Git tracking

Now we turn project into a Git repository in the usual way:

$ git init

This creates the directory .git. Since we previously excluded this directory from Dropbox sync, Dropbox won’t actually do anything here.

If you check Git’s status:

$ git status

you may see an untracked file called .dropbox. We want Git to ignore that, so we create the file .gitignore and add .dropbox to it:

$ echo ".dropbox" > .gitignore

Again, since we previously excluded .gitignore, Dropbox still won’t do anything.

Now, when you run git status, you won’t see .dropbox.

Note: This step may no longer be necessary. When I tested this just now, Dropbox did not create a .dropbox file, and all the .dropbox files in my Dropbox are many months old. So it may be that the newest version of Dropbox no longer creates a .dropbox file (or that the .dropbox file is coming from one of my collaborators’ versions of Dropbox). Still, it can’t hurt to add it to your .gitignore.

Step 6: Profit

Now you can work as usual, sync’ing to Dropbox and committing changes to Git as you normally would. The two will not step on each other’s toes.

The really nice thing about this method is that when you sync your collaborators’ changes to your machine over Dropbox, you can run

$ git status

to see which files were added, deleted, or changed, as well as

$ git diff

or (my preference)

$ git diff --word-diff=color

to see exactly what changes were made by your collaborators since your last Git commit.

Protip: Before doing new work on your project, and definitely before sync’ing over Dropbox, I highly recommend checking https://www.dropbox.com/events to see if anyone has made any changes. If so, then pull in the changes first, review and commit them with Git:

$ git commit -am "Merge Alice's changes"

and then start your work. (Otherwise, Dropbox will create a conflicted copy, and then you’ll have to manually merge your conflicted copy with your collaborator’s copy.)

Important warning!

For some reason that I don’t understand at all, if you run:

$ dropbox exclude add foo

and foo already exists, then Dropbox will actually delete foo! Therefore, if you decide you want to exclude a file from sync’ing over Dropbox, but it’s a file that you want to keep locally, be sure to move the file out of your project folder first (or make a copy of it).

For example, let’s say that I’ve created a file notes that contains my own notes for a collaborative project. My colleagues don’t care to see that, so I decide to exclude it:

# From inside ~/Dropbox/project!
$ mv notes /tmp                # move notes to /tmp
$ dropbox start                # start Dropbox, if not already running
$ dropbox exclude add notes    # exclude notes
$ mv /tmp/notes .              # move notes back to project

If you accidentally exclude add a file that already exists, and Dropbox deletes it, don’t worry: you can manually download the deleted file by going to the Dropbox website, navigating to your project, and making sure to “Show deleted files”. Once you’ve downloaded the deleted file, move it into your project directory, and Dropbox won’t do anything with it, since it’s been excluded.

Step 7 (bonus): Multiple versions of a file or directory

Since your colleagues don’t use Git, they may be in the habit of creating entirely new files or directories when they implement (major) changes, which on first glance may look disastrous.

For example, suppose your project starts with the following state:

$ ls -a project
./ ../ .git/ .gitignore paper.tex paper.pdf

You start Dropbox, and then when you run git status, you notice that all your files have been deleted, and in their place you now have two untracked directories!

$ git status
Changes not staged for commit:

    deleted: paper.tex

Untracked files:

    v1/
    v2/

What happened, of course, was that your colleague moved the old paper.tex and paper.pdf into a new directory called v1, copied them into another new directory called v2, and then made their changes in the v2 version.

$ ls -a project
./ ../ .git/ .gitignore v1/ v2/
$ ls -a v1 v2
v1:
./  ../  paper.pdf  paper.tex

v2:
./  ../  paper.pdf  paper.tex

Assuming they haven’t made any filename changes, all you have to do is move .git and .gitignore from the top-level project directory to the new v2 directory, and then run git status to see the new changes.

However, before you do that, make sure to exclude v2/.git and v2/.gitignore!

$ dropbox exclude add v2/.git v2.gitignore
Excluded:
v2/.git
v2/.gitignore
$ mv .git .gitignore v2
$ cd v2
$ git status

You can also now un-exclude the old top-level Git files:

$ cd .. # move back to ~/Dropbox/project
$ dropbox exclude remove .git .gitignore
No longer excluded:
.git
.gitignore

In addition, Arch’s xmobar (with xmonad-0.13-8) has been crashing sporadically (segmentation faults), for some reason. See here, for instance.

In this post, I’ll explain how I got xmonad (and xmonad-contrib) and xmobar installed and working – and no xmobar crashes, so far – via stack. I’ll try to keep it as short and simple as possible. No in-depth explanations; just a straightforward, step-by-step rundown of what I did. The usual disclaimers (YMMV, etc.) apply.

I’ll assume you already have an ~/.xmonad directory with an xmonad.hs config file. If you don’t use xmobar, this post can still be useful; just ignore the lines/steps that refer to xmobar.

Step 1: Get stack

There are couple ways to get stack. I installed stack-static from the AUR, because it doesn’t come with any Haskell dependencies.

If you don’t care about tracking stack with your package manager, then, as the stack how-to-install explains, just run

curl -sSL https://get.haskellstack.org/ | sh

or

wget -qO- https://get.haskellstack.org/ | sh

Step 2: Install GHC with stack

To build and install Haskell packages, we need GHC. Simply run

stack setup

to install GHC into ~/.stack. Useful for the kind of sandboxing projects that we’re doing with xmonad.

NB: You can run stack ghc to do things with GHC, stack ghci to fire up interactive GHC, and so on.

Step 3: Get xmonad, xmonad-contrib, and xmobar

We’ll be turning our ~/.xmonad directory into a stack project, so first, head over there.

cd ~/.xmonad

For the remainder of this post, I’ll assume you’re inside ~/.xmonad.

Next, download the xmonad, xmonad-contrib, and xmobar Git repositories, which contain the .cabal and .yaml files that stack will look for in the next step. I like to add -git to their directory names, just as a reminder.

# From inside ~/.xmonad.
git clone "https://github.com/xmonad/xmonad" xmonad-git
git clone "https://github.com/xmonad/xmonad-contrib" xmonad-contrib-git
git clone "https://github.com/jaor/xmobar" xmobar-git

Your ~/.xmonad directory should now contain xmonad-git, xmonad-contrib-git, and xmobar-git, each of which contains a .cabal file and a .yaml file.

Step 4: Initialize stack

This step is easy: just run

# From inside ~/.xmonad.
stack init

Stack will find the .cabal and .yaml files and auto-create the file stack.yaml for you. It’ll look like this:

# ~/.xmonad/stack.yaml
resolver: lts-9.6
packages:
- xmobar-git
- xmonad-git
- xmonad-contrib-git
extra-deps: []
flags: {}
extra-package-dbs: []

At this point, you can modify stack.yaml to add flags, etc. The only change I made was to add the flag all_extensions to xmobar, by changing

flags: {}

to

flags:
  xmobar:
    all_extensions: true

This flag provides all the xmobar bells & whistles, like support for xft, mpd, battery, wifi, etc.

NB: If you add the with_iwlib flag (or all_extensions), you’ll need to also install the iwlib C library and headers. In Arch Linux, just install wireless_tools; in Debian-based systems, libiw-dev. Or, in your stack.yaml, change

extra_deps: []

to

extra_deps:
    - iwlib-0.1.0

(The specific version you’ll need will change over time. If stack install from step 5 produces an error, just see what stack recommends.)

Step 5: Build and install everything

Next, run

# From inside ~/.xmonad.
stack install

to build and install xmonad, xmonad-contrib, and xmobar (and all their dependencies). You’ll now have two new binaries, xmonad and xmobar, installed into ~/.local/bin.

NB: You’ll want to add ~/.local/bin to your PATH, if it isn’t already. (If you use a login manager, see Step 9 below.)

Step 6: Write a build file

Since we’re doing everything via stack, rather than ghc directly, xmonad --recompile won’t quite work yet. As of xmonad 0.13, we can write a custom build script, named build and located inside ~/.xmonad, which will use stack ghc to recompile xmonad. (Borrowed from pbrisbin.)

# ~/.xmonad/build
#!/bin/sh
exec stack ghc -- \
  --make xmonad.hs \
  -i \
  -ilib \
  -fforce-recomp \
  -main-is main \
  -v0 \
  -o "$1"

Make sure it’s executable:

chmod a+x build

Step 7: Recompile and restart xmonad

You should now be able to recompile and restart xmonad (and xmobar) with

xmonad --recompile && xmonad --restart

NB: I had to restart my computer in order for xmobar to start up properly – probably because xmonad couldn’t find the xmobar binary.

Step 8: Updating

Whenever you update your xmonad, xmonad-contrib, or xmobar repositories, just cd ~/.xmonad and run

stack install

to rebuild and reinstall everything.

NB: If you add a new flag or extra dependencies (in stack.yaml), you may need to run stack clean first.

(Step 9: Loose ends with login managers)

If you use a login manager, such as LightDM, then you may need to take some additional steps. I don’t use a login manager, nor do I know much about them, but I’ll use LightDM as the working example since I’ve read a little about it.

First off, LightDM uses *.desktop files located /usr/share/xsessions to know which desktop environments (or window managers) you have available to choose from. So, you’ll probably need to create xmonad.desktop. The xmonad package from the official Arch repos installs the following file, so you can just copy it verbatim and place it into /usr/share/xsessions:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Xmonad
Comment=Lightweight X11 tiled window manager written in Haskell
Exec=xmonad
Icon=xmonad
Terminal=false
StartupNotify=false
Categories=Application;

Second, running xmonad --recompile may not work yet. If it doesn’t, make sure that you’ve added ~/.local/bin to your PATH by adding it to one of your shell profile files, such as ~/.profile or (if you only use one shell, e.g. Bash) ~/.bash_profile, and not to your shell’s configuration file (e.g. ~/.bashrc). The reason is that LightDM (and by extension xmonad) is invoked from a login shell, which sources profile files like ~/.profile, but not (necessarily) shell config files like ~/.bashrc. See this SE thread and this Quora answer to learn more about the difference.

If that still doesn’t work, then it’s possible that your login manager doesn’t even source ~/.profile (see the end of the SE thread linked above). In that case, a possible fix is to just manually symlink ~/.local/bin/xmonad to /usr/bin (since the latter is definitely in your PATH; thanks to Ashesh in the comments below for this fix):

ln -s ~/.local/bin/xmonad /usr/bin

DECANUS · SCRIBUS MAXIMUS · RECTOR HONORARIUS · RECTRIX

We – the Governors, the Chancellor, and the Associates of McGill University – located in Montreal, Canada, send greetings to all those whom this document reaches. We – the Governors, the Principal and Vice-Chancellor, and the Associates of the university – attest that, since he has completed the prescribed curriculum of study with diligence and has duly carried out all the training charged to him, we have made Brian Anthony Buccola a Doctor of Philosophy and have granted him all the honors, rights, and privileges pertaining to that degree. To confirm this, we have taken care that this document be signed with the seal of the university and that the names of those in charge of academic affairs be signed below. Dated June 7, 2016.

Dean · Secretary-General · Honourable Chancellor · Principal and Vice-Chancellor

NB: I’ve translated the titles of the signatories by looking their names up and using their English titles. That’s why RECTRIX is translated as Principal and Vice-Chancellor, for instance. As for SOCII, I’m not sure if this refers to a specific body, with a specific title (e.g. the senate). Assuming it doesn’t (otherwise, I would’ve expected SENATUS, for example), the word can be translated as associates, members, fellows, or similar.

st (simple terminal), from the folks at suckless, is an extremely lightweight terminal emulator that also supports true color. It’s configured by editing a C header file, config.h, and then recompiling everything into a binary. For this reason, it doesn’t make sense to install st from the official repos (you’d just end up with a very basic, uncustomizable binary), nor does it really make sense to install it from the AUR, because you’ll inevitably want to modify the PKGBUILD to apply patches and do other things. Instead, your best bet is to create your own personal PKGBUILD (or modify an existing, similar one), which will apply the patches you want, copy over your custom config.h, and build st, which you can then make into a package with makepkg and install with pacman as usual.

Building and installing manually from source

The first step is to decide whether you want to use the stable release (currently st-0.7.tar.gz) or the development version (http://git.suckless.org/st). I originally went with the development version, but I was unable to apply patches (because the patches were created for the stable release, and I couldn’t find any more up-to-date versions of the patches). Therefore, in the end, I decided to go with the stable release, which also has the advantage that my terminal, which I rely heavily on, won’t break any time soon.

Step 1: Follow the installation instructions

The first step (after untarring the tarball and cd-ing into the st-x.x directory) is to install st exactly as the README says:

Installation
------------
Edit config.mk to match your local setup (st is installed into
the /usr/local namespace by default).

Afterwards enter the following command to build and install st (if
necessary as root):

    make clean install

Literally all I did was run sudo make clean install, and it worked. I could run st no problem.

Step 2: Configure config.h and apply some patches

Next, try and customize st a bit by editing config.h to your liking and applying some patches. Take note of exactly what you do. In my case, I applied the patches scrollback, hidecursor, and copyurl, by running patch -Np1 -i <patch> for each patch. Once you’re satisfied, it’s time to create a PKGBUILD.

Creating a PKGBUILD

First off, read the Arch Wiki entries on PKGBUILD and Creating packages. You can either create one from scratch (while following the Arch Wiki), modify the skeleton PKGBUILD /usr/share/pacman/PKGBUILD.proto, or modify an actual existing PKGBUILD. I decided to opt for the latter, and the existing PKGBUILD I chose to modify was the obvious one: st itself from community.

There are a number of ways to acquire an official PKGBUILD. Traditionally, you’d go the ABS route: install abs, clone the entire ABS tree (or at least the subtree of the repo containing st, i.e. community) onto /var/abs, then copy /var/abs/community/st over to something like ~/abs.

However, nowadays there are tools like asp and pbget that let you acquire the contents (PKGBUILD, etc.) of a single package without cloning an entire repo tree. So that’s what I did:

$ mkdir -p ~/.cache/asp
$ mkdir -p ~/builds
$ cd ~/builds
$ asp export st
$ cd st
$ ls
config.h PKGBUILD

Here I’ve used asp to export the st package, which comes with config.h (the configuration file) and PKGBUILD, the PKGBUILD. Now I just need to edit config.h in the same way I did in step 2 (easy part), and modify the PKGBUILD to apply the three patches I want (slightly harder part).

There are four main changes I made to the PKGBUILD. First, I added an array _patches with links to the three patches I want to apply:

_patches=("http://st.suckless.org/patches/st-scrollback-20170104-c63a87c.diff"
          "http://st.suckless.org/patches/st-hidecursor-20160727-308bfbf.diff"
          "http://st.suckless.org/patches/st-copyurl-20161105-8c99915.diff")

Second, I added the patches to the source array by adding "${_patches[@]}" to it…

source=("http://dl.suckless.org/st/$pkgname-$pkgver.tar.gz"
        "config.h"
        "${_patches[@]}")

…and of course added the patches’ corresponding hashes to the md5sums array. (Protip: Run updpkgsums to automatically do this.)

Third, it turned out that any patches which tried to patch config.def.h would lead to an error. This is because those patches — specifically, the scrollback and copyurl patches — define new functions (for scrolling back and for copying a URL) by modifying st.c and then bind keys to those functions by modifying config.def.h, but config.def.h is first overwritten by the custom config.h during the build stage, which later leads to a patch error. Therefore, I decided to (i) manually modify config.h to bind the relevant functions to some keys (easy), and then (ii) remove from those two patches the lines responsible for patching config.def.h, which happen to be the first 13 lines in the scrollback patch, and the first 12 lines in the copyurl patch:

# patch patches (don't let them patch config.def.h)
sed -i '1,13d' "$srcdir/$(basename ${_patches[0]})"
sed -i '1,12d' "$srcdir/$(basename ${_patches[2]})"

Fourth, and finally, inside of the prepare() function, I looped over each patch and applied them in the same way as I did in step 2 above:

for patch in "${_patches[@]}"; do
  echo "Applying patch $(basename $patch)..."
  patch -Np1 -i "$srcdir/$(basename $patch)"
done

See Patching in ABS for further details.

Putting it all together

That’s basically it. Now just run makepkg -si and make sure everything applies and installs correctly. Once it does, you should also run namcap on PKGBUILD and on the resulting *.pkg.tar.xz file to make sure there’s nothing wrong. In my case, namcap told me that the package didn’t actually depend on libxext or xorg-fonts-misc, even though the official PKGBUILD included those in the depends array, so I just removed them.

Before concluding, I want to mention two bonus tips.

Tip #1: To avoid config.h from being overwritten by some future asp export (supposedly, this can’t happen, but just to be safe), and to keep my config located among all my other configuration files, I moved config.h into ~/.config/st and then created a symlink to it from inside the build directory:

$ mkdir -p ~/.config/st
$ mv ~/builds/st/config.h ~/.config/st
$ ln -s ~/.config/st/config.h ~/builds/st

The directory ~/.config/st is not actually recognized by st in any way, but ~/.config is where most other apps put their configuration files, so it makes things tidier, especially since I version-control most things inside ~/.config with git.

Tip #2: What if you want to modify the patches themselves, i.e. patch a patch (apart from removing the error-prone lines mentioned above)? In my case, I wanted to modify the copyurl patch. By default, this patch patches st.c so that it allows you to copy any URL starting with http:// or https://, but I wanted to also be able to copy anything starting with ftp://, mailto:, or simply www.. So, here’s what I did.

First, I edited st.c by hand (after the copyurl patch had applied to it) in the way that I wanted, then manually reinstalled st to make sure it worked as expected. It did. I could’ve stopped here, but this isn’t really the elegant way to do things.

Next, I created a directory ~/builds/st/mypatches, and within that, two subdirectories, a and b. Inside a, I placed the post-copyurl-patched st.c file, and inside b, I placed my revised post-copyurl-patched st.c file, and then ran…

diff -u a/st.c b/st.c > ../st-copyurl-bb.diff

…to create a patch st-copyurl-bb.diff in the base package directory (alongside the other three patches).

Then I added this patch to the end of the _patches array, updated the hashes with updpkgsums, and re-ran makepkg -si, and everything worked out great.

So far, I’m extremely happy with st. It’s especially great to have a full range of colors in vim with minimal hassle, by adding these lines to my vimrc:

set termguicolors " Enable true color support.
let &t_8f = "\<Esc>[38;2;%lu;%lu;%lum"
let &t_8b = "\<Esc>[48;2;%lu;%lu;%lum"

It will not be my intention to do anything to benefit ANY American.

This is kind of a weird thing to say for someone who wants to run the U.S. Department of Housing and Urban Development, isn’t it?

More context (especially starting at 1:26):

(source)

Warren: Among the billions of dollars that you will be responsible for handing out in grants and loans, can you just assure us that not one dollar will go to benefit either the President-elect or his family?

Carson: “It will not be my intention to do anything to benefit ANY American. It’s for ALL Americans, everything that we do.”

Oh, I see now!

not [[an American]_x [it will be my intention [something_y [I do y to benefit x]]]]

Shout out to Andreas Haida for discussing this LF with me.

“You can imagine that a rational person would look at a cash discount, understand that it’s functionally the same as a credit card surcharge, and make his decision accordingly,” said Todd Rogers, a professor of public policy at Harvard. “But the cool and important contribution that behavioral science can make here is to highlight how people behave in reality, which is not in this so-called rational way.” The word “surcharge,” he said, prompts consumers to think about the price differential in a way that “discount” does not — which, in turn, has an effect on their willingness to use cash.

Here is the full text:

In its 144-year history, The Yale Record has never endorsed a Democratic candidate for president. In fact, we have never endorsed any candidate for president. This is, in part, due to our strong commitment to being a tax-exempt 501(c)3 organization, which mandates that we are “absolutely prohibited from directly or indirectly participating in, or intervening in, any political campaign on behalf of (or in opposition to) any candidate for elective public office.”

This year’s presidential election is highly unusual, but ultimately no different: The Yale Record believes both candidates to be equally unendorsable, due to our faithful compliance with the tax code.

In particular, we do not endorse Hillary Clinton’s exemplary leadership during her 30 years in the public eye. We do not support her impressive commitment to serving and improving this country—a commitment to which she has dedicated her entire professional career. Because of unambiguous tax law, we do not encourage you to support the most qualified presidential candidate in modern American history, nor do we encourage all citizens to shatter the glass ceiling once and for all by electing Secretary Clinton on November 8.

The Yale Record has no opinion whatsoever on Dr. Jill Stein.

—The Editorial Board of The Yale Record