So last year, I removed comments from my site entirely.

This worked fine, and I didn't really think about it much, until somebody reached out to me via email recently, with what was essentially a comment on a blog post, and I realized that nobody else but me was going to benefit from it.

So I started thinking about how to go about adding comments again.

Build it?

I started, of course, by building.

I modeled what was essential to a comment; decided I'd use Markdown, with limits, to allow commenters some ability to style and format their comments; even got a schema setup in my database.

And then I realized a few things:

• I'd need an admin for moderating comments.
• I'd likely need some way to notify at least myself when a new comment was added.
• What about letting folks know their comment was submitted successfully? Or that it was published? (I planned to moderate all comments by default.)
• What about letting folks know when a new comment was published on a post they'd previously commented on?
• What about allowing folks to unsubscribe from those notifications? And would I allow both granular (per blog post) and general (full site) unsubscription?
• What about allowing folks to request all comments be deleted (per GDPR)?
• What if I want to lock comments for a post? Or later unlock them?

The more I thought about it, the more work I was seeing, and I wasn't sure how much I wanted to develop it.

Research

So I started researching commenting systems, and quickly found a variety of generic solutions exist, thankfully. The research then boiled down to identifying which ones are actively maintained (because anything like a commenting system will likely need security updates and occasional updates to ensure compatibility with browsers and evolving security policies), which ones had the features I wanted, and how easily I'd be able to implement the solution.

I eventually settled on Remark42.

Remark42 is privacy-focused, and allows me to keep all the data. While there are a number of SSO integrations, they primarily use OAuth2, meaning that the integration is only for purposes of authentication. I was also able to enable an email authentication option; this sends an email to the user with a token that they then paste back into the form to authenticate.

As for the email, I was able to set it up to use an existing SMTP user to send out emails. These are used for users who authenticate via email, sending notifications to me of new comments, and managing individual user notifications of comments.

I run it under its own domain (comments.mwop.net), and have functionality to embed comments via JavaScript in my site. I was able to configure it such that it will only accept comments from specific domains, which helps prevent abuse of the system. While I'd love to have the comments integrated on my site without JavaScript, the fact that I did not need to develop any of this on my own was a huge benefit.

Better: it uses limited Markdown for comment styling, and has built-in links to documentation on what you can use.

Configuring Remark42

I run the service using Docker Compose, using a single service in my Compose file:

services:
  remark42:
    image: umputun/remark42:latest
    container_name: "remark42"
    hostname: "comments.mwop.net"
    restart: always

    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"

    ports:
      - "127.0.0.1:9010:8080"

    env_file:
      - .env
    volumes:
      - ./var:/srv/var
      - ./templates/email_confirmation_login.html.tmpl:/srv/email_confirmation_login.html.tmpl:ro
      - ./templates/email_confirmation_subscription.html.tmpl:/srv/email_confirmation_subscription.html.tmpl:ro
      - ./templates/email_reply.html.tmpl:/srv/email_reply.html.tmpl:ro
      - ./templates/email_unsubscribe.html.tmpl:/srv/email_unsubscribe.html.tmpl:ro
      - ./templates/error_response.html.tmpl:/srv/error_response.html.tmpl:ro

A few remarks here:

• I found that the "hostname" field needs to match the host that the service will answer to publicly. This was not documented, but until I made that change, it was inaccessible.
• The service runs on port 8080 internally. I mapped that to a port on my localhost, which I then reverse proxy to via Caddy (more on that below).
• There are a number of templates for the emails. I grabbed these from the Remark42 git repository and (minimally) customized them.

Configuration of Remark42 when run via Docker is done via environment variables. I configured mine to allow email authentication, as well as OAuth2 via GitHub (as a large number of my readers have GitHub accounts). (You can also configure Google, Facebook, Apple, Microsoft, Patreon, Discord, Telegram, and Yandex.)

These were the values I configured; the full list of configuration values is in the documentation:

# This is the actual URL to the Remark42 instance
REMARK_URL=

# This is an identifier used to allow the instance to handle multiple sites.
# It can be a single value, or multiple, comma-separated values
SITE=

# A shared secret key for signing JWTs
SECRET=

# Whether or not to log debug messages
DEBUG=false

# A comma-separated list of hosts that are allowed to interact with the service
ALLOWED_HOSTS=

# The "Same-Site" cookie policy to use.
# I discovered through trial and error it needed to be "none"
AUTH_SAME_SITE=none

