The .Files

Automate Hugo Locally

Tue, 29 Dec 2020 00:00:00 +0000

Previous posts have covered how to automate the remote part of having one or more blogs using Hugo. The last (I hope) post in this series will do the same for your local machine.

Writing a new post involves going to the blog’s root directory, creating the blog post file with hugo new, then opening it in a text editor and start actually writing it.
That’s one step too many, so I made a shell script instead. Or rather, I made two: one for creating content and the other for pushing it to the repo.

Keep in mind I post semi regularly to 4 different blogs (and a couple local note files) so my current solution is a little more involved than what I’m presenting here, but it’s the same principle.

This is the relevant part of the script I use for creating posts:

articulo() {
    menuArticulo=$(printf "Fuckup\\nMuert.o\\nDotfiles\\nTextArt" | listar -p " ")
    case $menuArticulo in
    "Fuckup") cd "$ARTDIR/fuckup/blog" || exit ;;
    "Dotfiles") cd "$ARTDIR/club/the-dot-files" || exit ;;
    "TextArt") cd "$ARTDIR/town/textarrrgh" || exit ;;
    "Muert.o") cd "$ARTDIR/texto-plano/muert.o" || exit ;;
    esac
    [ -z "$menuArticulo" ] && exit
    nombre="$(listar -theme dprompt -p "Titulo: ")" 2>/dev/null
    [ -z "$nombre" ] && exit
    nombreForm="$(echo "$nombre" | tr ' ' '-')"
    if [ "$PWD" = "$ARTDIR/texto-plano/muert.o" ]; then
        hugo new articulos/"$nombreForm".md
        sleep 1
        abrir "$PWD/content/articulos/$nombreForm.md"
    else
        hugo new posts/"$nombreForm".md
        sleep 1
        abrir "$PWD/content/posts/$nombreForm.md"
    fi
}

$ARTDIR is the immutable part of the path where I keep all my Hugo files.
listar is a small function I use to pass variables to Rofi¹, which I use to generate GUI menus. With minor modifications, it could be replaced by FZF or perhaps a pure shell solution using select or something like that. abrir is another function that opens the created file in text editor in a floating terminal emulator window.
As mentioned before, this function is part of a larger script that can be found linked below.

The posting script is considerably simpler:

#!/bin/sh

MAINDIR="$HOME/doc/paginas/tilde"

subir() {
	if [ "$PWD" = "$MAINDIR/texto-plano/muert.o" ] || [ "$PWD" = "$MAINDIR/town/textarrrgh" ]; then
		hugo
	fi
	git add . && git commit -m "nuevo post"
}

listar() { rofi -dmenu "$@"; }

MENU="$(printf "Fuckup\\nMuerto\\nDotfiles\\nTextArt" | listar -p " ")"
case $MENU in
'Fuckup') cd "$MAINDIR/fuckup/blog" && subir || exit ;;
'Muerto') cd "$MAINDIR/texto-plano/muert.o" && subir || exit ;;
'Dotfiles') cd "$MAINDIR/club/the-dot-files" && subir || exit ;;
'TextArt') cd "$MAINDIR/town/textarrrgh" && subir || exit ;;
esac

It’s not the prettiest, but it gets the job done. At some point I imagine I will look up how to write better, less repetitive scripts. Haven’t found a way so far.
The way it works is pretty straightforward, cd into the directory and call a helper function that mostly does git stuff.
The git push command is conspicuously missing because I have set up a post-commit hook on my blog repos that automatically pushes after writing a commit message.

https://github.com/davatorium/rofi ↩︎

Hugo and Drone Simplified

Mon, 28 Dec 2020 00:00:00 +0000

What if for whatever reason it isn’t possible (or desirable) to run Hugo on the machine hosting your blog?
If this were the case, the system described in previous posts can still be used, albeit a little differently.

The steps required would be:

Generate the blog locally
Clean up the remote repository
Modify .gitignore
Modify Drone pipeline
Add the generated site to git

Generating the site locally is the easiest thing. Just run the hugo command on the blog’s root directory. This will create the public directory, with the rendered version.

To clean up the remote repository run the command git rm -r --cached content/ static/ layouts/ archetypes/ config.toml. This is just for the sake of cleanliness, having these directories under version control isn’t strictly necessary anymore. They could also be put on a separate branch, but I won’t go into that.

Take out public from .gitignore and add in the other directories like so:

