Tables in a plain text zettelkasten
Hi!
Quite often when I take notes I need tables, but so far I haven't found a satisfying method to include them in my zettelkasten system. There are several options, each with serious disadvantages:
Option 1: Include Markdown table on a zettel directly, edit it with @ctietze's TableFlip.
- [PRO] Markdown tables resilient, no heavy reliance on any app that might seize to exist after a while for just reading them.
- [CON] Usually the Markdown tables will be too wide for a zettel, which makes it look very messy, almost unreadable.
- [CON] TableFlip is a quite limiting. You can't drag columns or rows around, sort rows alphabetically, have a line break within a cell, etc.
Option 2: Create and edit Markdown table with TableFlip in separate file, link to the file from zettel.
- [PRO] Markdown tables resilient, no heavy reliance on any app that might seize to exist after a while for just reading them.
- [PRO] Size of table can be whatever I like.
- [CON] TableFlip is a quite limiting. You can't drag columns or rows around, sort rows alphabetically, have a line break within a cell, etc.
Option 3: Use Excel (or other app like OmniOutliner, Numbers) to create and edit table in separate file, link to the file from zettel.
- [PRO] Most important functionality included in such apps, e.g. dragging colums and rows around. You can even include images and indent and fold rows.
- [CON] Tables can't be shared easily with people who don't have the app.
- [CON] Relies on app being available in the future, whilst it would be nice to get rid of it. In case it gets abandoned, there is the option to export table to .xlsx, which can be imported by Google Sheets. But: Formatting usually not nice, some functions might not to be supported, etc.
Option 4: Use Google sheet and link to it from zettel.
- [PRO] Important functionality included: Rows and columns can be dragged around, hidden, links can be included, etc.
- [PRO] Can be shared easily.
- [CON] Data on Google servers, so relies on internet connection and not very protected.
- [CON] Relies on Google sheets being available in the future. Could be exported to .xlsx, Open Office or PDF if that becomes problematic.
How do you do it? Are there any tools I'm not aware of yet, e.g. other Markdown table editors with more functionality than TableFlip? And @ctietze: How is the progress in the development of TableFlip? More features coming soon?
Howdy, Stranger!
Comments
Option 1 (built-in iA Writer table), and Option 3 when the table stops being just a table and becomes a spreadsheet with calculations and custom formatting.
@Splattack: Hm, the built in option in iA Writer wouldn't be enough for me as far as I can see – that's even less functionality than TableFlip has to offer...
@Vinho Thanks for the hint on Tableflip - very nice!
My position is this. I use very simple tables in Markdown in the Archive. Spreadsheets in Emacs.
But there is a good point to make that for quite some professions spreadsheets should be in the Zettelkasten from a methodological perspective.
I am a Zettler
It depends on whether you want your ZK to contain mostly ideas or also a lot of data. Of course, spreadsheets shine when storing, sorting and displaying data. You could also store ideas in a spreadsheet, but it would quickly get unwieldy if too large.
So I tend to follow that same practice as you - store my data mostly (not exclusively) outside my ZK and make reference to a relevant file name; store ideas within my ZK.
To me, this is not an issue of data vs ideas. For example, when describing an experiment I want to get close to the data as possible. This is: Accurately storing information of the experiment with as little interpretation as possible and covering the interpretation's conditions.
A biochemist might want to use his ZK to store data of his/her experiments.
I am a Zettler
@Sascha Didn't know that Emacs can handle tables as well – maybe I should look into it again... Don't really like it unfortunately...
The main situation in which I have needed tables in the zettelkasten so far is when I want to compare different versions of something under several aspects. Examples:
In these situations, I would like the table editor to have the following features:
@Vinho
Nobody likes Emacs. People who use it are just in an abusive relationship with this beast.
However, anything is possible in Emacs. So, any question that goes something like "Can Emacs.." the answer is: "Yes, there are 12323 possible solutions. 2 might be actionable without suffering weeks of Elisp torture."
I am a Zettler
when deciding if a table should be used in a Zettelkasten size does not matter (that's what she said). I haven't used tables in my ZK yet, because it is so fiddly to create them in plain text. When looking at tables in my old note taking (prior to ZKM) i find myself with a dilemma. Sometimes a table is both an essential reference but simultaneously a candidate for being poorly connected.
for digital Zettelkasten, how about disabling word wrap in structure notes? Do we need limited width when talking structure? I don't think so.
when thicc tables are applied on content i would try to use another method to represent it. This might not be possible, though, but i would be hesitant to allow any table to overflow the width of the body.
my first Zettel uid: 202008120915
p.s.: this is not a rhetorical question. I accidentally made it into one but am interested what others think about it ¯(ツ)/¯
my first Zettel uid: 202008120915
I toyed with the idea to have more horizontal screen real estate for tables etc, but it'll take a long while before I can even experiment with that because the whole text rendering thingie would have to be customized. It's on my long list of cool things
Author at Zettelkasten.de • https://christiantietze.de/
That would indeed be a cool thing, but for now I'd be quite happy with storing the table in a separate (plain text) file and being able to edit it as I want with a plain text table editor that shows the table cleanly in its whole width.
After having played around with it a bit more, the main remaining problem with plain text table editors that I have is that line breaks within a table cell seem to be impossible within the editor itself. There is the option to add a
<br>
tag, which makes preview tools like Marked 2 insert line breaks, but I'd like to have the line breaks in the editor itself. Is there any way to do this (and if yes, are you planning it in the foreseeable future for TableFlip)? As far as I can see, editing tables in Emacs also wouldn't solve this problem...I'm afraid the concept of plain text tables doesn't work with multi-line text cells in principle. There's only one kind of line break in a text file, no matter where you place it. Editors can only add conveniences to let you edit multiple lines of aligned cell contents as if it was 1 piece of text.
It's like the
rowspan
attribute in HTML tables. See here for an illustrative example: https://www.w3schools.com/Tags/tryit.asp?filename=tryhtml_td_rowspanYou can get that in HTML because there's syntax to group cells across line breaks, but that's not the visual format you want -- you're kinda stuck with this request, I'm afraid
Author at Zettelkasten.de • https://christiantietze.de/
@ctietze: Hm, shit... But thanks for pointing that out!
Instead of integrating tables in a single note, here‘s another idea (that I‘d also like to implement for my own app):
Imagine that each "table row" is simply a separate Zettel note. Within each of these notes, you can assign custom attributes/properties/metadata to the note. These custom attributes would be string-based key-value pairs, defined either in a YAML metadata block, or maybe simply as a tag. In MultiMarkdown, this could be something like
[@key:value]
, e.g.[@maturity:draft]
or[@maturity:published]
.Now, imagine that your Zettelkasten app has a note list which can display multiple columns. I.e., next to the “note title” column, you’d be able to map additional columns to attribute keys. The attribute key (e.g. “maturity”) would become the column title, and the column rows would list just the attribute values (in the above example, “draft” and “published”).
With such a setup, you could:
Export to common table formats would need to be handled by a script, though. But the scripting interface could give access to these custom attributes.
With this approach, you’d benefit from “rows” being regular Zettel notes, and your Zettelkasten app being the “table editor”. And this approach could be used for all kinds of analysis.