# GITHUB config
# If you use GitHub for OAuth2, these are the client ID and secret, respectively
AUTH_GITHUB_CID=
AUTH_GITHUB_CSEC=

# EMAIL SERVER CONNECTION
SMTP_HOST=
SMTP_PORT=465
SMTP_TLS=true
SMTP_INSECURE_SKIP_VERIFY=false
SMTP_USERNAME=
SMTP_PASSWORD=

# USER NOTIFICATION
NOTIFY_USERS=email
# The "From" address when sending email notifications
NOTIFY_EMAIL_FROM=
# The email subject line for email verifications
NOTIFY_EMAIL_VERIFICATION_SUBJ="mwop.net comments email verification"

# ADMIN NOTIFICATIONS
NOTIFY_ADMINS=email
# The "From" address for admin notifications
NOTIFY_EMAIL_FROM=
# A single email or comma-separated list of emails to which to send admin
# notifications
ADMIN_SHARED_EMAIL=
# User identifiers for admin users, to enable admin features for those users
ADMIN_SHARED_ID=

# Enable email authentication
AUTH_EMAIL_ENABLE=true
# The "From" address when sending email verifications
AUTH_EMAIL_FROM=
# The email subject line when sending email confirmation
AUTH_EMAIL_SUBJ="mwop.net confirmation"

# MISC
EMOJI=true

The ADMIN_SHARED_ID value must be setup AFTER you've authenticated a user in the system. You can click on a user from any comment thread, which opens a sidebar. At the top of the sidebar is the user display name, as well as their identifier, and you will copy this identifier to put in the ADMIN_SHARED_ID field. When you do so, you'll need to restart the container.

Serving it with Caddy

The Remark42 docs detail a number of different reverse proxy setups for serving it, including Caddy... but, interestingly, only show Caddy configuration for serving it from a sub-path of an existing site.

My Caddy configuration for this was very minimal:

comments.mwop.net {
    reverse_proxy localhost:9010 {
        header_up X-Real-IP {remote}
        header_down Strict-Transport-Security max-age=3153600
    }
    header {
        Strict-Transport-Security max-age=3153600;
    }
}

Integrating with the application

Once I had setup the server, I needed to integrate it in my application, and this is where things got tricky. Why? Because of some choices I've made along the way while developing my site:

• I have a pretty robust Content Security Policy, and needed to configure it to allow (a) pulling the JS for Remark42 from my comments host, and (b) allow it to display frames from it.
• I use HTMX, and have enabled hx-boost, which means I need to (a) load the Remark42 JS on every page, and (b) have some functionality for re-initializing it when a user navigates to a new page. Further, I use Webpack to concatenate and minimize my JS, which means I'd need to ensure that this integration is done in a way that will work correctly.

Content Security Policy

The values used in ALLOW_HOSTS are used to populate a frame-ancestors Content Security Policy header by the Remark42 server.

This is important.

If you are defining a Content Security Policy on your application, you'll need to ensure that you have a frame-src setting that allows your Remark42 server. This is in addition to allowing it as a script-src:

Content-Security-Policy: script-src https://comments.mwop.net; frame-src https://comments.mwop.net

I use paragonie/csp-builder, and you can set these via the following:

<?php
use ParagonIE\CSPBuilder\CSPBuilder;

$csp = new CSPBuilder([
    'frame-src' => [
        'allow' => [
            'https://comments.mwop.net',
        ],
    ],
    'script-src' => [
        'allow' => [
            'https://comments.mwop.net',
        ],
    ],
])

(I clearly have more in it than these values; this is to illustrate the pieces necessary to integrate Remark42.)

HTMX Integration

To start, I added the following tag to the <head> element of my layout:

<script defer src="https://comments.mwop.net/web/embed.js"></script>

This ensures that the first page a user comes to on my site loads the JS, but that it's done in the background.

Next, I needed to make a change to my site JavaScript.

I use Webpack, and have the following in my site JS, among other things:

window.htmx = require("htmx.org");

I discovered through trial and error that you MUST define a remark_config variable at the global (window) level of your JS; otherwise, regardless of how you try and create a Remark42 instance, it will fail.

Additionally, I was going to need to (a) register a listener on the REMARK42::ready event so it would initialize on an initial page load, and (b) register a listener on the htmx:load event so that it would re-initialize after a page swap occurs.

The end result looks like this:

const remark_config = {
    host: "USE SAME VALUE AS 'REMARK_URL' CONFIG HERE",
    site_id: "USE A VALUE FROM 'SITE' CONFIG HERE",
    theme: "dark", // can be light, dark, or system
    no_footer: true, // I didn't want to include the "powered by" footer
};

let remark42Instance = null;

const initComments = function() {
    if (window.REMARK42) {
        if (remark42Instance) {
            remark42Instance.destroy();
        }

        node = document.getElementById('remark42');

        if (node === null) {
            return;
        }

        remark42Instance = window.REMARK42.createInstance({
            node: node,
            ...remark_config,
        });
    }
};

window.remark_config         = remark_config;
window.htmx                  = require("htmx.org");
window.addEventListener('REMARK42::ready', () => {
    initComments();
});
window.htmx.on("htmx:load", () => {
    initComments();
});

The initComments() function checks to see if a global REMARK42 object exists; this is registered by the Remark42 JS when it loads, so if it doesn't exist, it means the JS hasn't been loaded on the page yet. From there, it checks to see if the remark42Instance variable is non-null, and, if so, calls its destroy() method. Next, it checks to see if a DOM element with the ID remark42 is present; if so, it creates a new Remark42 instance, passing that node and the previously defined Remark42 configuration.

When the Remark42 JS emits the REMARK42::ready event, or HTMX emits the htmx:load event, I trigger the function. This ensures it's triggered on an initial page load, and on any subsequent DOM load event triggered by HTMX.

Adding comments to a page

Now, to add comments to a page, I only need to add the following:

<div id="remark42"></div>

And I can use any tag I want here, just so long as the ID is set.

Final thoughts

I'm fairly happy with this solution.

I didn't have to build it all myself, I keep ownership of the data instead of handing it to a third-party, my users get reasonable privacy (including the right to request deletion of all their comments), and I get tools to moderate and manage comments.

I'd love it if I didn't have to use JS for this, and could theme the comments myself. That said, Remark42 has an API, so technically I could build some site integration that delegates to it behind the scenes if I really want to. As it is, the "dark" theme integrates reasonably well with my existing site styles, so there's no immediate need for me to do this currently.

Let me know what you think... comments are on, after all!

Comments are Back was originally published 25 January 2025 on https://mwop.net by Matthew Weier O'Phinney.

Today, I updated my work machine, and didn't even notice that there were new pamu2fcfg and libpam-u2f packages, updating to version 1.3.1; I never really care, as everything just works. But when I came back to my machine after lunch, I was unable to login: I'd provide my password, but my Yubikey wouldn't activate.

I tested it on my personal machine, and everything was working fine. I tried pressing the key on my work machine, when in the password field, and it pasted in the OTP code, so clearly there's no USB issue.

So, after booting my rescue USB drive and disabling the U2F support, I (a) discovered that I'd had updates for the PAM U2F support earlier, and (b) searched for the phrase "yubikey pam u2f 1.3.1 breaks", which took me to this report.

The gist?

Due to a CVE, the PAM U2F bindings now require that the u2f_keys file is writeable only by the owner.

This can be accomplished pretty easily:

# If you have systemwide keys:
sudo chmod g-w,o-w /etc/yubico/u2f_keys
# If you have per-user keys:
chmod g-w,o-w $HOME/.config/Yubico/u2f_keys

Once I did that, I re-enabled my PAM U2F bindings, rebooted, and all worked fine again.

Final thoughts

I rarely think about permissions in my $HOME/.config directory, but I'm well aware that configuration for things like SSH and GPG require similar permissions masks. I think it's great that Yubico is doing this, but (a) it should have likely been like this all along, and (b) they really should have provided some sort of tooling or messaging with the update to help folks fix permissions issues before they become a problem. The fact that I only found out when I was unable to login to my machine was horrible, and I feel incredibly fortunate and privileged that I (a) had a rescue USB drive handy, and (b) the knowledge of what I needed to do to disable U2F so I could access my machine. Not all their users will be in that position.

Fixing issues with Yubico's PAM U2F bindings in version 1.3.1 was originally published 15 January 2025 on https://mwop.net by Matthew Weier O'Phinney.

For these, I generally keep a page in Logseq for the given week, named something like "2024w50", and I've been adding that into my "Favorites" list (and taking out the previous week's page!) so that it's easy to navigate to. I also keep my weekly notes here; I have to do weekly reports for each brand, so having a dedicated location I can either tag in other notes or write them in directly is useful.