resources/
content/
static/
layouts/
archetypes/
config.toml

Amend the Drone pipeline:

---
(rest of the file)

steps:
  - name: deploy
    commands:
      - cd /home/me/myBlog
      - git pull origin blog
      - cp -Rf public/* /home/me/public_html
      (do the gopher stuff, if necessary)
      - rm -r public

The gopher integration steps remain the same.
Now all there’s to do is git add public, write the commit message and push.

Hugo and Gopher

Wed, 16 Dec 2020 00:00:00 +0000

I’ve rediscovered gopher thanks to the tildeverse and figured I would give it a shot, once I was done setting up the web side of things. Well, the time has come and here I am, all ready to go.

However, I’m not too crazy about the idea of having to maintain two (or more) separate sets of content depending on the protocol. I’m pretty spread out as it is already.
So I started looking around for a way to generate gopher content from my preexisting Hugo markdown files. I didn’t have to search long, fortunately.

JFM’s blog¹ details a very simple way of getting it all together, and after some tweaking, I came up with a perfectly working solution.

The first part

Edit Hugo’s config.toml file and add the following lines:

[outputs]
  section = ["HTML", "gopher"]
  page = ["HTML", "gopher"]

[outputFormats.gopher]
  mediaType = "text/plain"
  path = "/~me/phlog"
  baseName = "gophermap"
  protocol = "gopher://"
  isPlainText = true

[outputFormats.HTML]
  noUgly = true

The content of your [outputs] section might vary depending on your needs, naturally, but this is the bare minimum required to get your posts converted.

The meat of the issue is the [outputFormats.gopher] section. As per the Hugo docs² we specify the required options to have the files be plaintext.
Generally path isn’t needed, but I wanted to have my blog (phlog, actually) be in a subdirectory. This will come into play during the deployment later.

I placed these additions at the bottom of my config file, then added uglyuRLs = true near the top. This option together with the [outputFormats.HTML] section provides clean permalinks for plaintext files while preserving the nice folder-like structure for web output.

The second part

Create the required layouts for the gophermap and phlog posts under layouts/_default.

layouts/_default/list.gopher.txt

1Go back	/me

{{ range .Pages.ByPublishDate.Reverse }}
0{{ .Date.Format "2006-01-02" }} {{ .Title }}	{{ with .OutputFormats.Get "gopher" -}} {{ .RelPermalink }}{{ end }}
{{ end }}

layouts/_default/single.gopher.txt

{{ .Title }}
{{ .Date.Format "2006-01-02" }}

{{ .RawContent }}

However, if you use manual summaries, replace {{ .RawContent }} with the following:

{{ $content := .RawContent -}}
{{ $content := $content | replaceRE "(?s:< !--more-- >)" "" -}}
{{ $content }}

This will remove the summary tag. Note that I had to include spaces in there to prevent Hugo from actually picking up the --more-- tag, so please make sure there’s no space in between the angle brackets and the rest of the tag.
I feel like this is a bug I should report…

The third part

Bring it all together in Drone’s pipeline. I added the following to the .drone.yml from my previous post:

...
steps:
  - name: deploy
    commands:
      (previous commands here)
      - cp -ruf /home/me/public_html/posts/~me/phlog.txt /home/me/public_gopher/phlog/gophermap
      - cp -ruf /home/me/public_html/~me/phlog/posts/*.txt /home/dgy/public_gopher/phlog/posts

The directory paths are a bit unwieldy and took some trial and error to get right, but I now have a “main” gophermap in public_gopher with a number of links and info about myself and the phlog in its own subdirectory.

Hugo, Gitea, and Drone CI

Thu, 10 Dec 2020 00:00:00 +0000

One of the many nice things about the tildeverse is that we have can have repos in tildegit. Another nice thing is it uses Gitea and Drone CI. Yay open source, and stuff.

Bashblog might be nice if all you want to do is write and post, but it’s not very nice when it comes to customization. Also I’ve been spoiled rotten by Gitlab/hub Pages and really wanted to set up something like that for the tildes.

And so, after much putting it off and asking people for help, I finally undertook the seemingly daunting (but actually easy although a bit tedious) task of setting all of this up.

I’ll be the first to admit I know jack shit about Docker, (and I should probably learn how to use it at some point since I have a spare box at home that I plan to use as a personal server of sorts), so my current solution may not be the best or most elegant but for the intents and purposes of setting this up I figured it wouldn’t be 100% necessary to create containers and such. And I would have never gotten this off the ground either, so there’s that.

After creating and testing my Hugo site locally, I pushed it all to a repo, activated it under Drone and got to work on the .drone.yml file.

A couple searches later, I was all set up with something I pulled from the Drone docs¹. Easy peasy… Or so I thought. I went with a combination of the Hugo plugin² and the rsync plugin³, which didn’t work at all. PEBCAK? I’m not so sure. For some reason, rsync wouldn’t pick up on the secrets I set up on the repo config. Oh well… I fell back to the solution the documentation proposes and used the scp plugin⁴, which does work. Or would have worked if there was something for it to copy… This is how I discovered the Hugo plugin didn’t work. Or didn’t work for me? I found a number of posts of people using it successfully. Mind you, these are all a couple of years old now.

At this point I scrapped all the remote stuff, went back to the docs⁵ for a fresh start, and decided to try a manual approach without using containers.

First, I recreated the repo setup in Drone and added the connection details as secrets. Second, I logged into my ~club account and cloned the repo. Then I recreated .drone.yml as follows:

---
kind: pipeline
type: ssh
name: deploy

server:
  host:
    from_secret: host
  user:
    from_secret: username
  ssh_key:
    from_secret: ssh_key

trigger:
  branch:
    - blog

steps:
  - name: deploy
    commands:
      - cd /home/me/myBlog
      - git pull origin blog
      - hugo --cacheDir ~/temp/
      - rm -r resources
      - cp -ruf public/* /home/me/public_html
      - rm -r public

This establishes an ssh connection, pulls the git repo, generates the static pages using hugo, and moves them to their designated location.

The trigger option makes sure the pipeline only works on the specified branch, this makes working on themes or whatever on a different branch easier, and it won’t eat up CI time.

Hugo’s default cacheDir is /tmp, which can’t be accessed by non admin users on tilde, so I set it to a directory I created.

Last but not least, I created a .gitignore with the following lines in it:

public/
resources/

public contains the generated blog and resources houses files used in the generation, they’re not needed in the repo.

BSPWM Multimonitor Support

Wed, 09 Dec 2020 00:00:00 +0000

I’ve seen a lot of people making posts on r/bspwm asking about this topic and unless you’re doing something particularly strange or are having trouble with your modern (and most likely nvidia) video card, you shouldn’t have much trouble getting this to work.

There’s also the matter of the odd workspace that gets created if one hotplugs a monitor in and out.

Leaving the aforementioned video card issues aside, all of these difficulties stem from people not knowing how bspwm works, people who expect it to work EXACTLY like i3 (or some other wm), people that don’t use the subreddit’s search function, etc.

The bspwm docs detail how the creation of workspaces happens, but the long and short of it is that you absolutely must assign them to a monitor. And while I’ve seen a couple scripts for creating workspaces on demand, I’ve never used them and can’t vouch for them.

Now to the solution. First, we create the workspaces and then we split them between our physical screens.

The first version

#!/bin/sh

M=$(bspc query -M --names)
NUM=$(echo "$M" | awk 'END{print NR}')

ettin() {
    sec=$(echo "$M" | awk NR==2)
    xrandr --output LVDS1 --primary --auto --scale 1.0x1.0 --output "$sec" --right-of LVDS1 --auto --scale 1.0x1.0
    bspc monitor LVDS1 -d 1 2 3 4 5
    bspc monitor "$sec" -d 6 7 8 9 10
}

cyclops() {
    xrandr --output LVDS1 --primary --auto --scale 1.0x1.0 "$(echo "$M" | awk '! /LVDS1/ {print "--output", $1, "--off"}' | paste -sd ' ')"
    bspc monitor -d 1 2 3 4 5 6 7 8 9 10
}

if [ "$NUM" = 1 ]; then
    cyclops
elif [ "$NUM" = 2 ]; then
    ettin
fi

This is a “pure bspwm” solution that uses xrandr and awk as its only dependencies. I’ve hardcoded LVDS1 (my laptop screen) as the primary output, but that could easily be replaced by a variable (just copy sec’s format) or whatever works for you. This could also be made to work for 3 or more screens, you just need to add more variables and split accordingly. Note that you could just as well assign 10 workspaces to each screen but that would make you run out of keys to bind them to pretty quickly. Call this script at the top of your bspwmrc and you’re good to go.

The second version

The first version works great as it is, but if for some reason you require a more “portable” solution, here’s my take.

#!/bin/sh

conectados=$(xrandr -q | awk '/ connected/ {count++} END {print count}')
pri=$(xrandr -q | awk '/ connected/ {print $1}' | sed -sn 1p)
sec=$(xrandr -q | awk '/ connected/ {print $1}' | sed -sn 2p)

if [ "$conectados" = 1 ]; then
    xrandr --output "$pri" --primary --auto --scale 1.0x1.0 "$(xrandr -q | awk '/ disconnected/ {print "--output", $1, "--off"}' | paste -sd ' ')"
elif [ "$conectados" = 2 ]; then
    xrandr --output "$pri" --primary --auto --scale 1.0x1.0 --output "$sec" --right-of "$pri" --auto --scale 1.0x1.0
fi

I created this version some months ago as i was messing around with some different window managers i found on the web, but they didn’t stick. Still, i kept the script because it’s a little bit cleaner i think, and it also let me separate concerns properly as I was using the previous version of the script to also set up my wallpaper and assign certain programs to different workspaces as well.

I had to resort to sed here, for reasons i haven’t taken the time to investigate, but the result is exactly the same.

I run this script from my .xinitrc and i run the following script from my bspwmrc

#!/bin/sh

M=$(bspc query -M --names)
NUM=$(echo "$M" | awk 'END{print NR}')

if [ "$NUM" = 1 ]; then
	bspc monitor -d 1 2 3 4 5 6 7 8 9 10
elif [ "$NUM" = 2 ]; then
	pri=$(echo "$M" | awk NR==1)
	sec=$(echo "$M" | awk NR==2)
	bspc monitor "$pri" -d 1 2 3 4 5
	bspc monitor "$sec" -d 6 7 8 9 10
fi

Addons

Here’s a script to switch back to a single screen

#!/bin/sh

pri=$(xrandr | awk '( $2 == "connected" ) { print $1 }' | sed -sn 1p)
xrandr --output "$pri" --primary --auto --scale 1.0x1.0 "$(xrandr | awk '( $2 == "disconnected" {print "--output", $1, "--off"}' | paste -sd ' ')"

if [ -e /tmp/bspwm_0_0-socket ]; then
    bspc config remove_disabled_monitors
    bspc config remove_unplugged_monitors
    bspc monitor -d 1 2 3 4 5 6 7 8 9 10
fi

And here’s a script to mirror screens

#!/bin/sh

screens=$(xrandr -q | awk '/ connected/ {print $1}')

grae() {
    external=$(echo "$screens" | dmenu -i -w 320 -p "Optimize resolution for: ")
    internal=$(echo "$screens" | grep -v "$external")

    res_external=$(xrandr --query | sed -n "/^$external/,/\+/p" | tail -n 1 | awk '{print $1}')
    res_internal=$(xrandr --query | sed -n "/^$internal/,/\+/p" | tail -n 1 | awk '{print $1}')

    res_ext_x=$(echo "$res_external" | sed 's/x.*//')
    res_ext_y=$(echo "$res_external" | sed 's/.*x//')
    res_int_x=$(echo "$res_internal" | sed 's/x.*//')
    res_int_y=$(echo "$res_internal" | sed 's/.*x//')

    scale_x=$(echo "$res_ext_x / $res_int_x" | bc -l)
    scale_y=$(echo "$res_ext_y / $res_int_y" | bc -l)

    xrandr --output "$external" --auto --scale 1.0x1.0 --output "$internal" --auto --same-as "$external" --scale "$scale_x"x"$scale_y"

    if [ -e /tmp/bspwm_0_0-socket ]; then
        bspc monitor -d 1 2 3 4 5 6 7 8 9 10
    fi
}
grae

