I’ll redo my wish into: I wish Pikchr was more expressive. I’m not attached to Mermaid, but I do like things that make the common tasks simple.

AFAICT the Pikchr language is still pretty close to its PIC roots, which is comparatively low level. An expansion to better handle the sort of diagramming that has become common since PIC’s 80s time would be excellent.

This is especially true in the context of Fossil, where being able to make quick flowcharts or sequence diagrams would be super useful.

There is a point at which you end up re-writing the entire universe yourself for smaller and smaller gains

Sure, but it depends how strongly you care about the security of the supply chain for a core piece of software for our industry, Vs having a more featureful way to make diagrams.

creating inline diagrams to display in documentation or comments in a VCS used to handle sqlite code isn't that much of a security issue IMO. It's bordering on paranoia :)

> It's bordering on paranoia :)

FWIW/FYI... as someone who has collaborated extensively in the "Hwaci ecosystem," for lack of a better term (projects stemming from Richard Hipp and his company (Hwaci)), i can elaborate a bit on that...

It's not about security in the conventional computing sense, but more about _supply-chain security_. Any third-party components can become unmaintained or break in incompatible ways at any time. The Hwaci ecosystem has a strong culture of avoiding third-party-dependencies, stemming from/related to Richard's definition of freedom: "freedom is being able to take care of yourself," i.e. not depending on others to take care of you. It's important to Richard, and is therefore a part of his projects' cultures, that those who maintain the project are capable of continuing to do so. It's not always feasible to take over maintenance of upstream third-party code, or port away from it, if it suddenly becomes unmaintained. Similarly, it is not always feasible to adapt one's own code to incompatible changes made in upstream third-party code. Avoiding upstream dependencies, despite the obvious annoyance of having to re-invent the wheel at times, inherently gives a developer more freedom over the direction of their own projects. All projects within the Hwaci ecosystem share the trait that they eschew third-party dependencies unless they are (A) unavoidable, (B) non-trivial or non-sensible to reimplement in some minimal form, and (C) ubiquitous (zlib, libssl, and tcl being the counter-examples which most readily come to mind).

That's the short and the long of it.

I was on the both sides of the spectrum: from everythig custom-built to everything is a third-party dependency.

I guess you managed to find the balance where it works.

Because on the one side it often falls into "oh, we built a PDF writer, and a phone routing system, and a generalised build system from scratch, and now we have no one who knows how these work, how to upgrade them, or replace them". On the other side is "we've been running this PHP 4 project forever because the cost of upgrading every third-party library used across all the breaking changes is at least a three-year project, so we're better off not touching it" :)

Core software is worlds apart from some client app.

Dependencies get compromised, supply chain attacks are extremely real. If you write a webapp do whatever works for you. If you write software with a blast radius as large as SQLite's then please consider not pulling in some vulnerable third party lib for a nice to have.

Makes me think of SerenityOS. Although I have not heard it stated the motivation in that way, seems it arrived at a similar conclusion.