While it's easy to open this page into a sidebar, I generally do not want a sidebar open, as I find it distracting. So I've been mulling over alternatives that would allow me to continue seeing my priorities easily, while giving me the same ability to group them by week.

My solution

The solution ended up being quite simple.

I'm now creating a structure like the following on that weekly page:

## Priorities
priorities:: 20241220

- First item in the list
- Second item in the list
- and so on

In my Logseq config.edn, I've added the following into my :default-queries { :journals: } section:

#+BEGIN_QUERY
{
  :title "PRIORITIES"
  :inputs [:today :+1w]
  :query [
    :find (pull ?b [*])
    :in $ ?start ?end
    :where
      [?b :block/properties ?properties]
      [(get ?properties :priorities) ?priorities]
      [(>= ?priorities ?start)]
      [(< ?priorities ?end)]
  ]
}
#+END_QUERY

This adds a block named "PRIORITIES" to the current journal, pulling all blocks marked with the tag "priorities" where the date is today or no more than a week in the future. Since I do my planning only a week in advance, this ensures I typically only see one such block on any given day, and ensures it's in front of me each day as I start the journal. On Friday, I see the current week's and the next week's priorities, allowing me to see what slipped through the cracks as I plan, as well as get a handle on what I want to accomplish next week.

A Weekly Priority List in Logseq Journal View was originally published 17 December 2024 on https://mwop.net by Matthew Weier O'Phinney.

• What's New in PHP 8.4: Features, Changes, and Deprecations
• A Guide to PHP 8.4 Property Hooks
• Asymmetric Visibility in PHP 8.4: What It Means for PHP Teams
• HTTP Verbs Changes in PHP 8.4

Roundup of PHP 8.4 Posts was originally published 4 December 2024 on https://mwop.net by Matthew Weier O'Phinney.

If you want to know how I got to that point, read on.

I've been using Vivaldi the past nine months or so.

I'd used it once before, but had to abandon it due to issues I was having with sites and applications I use for work, but tried it again earlier this year, and found it (a) worked everywhere I needed it, (b) performed better than any other browser I'd used, and (c) had features I'd never seen in other browsers that were hugely useful. (The quick search feature and workspaces are amazing, if you've not tried them! And tab tiling has allowed me to compare information or fill out forms in far easier ways.)

I also love having tabs in a sidebar instead of at the top.

Vivaldi actually allows you to choose any side of the screen for displaying tabs, and displaying them on the left or right stacks them vertically in a sidebar.

When you get a dozen or more tabs open, the side-scrolling, top tab bar becomes quickly untenable, as the tabs shrink and the useful information contained in their titles disappears. Sure, I could perform better "tab hygiene", but sometimes when you're in the middle of a project, that's not an option. Having them listed vertically in a sidebar means they are a consistent size, and easy to locate.

There's one problem, though: they take up screen real estate.

Most of the time, I don't actually need to see them; I only need to see them if I'm trying to switch to a specific tab.

For a while, I used a solution that utilized an experimental feature of the Vivaldi browser: CSS modifications. This feature allows you to define a stylesheet that interacts with the browser chrome. Coupled with a tool that allows you to inspect the application's DOM itself, you can do a lot, and I found a mod that:

• Auto-hides the tab bar so that only the favicons show
• Expands it when you mouse over the tab bar

This was pretty magical.

However, I noticed that if the load on my machine were high, or there was a tab using a lot of resources, it could get pretty laggy. Additionally, it meant that any time my cursor moved over that area, it would expand — which might not be what I wanted if, for instance, I was just moving my cursor between windows on the screen.

But worse: it hid the workspaces feature, which I've started to use to, well, do better tab hygiene. Workspaces allow me to group related tabs, and then I can switch between workspaces within a window. This keeps resource usage lower, and helps me focus better.

But by hiding the tooling, I had to go through a lot of hoops to use it, and I found I was avoiding the feature.

So I recently started looking to see if Vivaldi had added any features to enable tab bar hiding natively, without a mod, and discovered that it's basically existed all along; it just requires a click.

Specifically, a middle-click, on the separator between the sidebar and the web page.

Middle clicking on this separator will either collapse or expand the sidebar; when collapsed, it shows just the tab favicons, and the workspace selector icon.