The best way to use these is to bind them to a key in your sxhkdrc. Or just run them manually from the terminal.

Spoiled by Vim plugins?

Sat, 24 Oct 2020 00:00:00 +0000

Hanging out in freenode’s #neovim has taught me a couple of things about the way things work, and how they’re supposed to work.
One of these things is the native packages system which most people, myself included, are treating (or have been treating) as a plugin manager in the same vein as vim-plug and many others.

After lurking and reading, and asking around, several people there have told me that there’s some very strange gymnastics going on behind both the package system and plugin managers like vim-plug. The general consensus seems to be that while plugin managers have gotten very crafty and practical and bring much to the table, the package system continues to reinvent the wheel in very “vim-like” ways.
The fact that it loads plugins seems to be more of a side effect than a planned feature, even if people do use it for their plugin needs. Is this one of those UI vs UX type situations? Is it because, as many people say, vim is still its creator’s pet project only making sense to him?

I’m afraid I really can’t comment on either, but after some testing I have adopted a sort of hybrid solution. I keep very few “bare necessities” in Neovim’s runtimepath and load every other plugin using vim-plug.

I figure this will hold me until the time to migrate my config from init.vim to init.lua comes. Everything I keep seeing about the 0.5 nightlies leads me to believe this will be a change for the better. And if it does come out around the solstice then what better way to celebrate than by redoing the entire config! :D

