On <2026-09-14 Mon> I saw tp-grep function in the Biff note and grepping it found it was defined in Trip Planner project.
This reminds me on eev.el package which has these many custom functions and helpers for them. I'm using lozenge.el for these purposes, but Lozenge is monolithic - to design flexible high-level functions with high reuse.
eev utility functions are local, cheap and throw-away. Maybe I should try eev one more time.
I started posting Reddit galleries on this website, created using my reddigg-images-to-html.el package.
Here are some:
I will keep the list up to date on the home page.
I stopped publishing notes regularly, and this led to some features stopped working.
Namely, I stopped making every note its own node in my Vulpea notes corpus, and switched to custom property on heading (TEXTPOD_ID). But that broke search for linked terms, when I reference existing Vulpea node, like this - "the flow".
Something to fix, later. May be.
There I found built-in timeclock package. Simplified version of Org time tracking.
Built-in Emacs package for time tracking.
Maybe I should try it to stay in "the flow"?
(use-package timeclock :ensure nil
:config
(display-time-mode +1)
(timeclock-mode-line-display +1)
(display-time-mode -1))
Peter Seibel, Practical Common Lisp, footnote 3, page 3:
"Psychologists have identified a state of mind called flow in which we’re capable of incredible concentration and productivity. The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter. DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss. Less frequently considered but probably just as important to programmers are the interruptions caused by our tools. Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow."
Take: Emacs is not a text editor, it's an extensible interface to work with computer. That old joke about Emacs being an operating system is about that. Well, and it comes with great text editor.
Example. Why using terminal when you can run a shell command from Emacs? async-shell-command, start-process, make-process and likes (e.g. ghostel-shell-command was trivial to implement).
In the core of that is several orthogonal concepts that blend together: buffer, point, region, keymap, completion. Plus Elisp programming language, being simple but stood the test of time, being Lisp 2 (separate namespaces for variables and functions), and having flat namespace make it easy to learn and adopt to your needs. Elisp-oriented Emacs concepts: packages, hooks, advices.
╭─ buffer ── point ── region
│ ╭─ C-c ── context
├─ keymap ── prefixes ┼─ C-x ── always
╭─ concepts ┤ ├─ C-h ── help
│ │ ╰─ M-g ── "go"
│ ╰─ completion ┬─ minibuffer ── completing-read
│ ╰─ completion-at-point ── capf
│ ╭─ Lisp-2 ┬─ variables namespace
│ │ ╰─ functions namespace
│ ├─ flat namespace
│ ├─ macro
│ ├─ function
├─ Elisp ┤ ╭─ list
│ │ ├─ alist
│ │ ╭─ collections ┼─ plist
│ ╰─ variable ┤ ├─ hash-map
│ │ ╰─ cons cell
« Emacs » ┤ ├─ defconst
│ ╰─ defvar
│ ╭─ :init
│ ╭─ use-package ┼─ :config
│ ╭─ packages ┤ ├─ :custom
├─ Emacs-Elisp ┤ │ ╰─ :bind
│ │ ├─ package.el
│ │ ╰─ autoload ── user-lisp-directory ── Emacs 31
│ ├─ hooks
│ ╰─ advices
│ ╭─ mailing list
│ ╭─ emacs-devel ┴─ maintainers communicate there ┬─ Sean Whitton
│ │ ╰─ Eli Zaretski
│ ├─ reddit ── users ┬─ r/emacs
╰─ people ┤ ╰─ r/orgmode
│ ╭─ Prot
╰─ personalies ┼─ Sasha Chua
├─ Mike Zamansky
╰─ u/minad ── u/oanolin ── abo-abo ── alphapapa
On <2026-08-23 Sun> I read in stumbled on this post - Anthropic: Please Have Daisy the CC Engineer Do a Video! : r/ClaudeAI.
In this week's newsletter, Anthropic included this:
"My daily driver currently looks like: two lead agents that keep each other accountable and restart the other if either fails. These delegate to tech lead or PM agents for the 8-10 projects I'm running at any one time, and each project has 5-10 IC [individual contributor] agents, generalists or specialists depending on the problem. Across all of these I'm still only doing 30-50 prompts per day, and my IC agents typically work autonomously for 2-3 days. About 60% of my interaction is with the leads, 35% with a project lead, and 5% is when something has gone off the rails. All of these agents communicate directly with the SendMessage tool."
– Daisy, Engineer on Claude Code
Turning it into mindmap:
╭─ keep each other accountable
╭─ two lead agents ┼─ restart the other if either fails
│ ╰─ delegate to ┬─ tech lead ── 8-10 projects...
│ ╰─ PM agents
│ ╭─ . ┬─ generalists
« Daisy workflow » ┼─ 8-10 projects ── per project ── 5-10 IC agents ┤ ╰─ specialists
│ ╰─ work autonomously ── for 2-3 days
│ ╭─ 60% with leads
├─ 30-50 prompts per day ┼─ 35% with project lead
│ ╰─ 5% off rails
╰─ agents communicate ── SendMessage tool
My thoughts:
Why two lead agents? Likely they both run "/loop 30m check projects" with offset, so one is checking status while another is ready for communication. This is where "60% with leads" coming from; sometimes they both are checking, and Daisy goes to project leads directly. Those two leads have permanent session names and never closing.
8-10 projects. I also have about the same number of big topics a week, often carried to other weeks. So this sounds like the right amount of parallelism. Also keeping 8-10 projects on track is within cognitive abilities of an average human.
Comments lead to this video:
It breaks down to this mindmap:
╭─ Slack
╭─ where work comes from ┼─ CI/CD ── no point to fix CI/CD manually
│ ├─ Dashboards
│ ╰─ Internal Docs
├─ tip ── try doing ALL work from within CC
│ ╭─ code conventions are not in the model
├─ limits ┼─ fine-tuning doesn't work well ── leads to more hallucinations
│ ╰─ in-context learning ── ICL ── general AI wins over specific AIs
│ ╭─ rigid templates
│ ╭─ compensates lack of intelligence ┼─ guardrails
│ │ ├─ "don't let it touch X"
├─ two kinds of tools ┤ ╰─ gets less useful as model improves
│ │ ╭─ more access
│ ╰─ scales with intelligence ┼─ more control
│ ├─ faster feedback loops
│ ╰─ gets more useful as model improves
│ ╭─ context window stayed at 1M max ── models are way better yoy
│ ├─ can't dump the whole X into context ── X ┬─ wiki
├─ context window is a box ┤ ╰─ codebase
│ ├─ example ── try to run npm on Arduino
│ ╰─ don't pay for what you don't use ── [TK: no slop skills]
│ ╭─ cached tokens are cheap ── new are expensive
│ ├─ not an LRU problem
├─ KV cache ┼─ change in early instructions invalidates the cache ┬─ add new tool
│ │ ╰─ change in CLAUDE.md
│ ╰─ put stable stuff at the front ── volatile at the end ── CC teams tries to solve this problem
├─ Large-scale Software Engineering ── main question ── Does it scale?
│ ╭─ when it's the right tool?
│ ├─ CC has a shell ── Skill+CLI has less overhead
│ │ ╭─ name
│ ╭─ MCP ┼─ tools definitions sit in front ┼─ arguments
│ │ │ ╰─ description
« Agentic flow » ┤ │ │ ╭─ puts just name in the system prompt
│ │ ╰─ tool search ┼─ kind-of lazy-loaded
│ │ ╰─ needs to be very specific ── e.g. slack
│ │ ╭─ in-context
│ │ ├─ one-line description always loaded
│ │ ├─ full SKILL.md and assets loaded on-demand
├─ Plugin primitives ┼─ Skills ┤ ╭─ body is pay-per-use ── good
│ │ ╰─ does it scale? ┼─ reliably loading requires a paragraph in description
│ │ ╰─ not possible to lazy-load sub-skills ┬─ no hierarchy yet
│ │ ╰─ what if 100k skills?
│ ├─ Hooks ┬─ runs code on events ── shell scripts
│ │ ╰─ zero-overhead abstraction
│ │ ╭─ out-of-context ── fundamental difference to a skill
│ │ │ ╭─ named role
│ │ ├─ more Claudes ┼─ own system prompt
│ ╰─ Agents ┤ ╰─ own tool set
│ ├─ spawned with a task ┬─ returns result
│ │ ╰─ its transcript doesn't come back
│ ╰─ description still in-context ── what if 100k agents?
│ ╭─ loads fully unconditionally ┬─ doesn't scale
│ ╭─ CLAUDE.md ┤ ╰─ every plugin adds it
├─ Doesn't scale ┤ ╰─ better inject via SessionStart hook
│ │ ╭─ low-quality ── low-cost ── useful, different contract
│ ╰─ Memory ┼─ model-curated, not human-curated
│ ╰─ plugins are human-authored, human-reviewed
│ ╭─ worktrees ┬─ one repo ── N claudes each owns its branch
│ │ ╰─ better make it long-lived ── less overhead ── [TK: try kunchenguid/treehouse?]
├─ Multi-clauding ┼─ asynchrony ┬─ walk away, let it do the work
│ │ ╰─ /loop 10m
│ ├─ parallelism ── multiple of asynchrony
│ ╰─ lot's of context switching
╰─ Agent-teams ┬─ teammates ── long-lived ── unlike agents
╰─ SendMessage tool ── Claude's talking to each other
Follow-up questions:
My GNU Emacs configuration works from two machines I regularly use.
Configuration is an Org file living within my Notes corpus. Then on
save it's tangled into el file and init.el loads it. I keep custom
packages in separate repository that configuration adds to load-path.
On <2026-08-22 Sat> I bumped into situation, when on one of machines, after fresh Emacs startup a symbol from lozenge.el package is not defined.
– prompt
defalias doesn't load via require and use-package why doesn't loading lozenge.el at emacs startup define an alias ◊git-status? I did (require 'lozenge), evaluated (use-package) block, added :demand t to it, still (◊git-status "~/.velppa/hotter.myaddr.dev") was failing with
eval: Symbol’s function definition is void: ◊git-statusI had to go to lozenge.el and do (eval-buffer) there.
Root cause was stale lozenge.elc file that didn't have alias defined. Solved by removing all elc files, and for the future setting this in Pavel's Emacs Configuration v3:
(setq load-prefer-newer t)
We use Datadog Case Management at $WORK for managing failed batch jobs. When a job fails, it sends event to EventBridge then to Datadog Events, then a Monitor captures and opens a new case, providing all the details of failure (links, names, timing, basically what comes in the event). Automation workflow archives duplicated active case by title, so sequential daily runs only lead to the first case. Works really well, about 4000 cases have been created in the last 6 month of usage. AI agents are checking open cases on schedule and do root cause analysis and resolve cases (open PRs with fixes) semi-autonomously (Claude became lazy recently).
Today I noticed that Datadog renamed Case Management to Work Management, and it changes premise quite a lot. Do you remember Slack mission "Slack - where work happens" - well, often it's true, but when it is true, it means somebody doesn't do their real work. If we have a product "Work Management", then, well, why don't we use it to manage work, and manage work in Slack/Notion/Shortcut/Github. Fifth place to manage work. Thank you very much, dear Datadog, you went from a strong concept of a funnel – Alert → Case → Incident – into vague "Work Management"
Case Management API has been always not pleasant: heavy relying on UUIDs, lack of public API methods - can't link cases, can't READ COMMENTS - yes, you can POST a comment, but you can't read it back. To overcome these limitations, I had to check what Datadog UI is doing and wrap it into datadog-mcp-server.
What has changed in the API side of things with this renaming? Absolutely nothing, Work Management doesn't exist nor in API reference nor in the API requests, they still go to https://app.datadoghq.com/api/v2/cases.
Textpod received better assets sharing.
New logic:
file: or attachment:) are be copied
to assets and served from textpod.Examples:
file:
Image:
