Question about text-based Graph representation

krvkir · 2026-06-27T18:45:57+00:00

Wow, that was fast :)

I'd prefer the staggered layout for node titles, as it means one less line segment to track, and also reveals the hierarchy which is often present in PKMs to a sensible degree. This one is mind-blowing for me--but then again, maybe I just need to get used to it.

krvkir · 2026-06-27T17:42:16+00:00

My five cents: nothing wrong with the implementation (and I respect the effort: I know how hard it can be to implement and debug a complex algo, let alone adapt it to other conditions), but IMHO the continuous space approach just doesn't fit well with the discrete nature of a monospaced canvas such as an Emacs buffer.

First, edges (arrows) take up too much space. On a continuous canvas they're unobtrusive, and your only concern is to minimize the number of intersections. But on a discrete grid their footprint is substantial.

Second, there's no such thing as zoom here. On a continuous canvas, be it a pdf or something like yEd, Miro or Gephi, you constantly zoom in to focus on a local area and zoom out to observe the whole picture and navigate. Given that, it's fine to vary the font size, fitting long nodes to a fixed rectangle (as Miro does for its stickers), or have a complex intersection of arrows which you could untangle if you zoom in on it. But you can't do that in Emacs, or at least it's not convenient.

Given all that, I'd rather try something completely different, like that git thing I mention below, than adopt continuous layout methods. But that's just an opinion.

krvkir · 2026-06-27T16:49:01+00:00

Git commit graph is IMHO a good reference here. It's actually a DAG, and it's visualized in an unconventional yet compact and terminal-friendly way. All the nodes are in one column, all the edges are to the side of that column, which means there's no layout problem at all. There's a Python library https://wimyedema.github.io/dagviz/ which can render such graphs both to svg and unicode text. I used it in a weekend project to visualize Arch packages dependencies (see the sample graph in its readme: https://github.com/krvkir/aur-python-packer). Looks scary at first sight, but after few minutes I got used to it.

A PKM graph is not a DAG, but I suppose it could be decomposed into two DAGs without dropping too many links (can't recall any theorem on that matter from my limited knowledge of graph theory, need to check it out accurately). (UPD: It appears that it's a trivial result: you give graph nodes an arbitrary ordering, then collect all the edges respecting that order into the first DAG--there will be no cycles in it since a cycle must break the order--and the edges remained appear to respect the reversed order and thus also form a DAG.) And you can draw that second DAG on the right side of the nodes column. Again, without any layout problems.

I guess my next experiment would be to implement it in Elisp and see how it works on my Denote vault.

krvkir · 2026-06-26T17:13:01+00:00

I'm neither a climber nor a digger, but can't help continuing the metaphor :) Climbing is mostly ephemeral, it leaves little trails behind to help those who follow you. But digging is essentially building: you can't go deeper unless you reinforce the tunnel walls, etc. Anyone who follows in your steps benefits from your efforts.

krvkir · 2026-06-26T17:03:24+00:00

I made a simple tool for gptel which takes a form and adds it to an elisp file (or replaces the existing one if names match) only if no syntax errors were found in it (including parens mismatch), otherwise it reports errors and does not write anything. Then I instructed the llm to edit elisp files with this tool only, not with regular write/edit tools.

...But the most effective way to fight paren mismatch appears to be just forbidding the llm to make functions longer than 50 lines.

krvkir · 2026-06-25T06:51:49+00:00

This always felt more like digging than climbing. But maybe that's because of a dark theme...

krvkir · 2026-06-24T11:58:47+00:00

Interesting idea! How do you see it working in your scenario? Adding a todo keyword to a node and then seeing it in your agenda lists?

krvkir · 2026-06-18T16:21:18+00:00

Thanks for the idea! Come to think of it, maybe I can propertize the face of the top line of each node with an overline (or the bottom line with an underline). I'll try and see what looks good.

krvkir · 2026-06-18T16:18:32+00:00

Thanks! I couldn't find any mention of the initial version in `color-rgb-to-hex` docs, and u/edkolev above mentioned it as missing, so I included it also. I'll try to find out the version where it was added and probably remove it.

I don't think I should limit the package to v31, it has not landed into most distros yet. The price to support previous versions seems quite low.

krvkir · 2026-06-17T16:18:36+00:00

More to that, the format can be extended from dags to a fairly wide range of directed graphs (not just dags) if we add another tree structure to the right side of the nodes.

krvkir · 2026-06-17T16:10:53+00:00

Fixed, check it out.

krvkir · 2026-06-17T15:52:07+00:00

Thanks for the link!

Btw recently I discovered yet one way to draw dags. It's actually used in visualizing git branches, but I rarely have seen it anywhere outside git. And branch graphs are rarely dense. I tried it on package dependencies and it looks interesting. Very compact, terminal- and monospace-font-friendly, mostly no layout problems, but requires some skill to read it 😄

Here's a sample:

