TL;DR

Usage

ptt(1) can be used from the command line to quickly format a file with delimiter-separated values into a plain text table. However, it can also manipulate its cells, rows and columns by using a unique character called the cursor (a tilde by default) to keep track of the row and column of the table that is currently being manipulated. This is what allows scriptable editors to interact with ptt. Essentially, for an editor to interact with ptt, it needs to do the following:

1. Insert cursor character at current location in table.
2. Pipe table into ptt to perform an operation.
3. Read ptt’s output.
4. Search for cursor character, move to it, and delete it.

Depending on the operation that is performed on the table, ptt will position the cursor character such that when the editor reads its output, it can know where to move the actual editor cursor.

For example, assume that the following is the content of a file that is open in vim and vim’s cursor is at the ‘X’:

| Item    |XPrice [$] | Qty. |
|---------+-----------+------|
| Lemons  |      3.00 | 2.00 |
| Apples  |      2.00 | 4.00 |
| Chicken |     10.00 | 1.00 |

The ‘Price’ column can be moved to the right by running the following in vim:

:execute "normal i~\<Esc>vap:!ptt column right -\<CR>/\\~\<CR>r "

This results in the following table, where the second column is now the third and vim’s cursor followed the motion.

| Item    | Qty. |XPrice [$] |
|---------+------+-----------|
| Lemons  | 2.00 |      3.00 |
| Apples  | 4.00 |      2.00 |
| Chicken | 1.00 |     10.00 |

All the macro did is to perform the four steps mentioned above. However, instead of writing these confusing macros manually, one would ideally write bindings for their editor of choice to interact with ptt. At the time of writing I have implemented bindings for the vim and vis editors. These can be used as examples by anyone wishing to write bindings for another editor.

I’m aware that calling an external tool for every operation performed on a table is not very efficient. However, I believe it is a worthy trade-off to enable different editors to benefit from ptt. Furthermore, ptt is written in POSIX awk(1), which makes it very fast, portable, and free of dependencies.

$ firefox file:///path/to/page/index.html

This worked fine until I decided to use absolute paths in the navigation bar links, e.g., /gallery.html instead of ../gallery.html, causing firefox to look for the file /gallery.html¹ instead of /path/to/page/gallery.html. When looking for an alternative, I found the one-liner

$ python3 -m http.server

which can be run from the root directory of the website to serve the files on port 8000 of localhost. This is really cool…, but it requires python. I could try with perl, which is shipped with OpenBSD, but I would probably need to install a module such as HTTP::Server::Simple. So, I turned to see if I could achieve something similar with httpd(8), OpenBSD’s HTTP daemon. It turns out, it is quite simple. It is not a one-liner, but a configuration file like the following is enough:

$ cat ./httpd.conf
chroot "."

server "local" {
    listen on localhost port 8000
    root "."
    no log
}

With this, serving a website locally is as simple as running

$ cd /path/to/page
# httpd -df /path/to/httpd.conf

and navigating to http://localhost:8000 in the browser.

\usetikzlibrary{shadings}
\begin{tikzpicture}
    \shade[ball color=blue] (0,0) circle (1);
\end{tikzpicture}

For my master’s thesis, I wanted to use this to draw the symbol for the center of gravity, conventionally a quartered black-and-white circle, but for a three-dimensional drawing. However, I couldn’t find any examples in the documentation of the ball shading applied to multiple paths. So, I just tried.

\usetikzlibrary{shadings}
\begin{tikzpicture}
    \shade[ball color=white] (0,0) -- (-1,0) arc (180:90:1)
        -- (0,-1) arc (270:360:1) --cycle;
    \shade[ball color=black] (0,0) -- (1,0) arc (0:90:1)
        -- (0,-1) arc (270:180:1) --cycle;
\end{tikzpicture}

To my surprise, it worked! But why? Well, it turns out that I just got lucky. Apparently, the shading is applied relative to the bounding boxes of the individual paths. Since both paths have rectangular bounding boxes with lower left corners at (-1,-1) and upper right corners at (1,1), their shadings overlap. Had I drawn the same symbol with four paths such that their bounding boxes did not coincide, this would not have worked.

\usetikzlibrary{shadings}
\begin{tikzpicture}
    \shade[ball color=white] (0,0) -- (-1,0) arc (180:90:1) --cycle;
    \shade[ball color=white] (0,0) -- (1,0) arc (360:270:1) --cycle;
    \shade[ball color=black] (0,0) -- (0,1) arc (90:0:1) --cycle;
    \shade[ball color=black] (0,0) -- (0,-1) arc (270:180:1) --cycle;
\end{tikzpicture}

        function(entry)        
   +----------------------+    
   v                      |    
+------+  function   +--------+
| mutt | ----------> | script |
+------+             +--------+

To honor the unix philosophy, I ended up writing two short scripts instead of one: file_menu for selecting files and mbox_menu for selecting mailboxes. These can be used with any mutt function that requires a file or a mailbox as an argument e.g. <attach-file> or <change-folder>.

TL;DR

Usage

The scripts rely on mutt’s source command, which in addition to evaluating configuration files, it can also evaluate the output of a script when the filename is suffixed with a pipe (‘|’).

source /path/to/script|