While I'd love to see a keyboard shortcut for this, or even a native auto-hide/expand feature, this is still an easy workflow to adopt, and has been more predictable in usage.

Collapsing the Vivaldi Tab Sidebar was originally published 25 October 2024 on https://mwop.net by Matthew Weier O'Phinney.

I tried a number of options, but was eventually pointed to resurrect.wezterm.

In this post, I'll detail how I've configured it, as well as a workflow I've developed for interacting with it that gives me (a) reasonable satisfaction that I won't lose work, and (b) additional flexibility for branching off work.

A note on sharing sessions

What this solution does not do is allow me to share a Wezterm session, or open it simultaneously in another wezterm session. For that, you need a Unix muxer session, and resurrect.wezterm does not play well with it. As such, you will need to do any such sessions without wezterm.resurrect.

Configuration

I've been finding it's most maintainable to throw my configuration for specific plugins or features into their own modules whenever possible. As such, I started by creating a resurrect/config.lua file that would do the following:

• Setup encryption for the saved state files
• Setup periodic saving, so I don't have to remember to save or worry about what happens if there's a crash before I save.
• Setup the maximum number of lines per pane to save.
• Return the default keybinding I want to use with the module.

That file ends up looking like the following:

-- File: resurrect/config.lua
-- resurrect.wezterm configuration and settings
--
-- This module:
-- * Configures the resurrect.wezterm plugin
-- * Configures event listener configuration (via an additional required file)
-- * Returns wezterm keybinding configuration for resurrect-related actions.
--
-- The main wezterm configuration is then responsible for merging the
-- keybindings with other keybindings, or setting up its own.

local config    = {}
local wezterm   = require 'wezterm'
local resurrect = wezterm.plugin.require("https://github.com/MLFlexer/resurrect.wezterm")

-- resurrect.wezterm encryption
-- Uncomment the following to use encryption.
-- If you do, ensure you have the age tool installed, you have created an
-- encryption key at ~/.config/age/wezterm-resurrect.txt, and that you supply
-- the associated public_key below
resurrect.set_encryption({
    enable      = true,
    method      = "age",
    private_key = wezterm.home_dir .. "/.config/age/wezterm-resurrect.txt",
    public_key  = "THE-PUBLIC-KEY-VALUE-GOES-HERE",
})

-- resurrect.wezterm periodic save every 5 minutes
resurrect.periodic_save({
    interval_seconds = 300,
    save_tabs = true,
    save_windows = true,
    save_workspaces = true,
})

-- Save only 5000 lines per pane
resurrect.set_max_nlines(5000)

-- Default keybindings
-- These will need to be merged with the main wezterm keys.
config.keys = {
    {
        -- Save current and window state
        -- See https://github.com/MLFlexer/resurrect.wezterm for options around
        -- saving workspace and window state separately
        key = 'S',
        mods = 'LEADER|SHIFT',
        action = wezterm.action_callback(function(win, pane) -- luacheck: ignore 212
            local state = resurrect.workspace_state.get_workspace_state()
            resurrect.save_state(state)
            resurrect.window_state.save_window_action()
        end),
    },
    {
        -- Load workspace or window state, using a fuzzy finder
        key = 'L',
        mods = 'LEADER|SHIFT',
        action = wezterm.action_callback(function(win, pane)
            resurrect.fuzzy_load(win, pane, function(id, label) -- luacheck: ignore 212
                local type = string.match(id, "^([^/]+)") -- match before '/'
                id         = string.match(id, "([^/]+)$") -- match after '/'
                id         = string.match(id, "(.+)%..+$") -- remove file extension

                local opts = {
                    window          = win:mux_window(),
                    relative        = true,
                    restore_text    = true,
                    on_pane_restore = resurrect.tab_state.default_on_pane_restore,
                }

                if type == "workspace" then
                    local state = resurrect.load_state(id, "workspace")
                    resurrect.workspace_state.restore_workspace(state, opts)
                elseif type == "window" then
                    local state = resurrect.load_state(id, "window")
                    -- opts.tab = win:active_tab()
                    resurrect.window_state.restore_window(pane:window(), state, opts)
                elseif type == "tab" then
                    local state = resurrect.load_state(id, "tab")
                    resurrect.tab_state.restore_tab(pane:tab(), state, opts)
                end
            end)
        end),
    },
    {
        -- Delete a saved session using a fuzzy finder
        key = 'd',
        mods = 'LEADER|SHIFT',
        action = wezterm.action_callback(function(win, pane)
            resurrect.fuzzy_load(
                win,
                pane,
                function(id)
                    resurrect.delete_state(id)
                end,
                {
                    title             = 'Delete State',
                    description       = 'Select session to delete and press Enter = accept, Esc = cancel, / = filter',
                    fuzzy_description = 'Search session to delete: ',
                    is_fuzzy          = true,
                }
            )
        end),
    }
}