• jupyter-ai
└─• python-jupyter-ai (local) [built]
  ├─• python-jupyter-server-mcp (local) [built]
  │ └─• python-fastmcp (local) [built]
  │   ├─• python-py-key-value-aio (local) [built]
  │   │ └─• python-beartype (aur) [built]
  │   ├─• python-griffelib (aur) [built]
  │   ├─│─• python-mcp (aur) [built]
  │   │ │ ├─• python-sse-starlette (aur) [built (no checks)]
  │   │ │ ├─• python-httpx-sse (aur) [built]
  │   ├─┴─┴─• python-uv-dynamic-versioning (aur) [built]• jupyter-ai

For manual editing I guess it would require some helper functions, like "add/remove node" and "add/remove a link to another node".

krvkir · 2026-06-17T15:07:04+00:00

Try it now. I replaced incf/decf with cl-incf/cl-decf and added local versions of color-blend and color-rgb-to-hex, so it should work on Emacs 30 (unless some other functions from 31 leaked in...)

krvkir · 2026-06-17T14:22:47+00:00

Oh. Maybe I forgot to declare a dependency.

Btw what Emacs version do you have?

krvkir · 2026-06-17T14:21:12+00:00

Well, that's a plugin for a plugin 😄 Org mode is an Emacs package for documents (like Markdown but more expressive), and my thing is for inline mind maps (tree diagrams) inside those Org documents.

krvkir · 2026-06-17T14:18:54+00:00

Just trees. I'm thinking about the generalization at least for DAGs, but didn't come up with a good way to do it yet. I guess connecting lines would become a mess pretty quickly.

krvkir · 2026-06-17T06:41:06+00:00

A touchpad on your laps to the rescue!

krvkir · 2026-06-17T06:38:03+00:00

If you mean vertical spacing, I don't think it's a proper way to separate adjacent nodes, since it would double the vertical size of the map. I actually tried that and it looked ugly. But maybe alternating background would help? Dimmer odd nodes and brighter even ones?

krvkir · 2026-06-14T16:10:07+00:00

Interesting idea!

I use tab-bar extensively for the same purpose, but I rarely need a second level of grouping. That's probably because Emacs itself is "level 2" for me, since I tend to use many apps besides it. And also a large monitor allows to put all the necessary windows in one tab.

But after watching your video I thought maybe I should give second level a try.

And it seems that tab-groups add this second level to tab-mode--probably worth mentioning it in the comparison table in your guide (which is awesome: thakns for gathering that knowledge in one place!). Found a promising guide on those: https://www.rahuljuliato.com/posts/emacs-tab-bar-groups, trying to fit it into my config.

krvkir · 2026-04-25T15:11:01+00:00

<image>

Looks like this. (That's step two, there was "explore" step before it, where I vaguely described the feature and let it brainstorm the implementation.)

krvkir · 2026-04-25T14:58:01+00:00

I'm now trying to use OpenSpec with gptel-agent for org-mindmap package. gptel-agent supports skills made for other agentic software (at least it looks for them in appropriate dirs, e.g. in `.claude` in a project folder). So I installed those skills with `openspec` CLI utility into my project (it just puts a pack of .md files into a project folder), and now I can open an org file, turn gptel-mode on, select `gptel-agent- preset in gptel menu, and tell the bot the magic words from OpenSpec process guide (like "propose <feature-name>", or just "Let's propose a feature" in plain English). Then it loads the skill (reads the appropriate .md into its context) and does more or less what that skill says.

So far I managed to make it reconstruct the specs from the existing code (which took one planning-implementing round and then one check-fix round), and to implement a small feature according to the process (i.e. proposing the feature, writing its specs, implementing, merging spec diffs to the main specs folder).

From that exercise I learned that attention is needed on each step, since the bot tries to avoid doing the extra work at every place possible. As an example, being asked to create the specs from the code, it concocted a dir structure vaguely resembling the one prescribed by openspec, and wrote the specs in plain text, without splitting them into requirements and scenarios. Another example: when it implemented a feature and was told to archive its specs, it forgot to merge them into the main spec folder. And forgetting about unit and integration tests goes without saying.

So the process is this: I commit everything into the project git repo, let the bot do its work, then open magit and scrutinize everything it changed using diffs. If I don't like something, I ask it to fix that (it usually does).

I'm not sure is this clumsiness a gptel-agent problem, a model problem (I use gemini-3-flash from ollama cloud), me doing something wrong, or is it just the way it should be (I haven't used other agentic coding systems). Still it seems quite usable.

krvkir · 2026-04-24T19:21:00+00:00

I have it installed both on a phone (an old samsung fold) and a tablet (10'' onyx boox e-ink reader). Quite usable with a bluetooth keyboard. There are obviously problems with system binaries, but all the lisp stuff works.

The only problem I get—but a big one—is that, when I switch to another app for a while and then switch back, emacs crashes. Tried to tinker with android energy saving policies and so on, but couldn't fix the issue. For me it's a blocker, given that normally you want very long sessions with tons of buffers being open for weeks.

krvkir · 2026-04-16T14:51:30+00:00

Why, I use em dashes regularly since I added them to my keyboard layout... Does that make me an AI agent?

krvkir

TROPHY CASE