This website

A pre-rendered site. The first major version abstracted while the second abbreviated.

Old versions of this site had typical menus at the top, which would turn into drop down menus on mobile view, or as they're called, hamburger menus. A questionable older version of the biography page is still served for demonstration.

You may find the first and second version on GitHub.

<?php
/* License at the bottom */

include_once("common/wraps/typical-layouts.php");
include_once("common/wraps/external-links.php");
include_once("common/wraps/xml.php");

[...]

function get_biography_html(string $language) {

  return get_typical_layout(
    $language,

<?php
    function biography_array_to_en_gr($array) {
        global $EN, $GR; $EN($array->en); $GR($array->gr);
    }
    $b = "biography_array_to_en_gr";
?>
[...]
<?php $h = simplexml_load_file("bio-high-school.xml") ?>
<h2><?php $b($h->title) ?></h2>
<p>
    <?php $b($h->graduated) ?>
    <a href="http://2lyk-amaliad.ilei.sch.gr/wordpress17/"
    ><?php $b($h->high_school) ?></a>

At first, the site was based on abstraction layers and components that choose their identity from a buffee, then the site became client-side rendered with macros and served almost as-is, then fully progressively enhanced for Emacs' browser, then it lost its menus which got replaced with plain text. The site got a simpler design over time while preserving or enhancing various values. The final design trivialises mobile support, old browser support, accessibility, localization, theme switching and navigation. It's fascinating that it looks neither better nor worse. While it can't impress at first sight, it gives the impression that it's going to be predictable and it won't cause the user trouble.

System's hotkey system

A system to provide a listing of key bindings and optional input box to key bindings, built around sxhkd, with 4 major versions:

Version 1: alchain

3 programs, alchain, alpopup and hk-tui.bash, working together so that when pressing the Windows key a terminal appears at the bottom of the screen, full width, displays possible key bindings and waits for key input. After pressing Windows, getting the terminal, and pressing another key in the terminal such as W, often nothing would have happened yet and the terminal would be showing next possible key presses.

read -n 1 -s -r
next=$( awk "/^$REPLY/ { print \$2 }" hk-states/$state )

if [ -z $next ]
then
    next=ROOT
    bspc node last --focus
fi

The flaw was that windows are not designed to work well when treated like this. There were more than just bugs. Windows play a more decorative role than anticipated. Most of the code is lost today.

Version 2: alk

Shell scripts that take arguments corresponding to hotkeys, and perform the actions. The al executable displays the stdout and stderr in a terminal. That is, if it was called from an environment without the INTERACTIVE variable set. The shell function definitions of the alk-* executables compile into the help message which acts like a listing of key bindings. While the code is weird, it's much closer to how I write shell scripts today. Note that it's POSIX compliant instead of Bash.

if [ "$INTERACTIVE" = '' ]
then set_interactive
fi

execute_al() {
    alk-router "$@"
}
execute_al_interactive() {
    execute_al "$@"
}

Compared to the first approach, this one had very verbose configuration files. Also, it was never actually used in the terminal.

Version 3: alsnip

A code snippet generator, that can take multiple user inputs to complete parts of a snippet, and provides auto completion in the process. The snippets could be shell scripts that would run, and the completion could be started by pressing a key binding. Built in, the configuration expressed which snippets were shell scripts (to be ran), and of them, which were bound to keys, and which needed terminal interactions such as entering passwords. It was almost ready to be published, but it wasn't self-contained at all, plus I abandoned it before publishing it.

fn=powff+key+is-e-q+key-term:"$fn"
fn_powff() {
  case "$act" in
    script) printf 'sudo shutdown %s\n' "$1" ;;
    descr) cat <<EOM
systemd command,  poweroff  is an alias to  shutdown now
EOM
    ;;
    arg1) printf "recommend\nnow\n+1\n+5\n+30\n23:59\n02:00\n" ;;
  esac
}

I didn't ever use snippets, nor did I start using snippets then. So it still was a hotkey system only. It abused mr Robert C. Martin's insights too, making it one of the most complicated pieces of software I had made by then. I uploaded the project once I made this site, on GitHub.

Version 4: scmd

A single file.

volume_set_8() { pacmd set-sink-volume 0 48000; } #m8
volume_set_9() { pacmd set-sink-volume 0 54000; } #m9
volume_set_custom() { pacmd set-sink-volume 0 "$(:|dmenu)"; }

wallpaper_set_scale() { bspc_float; feh --bg-scale "$(find ~/l/gwp/ -type f -print0 | xargs -0 sxiv -ot)"; }
wallpaper_set_fill()  { bspc_float; feh --bg-fill  "$(find ~/l/gwp/ -type f -print0 | xargs -0 sxiv -ot)"; }

It acts as a command palette where the lines of code become items of a list, and it can parse itself into a hotkey configuration using the comments at the end of the lines. Every line is either blank, a comment, or an inline shell function definition.

scmd_run() { c="$(dmenu < "$(this_file)" | cut -d'(' -f1)"; test "$c" && scmd_with_bar_status "$c"; } #x
  [...]
this_file() { echo ~/.config/scmd.sh; }

This is my best product because it didn't order the computer as much as it asked the computer what it's good at, to capitalize on it. The process felt like caring about the computer, a bit like a long conversation that makes two people understand each other.

scmd_ls_keys() { sed -n 's/^\([a-z0-9_]\+\)(.*#\([^}]*\)$/\2 \1/p' "$(this_file)"; }
scmd_sxhkdrc_vim() { in_vim scmd_sxhkdrc; }
scmd_sxhkdrc() { scmd_ls_keys | awk "{ $(scmd_awk1) $(scmd_awk2) }"; }
scmd_awk1() { printf %s 's = $1; gsub(/./, "; super + &", s); sub("; ", "", s); '; }
scmd_awk2() { printf %s 'print(s); printf("\t. %s && scmd_with_bar_status %s\n\n", "'"$(this_file)"'", $2);'; }