The file_menu script is meant for selecting multiple files². For example, it can be used with mutt’s <attach-file> function, to attach files in bulk:

$ file_menu attach-file
push <attach-file>/path/to/file_1.txt<Return>\
    <attach-file>/path/to/file_2.txt<Return>\
    <attach-file>/path/to/file_3.txt<Return>

The following macro maps the ‘a’ key³ to attach files from mutt’s compose screen using the file_menu script.

macro compose a \
'<enter-command>source "/path/to/file_menu attach-file"|<Return>' \
'attach files with fzf'

The mbox_menu script is meant for selecting a mailbox. For example, it can be used with mutt’s <change-folder> function to switch between mailboxes:

$ mbox_menu change-folder
push <change-folder>+INBOX<Return>

The following macro maps the space bar to switch between mailboxes from mutt’s index and pager screens using the mbox_menu script.

macro index,pager <Space> \
'<enter-command>source "/path/to/mbox_menu change-folder"|<Return>' \
'open a mailbox with fzf'

Source

$ cat file_menu
#!/bin/sh

FILES=$(fzf --height=100% --multi)

printf 'push '
for i in $FILES
do
    [ -f "$i" ] && printf '<%s>%s<Return>' "$1" "$i"
    [ -d "$i" ] && find "$i"/* -type f -maxdepth 0 \
        -exec printf '<%s>%s<Return>' "$1" {} \;
done

$ cat mbox_menu
#!/bin/sh

list()
{
    # your command to list mailboxes
}

MAILBOX=$(list | fzf --height=100% | sed 's/ /%20/g')

if [ -n "$MAILBOX" ]
then
    printf 'push <%s>+%s<Return>' "$1" "$MAILBOX"
fi

Ideas

These scripts are not limited to the examples shown here. After all, the idea was to make them as generic as possible for them to be flexible and reusable. Below are some other ideas on how these scripts can be used:

mbox_menu:

• Move/Copy tagged messages to another mailbox
• Switch between accounts with folder hooks by listing mailboxes of multiple accounts

file_menu:

• Save an attachment to a specific folder
• Change the current working directory

One of the programs that felt a little extra in my setup was dunst, which in the words of it’s author is a lightweight and customizable notification daemon. I rarely need or get notifications, yet I kept a full blown configuration to make them pretty. So, to get rid of dunst without losing notifications completely, I came up with a setup that makes use of the status bar of suckless’ dynamic window manager (dwm), my window manager of choice, to display notifications.

TL;DR

Configuring the status bar

For context, the dwm’s status bar uses the name of the X11 root window¹ as it’s source of text to display in the status bar. This property can be set to anything (usually the output of a command e.g. date(1)) and updated indefinite times. For example, the following shell script displays the date and time in the status bar and updates it every second:

$ cat statusbar
#!/bin/sh

while true; do
    xsetroot -name "$(date)"
    sleep 1
done

This script can now be run in the background before starting dwm from an X11 startup script to have it continuously display the date in the status bar for the entire session.

Displaying notifications

To display notifications in the status bar (if any), the above example can be updated as follows:

$ cat statusbar
#!/bin/sh

while true; do
    if [ -s "/tmp/nqueue" ]; then
        printf "1p\n1d\nw\n" | ed -s /tmp/nqueue
        touch /tmp/nlock
    else
        date
    fi | xargs -I{} xsetroot -name '{}'

    if [ -f "/tmp/nlock" ]; then
        sleep 10
        rm -f /tmp/nlock
    else
        sleep 1
    fi
done

The script monitors the file /tmp/nqueue, which acts as a queue of notifications (one message per line). The queue follows the First in, First out (FIFO) principle. That is, the oldest message (first line) is displayed in the status bar and removed from the queue, after which the second message becomes the first and the cycle is repeated until there are no more messages. When the queue is empty, the status bar reverts to displaying the output of the date command.

In addition, when a notification is displayed in the status bar, a lock file (/tmp/nlock) is created to prevent new notifications from overwriting the current one (see the notify script below). However, the frequency at which the status bar is updated to show the next available notification or to update the output of the date command is also regulated by the presence or absence of this file.

Finally, to add a notification to the queue, a script like the following can be used:

$ cat notify
#!/bin/sh

echo "$1" >> "/tmp/nqueue"
[ ! -e "/tmp/nlock" ] && sbreset

This will append the first argument passed to the script (the notification message) to the queue, and force the status bar to be updated with the following sbreset script if a lock file doesn’t exist:

$ cat sbreset
#!/bin/sh

PID=$(pgrep -f statusbar)
[ -n "$PID" ] && pkill -P "$PID"

The script simply finds the PID of the statusbar script and kills its child processes, causing a new loop iteration to begin. That’s it! Once dwm has been restarted with the updated statusbar script, notifications can be queued as follows:

$ notify "Example notification"

Bonus

The right mouse button can be mapped to execute the sbreset script to force a status bar update in dwm’s config.h file:

static const char *sbreset[] = {"sbreset", NULL};
static Button buttons[] = {
    ...
    {ClkStatusText, 0, Button3,  spawn, {.v = sbreset}},
    ...
};

The update causes any notifications that are being displayed to be cleared before their time expires, mimicking the behaviour of dunst.