hpfr

WebDAV support is nice to save money, but from a privacy perspective it’s a huge bummer that the sync servers get all your citation metadata. A better self-hosting story¹ is one path to resolving this. End-to-end encryption² similar to e.g. Firefox Sync is another. Zotero has a security overview³ that shows they clearly care about good practices, but it’s still bothersome to have to trust the server when many other applications have proven E2EE works great even for non-technical users⁴.

Unfortunately from the main Zotero dev’s responses, it seems clear that they have no incentive to implement either and probably never will (look, the same comment from 2½ [now 4!] years ago⁵) without some shift in circumstances (massive increase in funding, new regulatory requirements). Even if a community member implemented the entirety of either solution, dstillman can just (rightly, tbh) claim it will increase their maintenance burden when they are trying to support paying customers.

Unfortunately from the main Zotero dev’s responses, it seems clear that they have no incentive to implement either and probably never will (look, the same comment from 2½ years ago⁵) without some shift in circumstances (massive increase in funding, new regulatory requirements). Even if a community member implemented the entirety of either solution, dstillman can just (rightly, tbh) claim it will increase their maintenance burden when they are trying to support paying customers.

> I literally did not know info pages existed for the first 15 years I used GNU tools, and I've still never used one

A bit of irony: the link and screenshot in the OP are from the HTML version of an Info manual! In my book, that counts as using one :). HTML Info manuals are right up there with Stack Overflow for most queries about GNU tools. Most people who have searched the web for how to do something with Make, GCC, or tar have used an Info manual, unwittingly or otherwise. There are even two types of HTML export¹: one web page per node, good for sharing links, and everything on one page, good for lazy full-text search.

And while the TUI program is indeed pretty niche these days (probably partly due to the fact that it’s not installed by default in many environments), any Emacs user worth their salt is intimately familiar with Info-mode :D

Prompt will probably be my next terminal emulator. That inspector looks interesting. Have you seen Ghostty’s recent demo²?

Well, anything stored by git-annex has read-only file permissions. Apps will follow the symlink, yes, but they will fail to write to the location if they try.

> The way the "check out" feature works is also weird, causing a change in the shared version history.

Unlocking a file changes it from a symlink to a git-annex pointer file from git’s perspective (git-annex accomplishes this via git’s smudge filter interface), but you don’t have to commit the unlock. You can unlock, modify locally, re-lock, and commit the new changed version in one go. It’s nice that you can commit the unlocking action itself if you want a file to be unlocked in all clones of the repository. You can choose whether to commit the unlock depending on if it fits your use case.

    git annex config --set annex.largefiles 'largerthan=1kb and not (mimeencoding=us-ascii or mimeencoding=utf-8)'