My text KeenWrite supports R Markdown. I wrote a simple function to convert CSV data into a Markdown table[1] along with a tutorial demonstrating usage[2]. This allows users to keep the data separate from the document.<p>Having the ability to apply spreadsheet functions as per EqualTo is brilliant.<p>[1]: <a href="https://github.com/DaveJarvis/KeenWrite/blob/main/R/csv.R">https://github.com/DaveJarvis/KeenWrite/blob/main/R/csv.R</a><p>[2]: <a href="https://youtu.be/XSbTF3E5p7Q?list=PLB-WIt1cZYLm1MMx2FBG9KWzPIoWZMKu_&t=186" rel="nofollow">https://youtu.be/XSbTF3E5p7Q?list=PLB-WIt1cZYLm1MMx2FBG9KWzP...</a>
We've found "sheet markup" (a simplified, textual representation of a spreadsheet) useful in other contexts, such as when interacting with an LLM. I think there might be quite a few other interesting uses, happy to discuss.
Dang, that's nifty. In Asciidoc, everything has to go to CSV or some kind of delimited format, which means you need the TextQL extension if you want to calculate at the document layer. I've given guidance that the compute needs to be done before it goes into the document change control - TextQL lets you cheat, but you don't want to hinge a document process on something like that.<p>A little off topic, but it's something I wanted to ask from a more technical audience than myself. Asciidoc's table model can be instructed to use any arbitrary character as the delimiter (pipes, commas, tabs, etc) , which led a lot of people to ask me: why not support JSON as tabular format? At the moment, JSON has to be rendered via PlantUML (JSON) block. The only answer I could give (aside from RFC 4180, which is at the heart of adoc's table model) was that JSON, like XML, can recurse a record arbitrarily - making it pretty difficult, from a compute perspective, to render with a given resource. You can have columns in columns in columns. Here's my confession: I'm not really sure my answer holds any water. Any table model that supports merging and splitting (which Asciidoc's does) can support a modest level of recursion. So probably, the real reason, is that it's just too damn hard to extend the table model to JSON data.
Great stuff! If you'd like to add a spreadsheet to your React / MDX I created a similar small component <a href="https://github.com/iddan/react-spreadsheet">https://github.com/iddan/react-spreadsheet</a>
so...this isn't bidirectional? becuase the first thing i did was edit the spreadsheet on the right and i was expecting it to update the markdown on the left but i guess not.<p>should just disabled editing the spreadsheet if that's how its going to be
This looks really cool. I would love to have an embedded spreadsheet on my blog for some use cases. However, it seems that all entered data is siphoned into your service. Correct?
If I add a row at the end saying “another | $1000”, the total doesn’t get updated (the SUM still points to B2-B6, so doesn’t include the new field). Is that intentional?
I wonder when will Markdown adopt enough features of Org Mode to become a viable replacement for people not using Emacs.<p>(Yes, Org Mode has spreadsheets, of sorts.)