require 'resurrect/events'

return config

I've setup keybindings that mimic what I had in tmux:

• Leader-S will save the current workspace session
• Leader-L will give me a way to select a workspace session to load
• Leader-D will give me a way to select a workspace session to delete

(I map Leader to Ctrl-a, which is a common convention in both screen and tmux, so I don't lose any muscle memory here.)

In my main wezterm.lua file, I then make use of my merge.all function to merge the returned keybindings configuration:

local resurrect = require 'resurrect/config'
config.keys = merge.all(config.keys, resurrect.keys)

But what is that require 'resurrect/events' line for?

Listening to resurrect events

When I save a session manually or load a session, I'd like some notification that the operation was successful. resurrect.wezterm emits a number of events for different workflow states, and you can tie into those. I did exactly that, and had my handlers use my notify.send module to emit the notifications:

-- File: resurrect/events.lua
-- resurrect.wezterm event listener configuration
--
-- This module configures event listeners for the resurrect.wezterm plugin.

local wezterm               = require 'wezterm'
local notify                = require '../notify'
local suppress_notification = false

wezterm.on('resurrect.error', function (error)
    notify.send("Wezterm - ERROR", error, 'critical')
end)

wezterm.on('resurrect.periodic_save', function ()
    suppress_notification = true
end)

wezterm.on('resurrect.save_state.finished', function (session_path)
    local is_workspace_save = session_path:find("state/workspace")

    if is_workspace_save == nil then
        return
    end

    if suppress_notification then
        suppress_notification = false
        return
    end

    local path = session_path:match(".+/([^+]+)$")
    local name = path:match("^(.+)%.json$")
    notify.send("Wezterm - Save workspace", 'Saved workspace ' .. name .. "\n\n" .. session_path)
end)

wezterm.on('resurrect.load_state.finished', function(name, type)
    local msg  = 'Completed loading ' .. type .. ' state: ' .. name
    notify.send("Wezterm - Restore session", msg)
end)

If you follow the write-up in the resurrect.wezterm README file, you'll note that my approach is a bit different, particularly when it comes to tracking a periodic save. Why? Well, when a periodic save happens, it saves the window, the workspace, and all tabs, but each of those triggers separately, and each triggers a resurrect.save_state.finished event on completion. As a result, the periodic_save state often gets reset by one of these events, which causes another event to flow through. The upshot is that if I followed the documented example, I was still seeing notifications each time periodic_save would trigger. Since I'm really only concerned about workspace save events, I've modified the logic to only trigger if it's a workspace save, which I can identify by searching for the string "state/workspace" in the session filename passed to the callback. (It's not perfect, but it's good enough for my needs.)

From there, I can do the normal logic around identifying if I'm within a periodic_save event.

I've also done some logic so I can see the name of the session at a glance, as well as see the full path to the file (for debugging purposes).

One final thing to note is my handling of the resurrect.error event. I use the "critical" urgency flag to my notify.send functionality here so that the notification requires manual dismissal. Doing this ensures I do not miss these errors!

Day to day usage

The periodic_save settings mean that as I'm working, Wezterm is periodically saving my open sessions, meaning I never have to lose my place. But how do I restore?

The interesting thing about resurrect.wezterm is that when you load a session, it does not change the current workspace name. This means that if you start in the "default" workspace, and then load your "project" workspace, you're still in the "default" workspace, and that's where periodic_save will save the workspace contents.

This may sound bad, but I've found in practice that it's actually a huge benefit. It allows me to "fork" my workspace state. I can name the workspace something different, and its state will diverge... which allows me to go back to the original state if I want to later.

So, my workflow has become:

• Change the name of the current workspace workspace to what I want it to be saved as eventually; this may be the name of a previously saved session!
• If I want to start from a previous saved session, load the saved workspace.
• Manually save only when I am planning to close a terminal window or reboot, but otherwise have periodic_save handle saving state.

I find this to be an improvement over tmux-resurrect!

Final thoughts

I've tried a few different approaches to saving sessions since adopting Wezterm, but this is the one that has finally given me all the features — and then some! — that I had in tmux-resurrect. While being able to load and mirror an existing session would sometimes be useful, it's a niche feature for me; I never do XP-style programming anymore, and I rarely find myself in a position where I want or need to load a current session into another window. However, I've often wished I could go back in time to a previous state, and this set of tools gives me that.

Using resurrect.wezterm to manage Wezterm session state was originally published 21 October 2024 on https://mwop.net by Matthew Weier O'Phinney.

Keybindings are stored as a list of tables (what we call associative arrays in PHP). Simple, right?

Unlike in other languages I use, Lua doesn't have a built-in way to merge lists.

So, I wrote up a re-usable function.

First, the file:

-- File: merge.lua
-- Provide generalized functionality for merging tables

local merge = {}

function merge.all(base, overrides)
    local ret    = base or {}
    local second = overrides or {}
    for _, v in pairs(second) do table.insert(ret, v) end
    return ret
end

return merge

Then in my main wezterm.lua, I import it:

local merge = require 'merge'

My keybindings are in config.keys, which is initialized as a list:

config.keys = {}

Another module might return configuration, and I can merge the keybindings it provides with what I have already defined:

config.keys = merge.all(config.keys, smart_splits.keys)

It's a simple piece of functionality, but it helps me keep things organized and modular.

Managing Wezterm Keybindings, or Merging with Lua was originally published 21 October 2024 on https://mwop.net by Matthew Weier O'Phinney.

However, on Linux, it's a far from ideal tool, at least under gnome-shell. (I don't know how it does on KDE or other desktop environments.) It raises the notification, but the notification never times out, even if you provide a timeout value (fourth argument to the function). This means that you have to manually dismiss the notification, which can be annoying, particularly if the notifications happen regularly.