FZF as Vim package

Tue, 22 Sep 2020 00:00:00 +0000

As a Neovim user, I’ve been following the development of v0.5 with great interest. Native LSP and Treesitter look like great solutions to problems users clearly have. I’ve been slowly weaning myself off of coc.nvim in preparation for when all of this hits stable.

Admittedly, coc.nvim is a great plugin/ecosystem, and works great. Unfortunately, it’s a bunch of heavy js blobs that depend on both npm and yarn, which I’ve been tolerating for the sake of coc’s features.

Speaking of features, in the past I’ve relied rather heavily on coc-lists as a fuzzy finder, and coc-explorer for those hard to reach files.

I’ve (re)replaced coc-explored with Defx and decided it was time to bring FZF back into my vim config, so off to its repo I went, to check back on the docs.

I’ve always thought the instructions to use FZF as a vim plugin were a bit unclear and, as I discovered after a lengthy chat in #neovim, they actually are. Nonetheless, I remembered using it without much hassle before.

As a vim-plug user, my proposed solution had been to add Plug /usr/bin/fzf to the relevant part of my init.vim, but in the interests of going native as much as possible, I’ve been giving the packages system a try.

The way to get native packages working is to create a couple of folders somewhere in the runtimepath and just clone plugin repos in there. Some people prefer using git submodules but I’m not entirely clear on the benefits of this over cloning.
I keep my plugins in $XDG_DATA_HOME/nvim/site/pack/bundle placing the ones I always need loaded in the start folder, and the more specific ones in the opt folder for lazy loading. The latter require adding packadd! plugin-folder-name to init.vim.

