I am working with Pikchr and am enjoying it, but find myself wanting the classic triangle diamond for flowcharts where a decision is made. Here's an example:

DB01: line from (3,-3) \
  then go 0.75 heading 55 \
  then go 0.75 heading 305 \
  then go 0.75 heading 235 \
  then go 0.75 heading 125
text at (3,-2.58) "Tests pass?"

# "southeast"
dot at (3.29,-2.8)
# "southwest"
dot at (2.71,-2.8)

Note that the two angles on the left are more acute than those on top and bottom. I have no idea if that's consistent with accepted conventions, but it looks good to me.

I would also want a way to draw arrows in one direction or another for the "yes" and "no" paths of the decision block. I think the dots I placed would be good points for southeast and southwest; similar locations could serve as northeast and northwest. To obtain these locations I did some simple trigonometry and then fudged them a bit to make it look right.

I find it tedious to figure out all these coordinates on my own. I don't have time right this moment to look at the code, but I figure that the Fossil devs are more familiar with it and this might be "easy" (although as a developer I hate when people say that!)

Either way, I think it would be a useful feature.

Also, thanks for this simple and effective tool. It's working well for me!

Old ground.

Old ground

I see a macro definition for "diamond", but I see no request, consideration, or resolution regarding a request that there be a shape of that name.

It is a cute trick to make an invisible box and reuse its cardinal points.

There is the double indirection option, of course.

Box: box width 1 dotted thin thin thin
Diamond: line from Box.n to Box.w to Box.s to Box.e close "Diamond" fill lightgreen solid thick
Target: box with c at Diamond.c width 0.5*Diamond.width height 0.5*Diamond.height dashed thin thin thin
dot at Target.ne "  NE" above ljust
dot at Target.sw "SW  " below rjust

Clearly the boxes can be made invisible when not needed for demonstration purposes.

No fancy maths needed.

I was talking with Stephan earlier today and he convinced me that I should put in the code to support "diamond" as a primitive if somebody else would be willing to update all the documentation.

... if somebody else would be willing to update all the documentation.

... while also not immediately offering to take that part on for the simple reason that i'm not terribly well-versed in pikchr ;). (Rather, i made a concrete suggestion as to who would be great at that, and you probably know who you are. ;)

I suppose I could and should do that. But I make no claims of pikchr mastery.

you probably know who you are. ;)

Yes, and by that fact I recognize that I was forced by circumstance into writing these docs, for to think otherwise would be to deny my own nature.

Forced, I tell you. 😛

That's great Warren - but could you add toggle to the code fence definition please? Helps those of us on mobile immensely!

I was following the example of Pikchr's preexisting doc/*obj.md files, but since the Pikchrs in these serve as both visual and syntax examples, I went ahead and did it for this subset of the docs.

74% of the MD-fenced Pikchrs¹ now do this, but I didn't feel comfortable extending that blindly across all docs. Deciding that requires inspection to discern slackness from intentionality, and I can't be bothered to take that on right now. Sorry.