So, I worked up my own utility.

notify.send

Since Wezterm uses Lua for configuration, configuration actually also acts as an extension mechanism. The primary wezterm Lua module itself provides a run_child_process function for spawning a system process, which allows me to call on the system notify-send utility.

As such, I wrote up the following Lua module:

# File: notify.lua
local wezterm = require 'wezterm'
local module  = {}

local function has_value (tab, val)
    for index, value in ipairs(tab) do -- luacheck: ignore 213
        if value == val then
            return true
        end
    end

    return false
end

local function notify (subject, msg, urgency)
    local allowed_urgency = { 'low', 'normal', 'critical' }
    urgency = urgency or 'normal'
    if not has_value(allowed_urgency, urgency) then
        urgency = 'normal'
    end

    wezterm.run_child_process {
        'notify-send',
        '-i',
        'org.wezfurlong.wezterm',
        '-a',
        'wezterm',
        '-u',
        urgency,
        subject,
        msg
    }
end

module.send = notify

return module

Within other configuration, when I want to send GUI notifications, I can do the following:

local notify = require './notify'

notify.send('Subject Line', 'This is the full message', 'low')

Some notes on usage:

• The urgency argument is one of 'low', 'normal', or 'critical', and defaults to 'normal'. These correspond to the same --urgency option of notify-send, with the following behavior:
  • 'low' urgency messages are collected in the notification panel, but not displayed.
  • 'normal' urgency messages display until the system timeout for notifications is met. (For me, that's 3 seconds.) After that, it disappears into the notification panel.
  • 'critical' urgency messages require manual dismissal.
• The subject argument is used for the notification subject; it's what you see without expanding the notification.
• The msg argument is the full detail you want in the notification, and is shown when you expand the notification.

notify-send has a variety of other flags which can control things like timeout, whether or not the message is transient (i.e., will never be displayed in the notification panel), application category, etc. I've found for myself that just these three items are sufficient for probably 99% of any uses cases I'll need.

Wezterm GUI Notifications was originally published 21 October 2024 on https://mwop.net by Matthew Weier O'Phinney.

It turns out that Shift-Esc will open a task manager, and you can sort on any of:

• Task (a string representing high level things like the browser as a whole, GPU process, worker tabs, and more)
• Memory footprint
• CPU (this was what I was interested in!)
• Network usage
• Process ID

You can select any task to end its process.

I was able to quickly track down the issue to a background worker running for a PWA window I'd closed earlier, and ended the process.

Diagnosing Vivaldi resource usage was originally published 10 October 2024 on https://mwop.net by Matthew Weier O'Phinney.