Neat!

Really clever simplicity on how you added gradients.

This is one of my favorite spaces, so I'll add some generic advice which may or may not be helpful.

I once had the privilege of working for Max Roser and Hannah Ritchie at Our World in Data, as one of the engineers on their Grapher library (https://github.com/owid/owid-grapher), and learned a ton from them (and others on the team) about making great charts.

My one piece of advice from looking at your examples would be: don't neglect title, subtitle, and caption! They would be so easy to do well because you've already created your "simple headers thingies". A few words go along way. Check out "Storytelling with Data" by Cole Nussbaumer Knaflic for a great read on the subject. Owid's Grapher does those the best, IMO (followed closely by DataWrapper.de -- but that's not open source).

At some point, if you keep up with this, you'll also want to add a dataflow library and DSL. Hadley Wickham's dplyr in R was the GOAT, and I copied that in my Ohayo tool and in OWID Grapher's CoreTable library (https://github.com/owid/owid-grapher/tree/master/packages/%4...). Jeffrey Heer's newish Arquero (https://idl.uw.edu/arquero/) library is also along those lines.

Lately I've delving into Mike Bostock's new thing Plot (https://observablehq.com/plot/). So far, excited by it, but only spent a day or two with it at this point.

I don't use emacs anymore, but hopefully something helpful in the comments above.

Thank you for Grapher! I love Our World in Data.

Oh that's why I couldn't find a recent "10% of Emacs bugs fixed": that's what he was working on! Cool stuff. A true Emacs guru.

This looks fantastic! One thought, using Emacs' feature of file- and directory-local variables for the chart config might make for a more flexible UX. (For example, I might be generating the data files and not want to have to manually modify before charting, or I might have a large directory of data files that I'd like to plot at will without having to apply a header by hand to each.)

One could also use Python and matplotlib for plotting in org mode. Gnuplot is not the only thing one can use.

Matplotlib already has a pretty uncomfortable API. I can’t imagine that wrapping that in a layer of elisp would result in anything nice to use at all.

It would probably be a case of the thing OP mentioned, where the amount of code needed would exceed just doing it yourself.

Gnuplot is the best plotting interface I’ve ever used. Once you’ve learned “the Gnuplot language”, it’s very fast and efficient to visualize anything and iterate on it interactively, and I personally find it more usable than GGPlot, Matplotlib, Seaborn, Bokeh, and Matlab.

I think Gnuplot is undervalued because by default the results look horrible. Like many power tools, it requires some config in ~/.gnuplotrc to modernize the looks; http://gnuplotting.org/ is a great source to get started.

Unfortunately, I’m mostly using Matplotlib these days because the data generation is in Python. But despite using it on and off for over a decade, I’m nowhere near my efficiency in Gnuplot, and often have to ask Google or Copilot for help if I’m doing something more complex.

Gnuplot is fantastic. And with the epslatex terminal, it sets the graphics in EPS and the text elements in TeXsobtgat you can get everything typeset juuuuuust right.

To address your python woes: https://github.com/dkogan/gnuplotlib/ Gnuplot is excellent, and I use it every day.

I find Gnuplot syntax to be terse and unintuitive, and having poor discoverability without constantly refer to the docs.

In Gnuplot you can indeed write each command in a very terse way; some simple examples:

    plot cos(x) ls 2, sin(x) ls 3

    plot 'file.dat' u 1:2 w lp lw 3 ps 2

But you can also write the same code in a descriptive way:

    plot cos(x) linestyle 2, sin(x) linestyle 3

    plot 'file.dat' using 1:2 with linespoints linewidth 3 pointsize 2

I think most people prefer the terse version once they learn it. But I’d definitely recommend learning the descriptive commands first, as the abbreviations follow very naturally from there.

You're not wrapping it in elisp. You can just write matplotlib in a code block, evaluate it, and pop out an image to your buffer.

Matplotlib has 2 APIs, a procedural one and an object oriented one. Which one are we talking about? Or both?

Seaborn, plotly, datashader, etc. all exist to wrap matplotlib and they are wildly successful. Is there some reason an equally good interface couldn’t be written in elisp?

One thing that always bothers me with both matplotlib and gnuplot, is that they literally seem to have a command (or function call) for everything. To set the tick size for the third-level ticks on the Y axis, you call set_third_level_y_ticks() or something like that. This is not necessarily bad (and maybe it has to be this way — I haven’t even tried to analyse the problem) but it feels very un-orthogonal, like everything is special-cased.

If you’re looking for something “orthogonal”, you should definitely have a look at GGPlot and its “Grammar of Graphics”.

Personally, I prefer the Gnuplot approach, but I think GGPlot has some cool ideas behind it :)

There is also ESS (Emacs Speaks Statistics) which, among other things, supercharges org-mode with R/Julia, which means the likes of ggplot2 or makie. That said, I do respect any attempt at making something with pure elisp.

You can also use R and it's plotting libraries.

Thats some solid hacking right there. Esp yhe gradient part . Also given that these plots are svg means they can the imported to latex or a web browser. The first option makes it a solid contender for doing plots that need embedding in papers. Congratulations, some good results here.