lobre

Philosophy between Server-Side Decorations and Client-Side Decorations

Single identity vs split identity in application windows

There are fundamentally two different ways to think about application windows.

In the first paradigm, an application exposes a single visual identity. The frame, header, and content are all part of the same visual and conceptual entity, drawn by the application itself. This is the model Wayland is built around by default: the client renders its entire window, and there is no inherent notion of a window being split into independent parts. Importantly, this paradigm implies that an application fully owns its visual identity. If it uses the native toolkit of the desktop—such as GTK on GNOME—it will naturally follow the desktop’s design language and style guide, not just for the titlebar but for every detail of its widgets, spacing, typography, and interactions. If it uses a different toolkit, then by definition it cannot fully match those native design constraints, and it wi

lobre

The idea here was to zoom in on a very specific question: how does application state relate to the URL? Not the whole universe of state in an app, just the part where the URL has a role in carrying, pointing to, or ignoring state entirely.

When the server handles a request, it combines state from different sources: the URL, cookies, headers, and whatever state it keeps internally on its side. On the client, there can also be local UI state, but that never leaves the client unless explicitly sent. So the table is really about the URL’s role among those sources, not about state everywhere.

After thinking through the possibilities, it turns out there are only three patterns for how URLs can participate:

• The URL contains some of the state directly
  (for example filters, pagination, search parameters)
• The URL contains a token that points to state stored elsewhere on the server
  (often called “deep linking” in Datastar conversations)

lobre

Understanding Kakoune’s Command Language: Parsing, Evaluations, and Beyond

Kakoune is a modal editor. That means when you’re editing text, you’re constantly interacting with the editor using a powerful language of keystrokes — moving around, selecting text, transforming content, all through short, expressive commands typed directly in the editing interface. This is the core editing experience, and it’s what gives Kakoune its speed and fluidity.

But this isn’t the only way to interact with Kakoune.

There’s another side to Kakoune — a more structural, programmable one — which lets you interact with the editor through commands. These commands can be used to configure Kakoune, automate behavior, and define complex workflows. Commands can be written in configuration files, invoked via custom keybindings, or typed directly into the command prompt.

This document focuses on that second side: the command interface. We will explore how commands work, how they are built, and how Kakoune interprets them

lobre

Zig Type System

Zig aims to be a simple language. It is not easy to define what simple exactly means, but zig is also a low-level programming language that aims for c-compatibility. To reach this goal, it needs good semantics in its type system so that developers have a complete toolbox to manipulate data.

So types in zig are composable, but this can become rapidly overwhelming. See those examples. Are you able to understand them at a glance, as soon as you read them?

*const ?u8
?*const u8
*const [2]u8

lobre

function oni() {
    dir="$HOME"
    if [[ -n "$1" ]]; then
        dir=$(readlink -m "$1") 
    fi

    unset LD_LIBRARY_PATH
    unset LIBGL_DRIVERS_PATH

    nix-shell -p appimage-run --run "appimage-run $HOME/Downloads/Onivim2-x86_64-master.AppImage $dir"

lobre

#command
t   next-tag
T   prev-tag
j   forw-line
k   back-line
d   forw-scroll
u   back-scroll
h   left-scroll
l   right-scroll
r   repaint

lobre

# Example with go modules fetched by 
# nix and linked to the vendor directory
# when entering the shell.

with import <nixpkgs> {};

buildGoModule {
  pname = "example";
  version = "0.0.1";
  src = ./.;

lobre

{
  "workbench.colorTheme": "One Dark Pro",
  "editor.detectIndentation": true,
  "editor.fontFamily": "FiraCode-Regular.ttf",
  "editor.fontSize": 14,
  "editor.largeFileOptimizations": true,
  "editor.highlightActiveIndentGuide": true,
  "editor.indentSize": 4,
  "editor.insertSpaces": false,
  "editor.lineNumbers": "on",

lobre

#!/bin/bash

# This script takes a composer.json file as first parameter
# and will increase the minor number of the semantic version.
# e.g. From 1.3.3 to 1.4.0.

oops() {
    echo "$0:" "$@" >&2
    exit 1
}

lobre

package main

import (
	"flag"
	"fmt"

	"github.com/lobre/kits/cli"
)

func main() {