1. ^{^} grep -E '^(```|~~~+)\s?pikchr.*toggle' doc/*.md | wc -l divided by grep -E '^(```|~~~+)\s?pikchr' doc/*.md | wc -l

Thank you, it certainly isn't a change that needs rolling out globally.

Note a typo:

There’s a third, more subtle advantage to having this primtive built

Should be primitive.

🤦‍♂️ Thank you!

An initial cut at the changes is on a branch and I have rebuilt Fossil to use that branch version. Behold (click to toggle between raw Pikchr text and rendered image):

D1: diamond "First Diamond"
arrow
D2: diamond "Above" above "Below" below
arrow
D3: diamond "Fitted" fit
arrow from D2.s down 1cm
down
D4: diamond "Long string above" above "Below1" below fit
right
arrow
D5: diamond width 300% "thin" fit
arrow from D3.e right 2cm
right
D6: diamond height 300% "tall" above "diamond" below fit

diamond fill lightgreen
diamond at linewid below last behind first diamond fill coral
line from first diamond.e to last diamond.end
line from last diamond.s to first diamond.s
line from first diamond.start to 2nd diamond.w
text at 0.8 right of 0.4 north of first diamond.ne "Necker" above "disambiguated" fit
arrow from last text to first diamond chop
margin = 0.3

Seems to work as expected.

I am getting a syntax error on this page now. Looks like define diamond is no longer valid; I guess that's expected?

https://pikchr.org/home/forumpost/f4845b8df93f9349

I've edited my affected posts in that thread. The first diagram never used the macro, and in the second, I simply renamed the macro to "mydiamond" to side-step the keyword conflict.

Thanks for catching this. It reminds me to update my own diagrams using the macro in tandem with upgrading Fossil.

drh will have to fix his own, as my moderator powers on that forum do not let me edit others' posts.

Also an interesting parallel to some of the sqlite backwards compatibility discussions that have been had over the years.

Also an interesting parallel to some of the sqlite backwards compatibility discussions that have been had over the years.

True, but sqlite is an exceptional case with regards to backwards compatibility constraints, whereas pikchr is primarily used by the folks who develop in/around Richard's projects, where a little breakage isn't going to cause hundreds, thousands, or millions of apps to go haywire. It may even be likely that the only folks who would ever notice this particular breakage are participating in this thread.

Entirely agreed.
I meant it more as "an exception which proves the rule", in the correct historic use of that phrase (where "prove" is akin to "proving ground", and the exception demonstrates the merits of the rule in performing its intended purpose in its intended context).

It looks like you've merged the changes to trunk and trunk is running on the conical version of Fossil.

However, https://fossil-scm.org/home/pikchrshow isn't working with diamond:

/*    1 */  diamond
                 ^
ERROR: syntax error

It is working on pikchrshow here.

Hmm, now I see that.
Thanks for trying it out.

Isn't that what CI and Docker are good at?

I.e. let CI do that, instead of you or Richard.

And let the Docker file fully control the version of Emscripten, the OS, etc...

Isn't that what CI and Docker are good at?

We're collectively very old-fashioned in that regard, and make no use of docker in the canonical build/release processes. It's one more bit of third-party voodoo in the process, something all of Richard's projects go out of their way to avoid when at all possible. The pikchr/wasm update thing is just a minor nuisance, not worth introducing new tools, dependencies, and complexity for.

With Warren an expert in Docker stuff, and probably not the only one around the Fossil devs, seems like a missed opportunity to me.

I shall not require people to install Docker in order to compile Fossil. That is simply a non-starter.

If you want to use Docker, that's great. It is a powerful tool. But I won't make Docker a dependency of Fossil.

I shall not require people to install Docker in order to compile Fossil.

Especially since Fossil is usable and available on more platforms than Docker (e.g. OpenBSD).

I guess there's a misunderstanding here.

I didn't advocate to need Docker to build Fossil.

I advocated to automate deploying Pikchrshow using a mechanism (e.g. Docker) that allows control of the Emscripten version used, which seemed to be Stephan's justification for the lack of automation.

And I was simply reacting to Stephan's post justifying why it required manual intervention.

Anyways, back to lurking...

I completely agree, and this attitude/approach is exactly why I'm so fond of Fossil!

I am on Stephan's (and other graybeards') side on this one. We all could very well use a little less tooling and frameworks and packages and stuff.

Richard,

Thank you so much for implementing this feature request. It's a very welcome change from the constant clicking and dragging to get a result that's not even as good and gives me repetitive stress injury!

I used Pikchr to create a few diagrams and charts for work this week. I presented them yesterday along with the processes and technical challenges involved and got very positive feedback. That I was able to do this with a small amount of input text speaks volumes as to the well-designed nature of PIC and the simple but robust implementation of Pikchr.

Thanks again!

I used Pikchr to create a few diagrams and charts for work this week.

Are you able to share them (obfuscate your private info, of course)?

Maybe the pikchr forum would be a more ideal place for you to show off your work.