Having the ability to apply spreadsheet functions as per EqualTo is brilliant.
[1]: https://github.com/DaveJarvis/KeenWrite/blob/main/R/csv.R
[2]: https://youtu.be/XSbTF3E5p7Q?list=PLB-WIt1cZYLm1MMx2FBG9KWzP...
Feel free to reach out (email in my profile) if you'd like to discuss how Sheet Markdown could be added to KeenWrite. Assuming you're displaying the preview using some sort of modern HTML render with canvas support, it should be pretty easy to do.
Also, I must ask. Does anyone know an keenwrite-like-emacsExtension. I would really appreciate it.
[1]: https://youtu.be/CFCqe3A5dFg?t=48 (variables tutorial)
In my experience editing Markdown tables by hand isn't fun.
I just go with CSVs or PSVs or Space Separated values.
Here's how I do it in Scroll (my markdown alternative):
https://try.scroll.pub/#scroll%0A%20table%20%7C%0A%20%20Item...
I've sent a mail to the gmail referenced in your profile page.
Informally: each row in the sheet is a new line, and each cell is separated with a pipe (|). Cells can contain either values (various number formats supported) or formulas. Example:
```equalto
**Item** | **Cost**
Rent | $1500
Utilities | $200
Groceries | $360
Transportation | $450
Entertainment | $120
**Total** | =SUM(B2:B6)
```One thing I should mention, we have another tool which makes it easy to embed a spreadsheet in another app via an IFRAME:
- https://www.equalto.com/suresheet
The benefit of using the above is that Sure Sheet URL will always load the "same" spreadsheet. Edits aren't automatically saved, unlike (say) a Google Sheet.
That said, I think tables are markdown's Achilles heel - anything involving multi-line content starts to make things complicated.
[0]: https://github.com/tgrosinger/advanced-tables-obsidian
[1]: https://github.com/ganesshkumar/obsidian-excel-to-markdown-t...
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.
I'm curious, what's your vision for react-spreadsheet? I notice it supports some formulas, and a "single sheet" view. Do you plan to make it a more complete spreadsheet component in future, or do you see that as out of scope?
should just disabled editing the spreadsheet if that's how its going to be
For instance I can publish an article on the economics of ecommerce. And someone consuming my article might want to check the unit economics and might want to just divide the numbers by the total units sold. Instead of having to do that on a calculator, he can just do it on the spreadsheet.
That said, I think 8n4vidtmkvmk has a point that it would be nice if when authoring the Sheet Markup, edits in the spreadsheet preview would be applied "in kind" to the Sheet Markup (bidirectional sync). This would mean you could author the Sheet Markup using the spreadsheet preview, instead of relying 100% on Sheet Markup for authoring.
If you inspect the "Network" tab in Chrome and you can verify that there isn't any network I/O after you modify the markdown.
Edit: and thanks for the complement! I should mention that most of the look-and-feel is courtesy of StackEdit:
Our contribution was to extend StackEdit to render spreadsheets using our Sheet Markup syntax.
=SUM(B2:B7)
(Yes, Org Mode has spreadsheets, of sorts.)
I've heard of, but never used, the emacs spreadsheet / org mode stuff. I should probably review it for concepts that I could steal / be inspired by ;P
Some of the tech is open source ( https://github.com/EqualTo-Software/stackedit-sheet-markup ) and some of it depends on tech in our closed-source EqualTo Sheets product ( https://sheets.equalto.com/ ), which is in beta right now. We've considered open-sourcing some / all of EqualTo Sheets, and it may yet happen, but it's not something I could commit to right now.
So, regarding EqualTo Sheets:
> What happens with the data I enter?
Data entered into an EqualTo Sheets workbook is saved to the EqualTo server.
This is to some extent the value we provide with EqualTo Sheets: you can just paste the code snippet we provide into your code base and immediately have a functioning workbook that saves changes and supports parallel editing.
> Can I use an API to dump and restore data and formulas?
Yes, we have a bunch of APIs. You can export / import XLSX, as well as read / write individual cells using REST and GraphQL APIs. Some more details:
- https://sheets.equalto.com/beta-readme
- https://sheets.equalto.com/docs/
- Join the open beta (just provide an email address and click on a link in the email you receive): https://sheets.equalto.com/
Asking because your subprocessors list doesn't give an immediate answer.
> Asking because your subprocessors list doesn't give an immediate answer.
Fair complaint :) I'll update our subprocesser page tomorrow to make this clearer.
Item | Cost
-------------- | -------------
Rent | $1500
Utilities | $200
Groceries | $360
Transportation | $450
Entertainment | $120
**Total** | `=SUM(B2:B6)`
Getting rid of the vertical divider is nice but I'd rather think of it as a tiny modification to GFM than a distinct language.
Putting the in backquotes could make it look more like a formula and also it could be required for formulas to prevent accidentally invoking it.
It really is nice to have the horizontal bar gone, though. I think I might make my own format based on it. I tried to get rid of the bar but saw that you can't. In fact the only way you can have everything on one side of the bar is to only have a header (thead) when it would often be useful to only have a body (tbody).
FWIW original markdown requires pipes at the start and end of each row but not GFM.
At first sight, I think GFM's table extension and Sheet Markup have different goals. While the table extension is intended for displaying a single table of data, Sheet Markup for defining an interactive spreadsheet, including things like formulas. Such a spreadsheet might not really be a single "table" as such, it might be multiple separate logical tables. Also, I suspect that we will in future want to extend Sheet Markup with additional features which would be "even further" from what GFM's table extension supports.
But thanks, certainly food for thought!
External DSLs of course give you full flexibility, as you are no longer constrained by the language. https://javieracero.com/blog/internal-vs-external-dsl/
My past work and this gave me the idea to do something that sits between an internal DSL of markdown and an external DSL - to allow tables without row dividers, but put them in fenced code blocks with a different language name so they don't get displayed wrongly by existing markdown tools, instead displayed as code. And because this is the only difference, to make it display as a table using existing gfm tools, an empty header could be added, since normally it's not desirable to have the whole thing as a header.
Here's an empty header that at least on https://loilo.github.io/gfm-preview/ shows up shorter than a normal line:
[]()|||
-|
Rent | $1500 | paid
Utilities | $200 | unpaid
Edit: here's one that displays on GitHub:
[]()|[]()|[]()
-|-|-
Rent | $1500 | paid
Utilities | $200 | unpaid... and it made me wonder if some other syntax would work better, which made me think that maybe something like this would work?
=sum(column | 2+ | above)
targets whole column "stream"
second item and later
above this cell
pipes manipulate the target "stream"
As for why one would possibly ever want to use Sheet Markup for mode complex spreadsheets, one use is as a way to interact with an LLM. We've started to see some interesting results using GPT-4 to analyze various kinds of spreadsheets that have been encoded in Sheet Markup.
Very powerful, but I found it challenging to remember the syntax since I was only using them intermittently. Still, it could indeed form the basis of a more advanced spreadsheet markup syntax, supporting things like merged cells (which Sheet Markup does not, and probably never will, support).
For now, I'm treating Sheet Markup as an external DSL, which can be embedded in a Markdown document using a fenced code block. But there are certainly benefits (and costs) to developing an internal DSL for spreadsheets along the lines of what you're suggesting.