This brings us back to the topic of FZF’s docs. Having FZF installed through a system-wide package manager gets us halfway there, but the docs state we should have both the entire program and the vim plugin in our plugins directory… wat.

As it turns out, FZF proper already comes with a wrapper that enables us to use it with vim (very confusingly called fzf.vim), but all of the premade functions most of us are used to (such as :Buffers, :Files, etc), are only available through the fzf.vim plugin. While this is more or less explained somewhere in the docs, the recommended solution of managing the FZF application itself through vim (thus having it installed twice) is bullshit and nonsense and just plain WRONG.

What should be done is use find (or fd or locate or whatever) to find out where this wrapper is installed and add that location to our runtimepath.
locate fzf threw a bunch of directories at me, the most interesting one being /usr/share/vim/vimfiles which is where the wrapper is in my system. The actual path is somewhat longer but this is the part that’s of relevance.
So now it’s possible to just clone the one repo and add a line to init.vim

TL;DR

Install FZF through your system’s package manager
Clone the plugin repo to the runtimepath. For Neovim, it looks like this:

$ mkdir -p $XDG_DATA_HOME/nvim/site/pack/bundle/opt
$ cd $XDG_DATA_HOME/nvim/site/pack/bundle/opt
$ git clone https://github.com/junegunn/fzf.vim

Find the relevant file
Add line to init.vim like so:

set runtimepath+=/usr/share/vim/vimfiles/
packadd! fzf.vim
...

???
Profit!

The wrapper itself is inside a folder called plugin but if you add that to the route, then the file won’t be loaded. Go figure.

Epilogue

I couldn’t find any sign whatsoever of any of this ever being explained or talked about in either FZF repo. What little is there either doesn’t work or just reiterates that you should just install everything twice. Whatever issues have been opened have either come and gone or received answers so terse they might as well have been SteveMail¹

https://stevemail.tumblr.com/ ↩︎