[HN Gopher] Show HN: Sheet Markup - add spreadsheets to a Markdo...
___________________________________________________________________
Show HN: Sheet Markup - add spreadsheets to a Markdown document
GitHub: https://github.com/EqualTo-Software/stackedit-sheet-markup
Author : diarmuid_glynn
Score : 73 points
Date : 2023-04-11 12:32 UTC (1 days ago)
(HTM) web link (www.equalto.com)
(TXT) w3m dump (www.equalto.com)
| nine_k wrote:
| I wonder when will Markdown adopt enough features of Org Mode to
| become a viable replacement for people not using Emacs.
|
| (Yes, Org Mode has spreadsheets, of sorts.)
| diarmuid_glynn wrote:
| Cheers!
|
| 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
| thangalin wrote:
| 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.
|
| 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...
| diarmuid_glynn wrote:
| I've never seen KeenWrite before, it looks nice!
|
| 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.
| thih9 wrote:
| 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?
| diarmuid_glynn wrote:
| Yes, that's intentional. Assuming "another | $1000" is on the
| 7th row, you would need to update the formula to:
| =SUM(B2:B7)
|
| to incorporate it into the sum.
| seanosaur wrote:
| This looks great! Are there plans to spin up a plugin for
| Obsidian and similar apps?
| diarmuid_glynn wrote:
| I'm not familiar with Obsidian, I'll take a look.
|
| 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.
| diarmuid_glynn wrote:
| 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.
| breck wrote:
| Interesting! I am very interested in this stuff. If you ever
| want to chat I've spent way too long toying with different
| versions.
|
| 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...
| layer8 wrote:
| Where can I find the table syntax specification and the formula
| language specification?
| diarmuid_glynn wrote:
| We don't have a formal grammar yet. We'll put one together
| and add it to the GitHub repo tomorrow.
|
| 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) ```
| layer8 wrote:
| Thanks, that would be great.
| pflanze wrote:
| Pandoc also supports[1] pretty featureful ways to declare
| tables, may be worth looking into.
|
| [1] https://pandoc.org/MANUAL.html#tables
| diarmuid_glynn wrote:
| Pandoc tables remind me of the reStructuredText tables,
| which I used back in the day: https://docutils.sourceforg
| e.io/docs/user/rst/quickref.html#...
|
| 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).
| benatkin wrote:
| Why not just use GFM? Item |
| Cost -------------- | ------------- Rent
| | $1500 Utilities | $200 Groceries
| | $360 Transportation | $450 Entertainment
| | $120 **Total** | `=SUM(B2:B6)`
|
| https://github.github.com/gfm/#tables-extension-
|
| 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.
| diarmuid_glynn wrote:
| I hadn't reviewed GFM's table extension previously,
| thanks for sharing.
|
| 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!
| benatkin wrote:
| I'm working on internal DSLs for markdown. I think it's a
| pretty powerful language and often it can be used in a
| different way rather than changed. For instance, a badge
| with a link could. A nice thing about a true internal DSL
| is that they are supported because it's the same
| language, being an internal DSL rather than an external
| DSL.
|
| 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
|
| Though it isn't md I think I will have md in the name of
| the extension, much like jsonl has l in the name but a
| jsonl file with two or more lines of data isn't a single
| valid JSON document.
|
| Edit: here's one that displays on GitHub:
| []()|[]()|[]() -|-|- Rent | $1500 | paid
| Utilities | $200 | unpaid
| diarmuid_glynn wrote:
| I see. I'm a big fan of DSLs, but the internal vs.
| external distinction is not something I've seen
| articulated before.
|
| 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.
| antman wrote:
| B2:B6 is a bit out of context? perhaps also add
| SUM(*Cost*)?
| diarmuid_glynn wrote:
| Note that you can represent much more complex
| spreadsheets using Sheet Markup, and while in the above
| example it might be clear what SUM(COST) would mean, in a
| more complex spreadsheet, with multiple different tables,
| it might be ambiguous.
|
| 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.
| Groxx wrote:
| Seeing it in a context without a UI to show you the row
| and column numbers felt a bit awkward to me too...
|
| ... 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"
|
| I'm waffling between rx-like and unix-like for terms
| though. Or something else. But a much more relative-and-
| whole-sheet-focused language seems like it could be a lot
| nicer than pinning cell IDs everywhere.
| MilStdJunkie wrote:
| 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.
|
| 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.
| blackbear_ wrote:
| Happy to see the world slowly catching up to org mode in emacs..
| ;) jokes aside, cool stuff!
| iddan wrote:
| Great stuff! If you'd like to add a spreadsheet to your React /
| MDX I created a similar small component
| https://github.com/iddan/react-spreadsheet
| diarmuid_glynn wrote:
| Very nice - I don't think I've come across this project before.
|
| 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?
| iddan wrote:
| Thank you! The vision is to support as many spreadsheet
| capabilities as possible while retaining the simplest API and
| a small enough size. So multi-sheet is possible as long as
| using the component with a single sheet is still simple.
___________________________________________________________________
(page generated 2023-04-12 23:01 UTC)