💾 Archived View for moeris.xyz › gemlog › 2022-08-04_preformatted-table.gmi captured on 2024-03-21 at 15:01:47. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-01-29)

-=-=-=-=-=-=-

About tables in gemtext (yes again ;)

renders links csv or tsv link in the document

I think that the human readable rendering of a csv file in a gemini client is a good feature as such. On the other hand, let's not forget why we use tables, we don't make databases. This approach forces you to multiply as many files as you want to integrate tables, which seems to me to be a very cumbersome way of working.

integrate the csv syntax in main document

gemini://auragem.space/~krixano/20210531.gmi

The second proposal solves the problem of multiple files by integrating them directly into the body of the document. It solves this aspect, but on the other hand, it makes the source file unreadable. Yes, I say non-readable: have you ever had fun counting the number of commas in a csv file to know which column it corresponds to? This would mean that it would not be possible to read the information correctly without using a client, which seems to me to go against the philosophy of gemtext.

in a purely non-objective way, I also find that integrating csv or other variant in a gemtext is not elegant.

It is also to put the foot in the door to integrate little by little code in the gmi files what seems to me not to go in the philosophy of gemtext.

the "preformatted table" tag proposal

The first time I saw the tables with the preformatted text blocks, I, like I think a lot of people, thought it was a bit of a hodgepodge. But now, having seen in which context it was needed (gemlog) and the other possible solutions, I find it a very interesting way to present tabular data. I would like to point out that for me, a table is not a presentation but a content. A 2-dimensional information can hardly be transmitted without using a table, it is not just cosmetic.

if we compare the size of the files, the csv and derived version wins by far. This is of course quite true, but I remind you that the goal is not to write databases, so most of the time the size will not matter given the volume of data.

In this sense the use of preformatted text already plays its role well. The only problem I see is that it's not very clean and the tables are relegated to second-class status with everything that doesn't fit, which I think is a shame.

That's why, in order to facilitate its integration, a specific tag ||| that would be used like the preformatted text ``` tag seems to me an elegant solution.

to think about

how to produce these tables easily ?

For me it is more a problem of text editor and for example with vim, we can already easily do a lot of work. It is indeed a point to dig (to be inspired by orgmode ?) and to improve.

do we have to impose a style of table representation ?

we should think about a precise and simple standard to represent a table. First of all, the use of ascii characters ( = - | ) seems to me important, the nice rendering with unicode characters can be done on the client side.

This would greatly facilitate parsing and homogenize the rendering of source files. We could also have a "compatibility" mode that would try to parse more exotic forms of table if the need would be felt. In any case, I don't have a strong opinion on the matter.

source examples

gemtext with csv

# Star Wars Comics

=> /starwars/search Search

Star wars chronology

Title,Issues,Years,Publisher
Star Wars,75,2015-2019,Marvel
Darth Vader,25,2015-2016,Marvel
Kanan,12,2015-2016,Marvel
Doctor Aphra**,40,2016-2019,Marvel
Poe Dameron,31,2016-2018,Marvel
Darth Vader: Dark Lord of the Sith,25,2017-2018,Marvel
Star Wars Adventures,32,2017-2020 IDW



bla bla bla

very long text,ccc
very long text,45 
text2,450

how to specify that the cells are merged ? it could just be the same data in two different cells and it's difficult to read informations for me for the first table for example.

gemtext with preformatted table

# Star Wars Comics

=> /starwars/search Search

|||Star wars chronology
-----------------------------------------------------------------------
| Title                              | Issues | Years     | Publisher |
-----------------------------------------------------------------------
| Star Wars                          | 75     | 2015-2019 | Marvel    |
| Darth Vader                        | 25     | 2015-2016 | Marvel    |
| Kanan                              | 12     | 2015-2016 | Marvel    |
| Doctor Aphra**                     | 40     | 2016-2019 | Marvel    |
| Poe Dameron                        | 31     | 2016-2018 | Marvel    |
| Darth Vader: Dark Lord of the Sith | 25     | 2017-2018 | Marvel    |
| Star Wars Adventures               | 32     | 2017-2020 | IDW       |


|||

bla bla bla

|||
-----------------------
| a very    | ccc     |
| long text |----------
|           | 45      |
=======================
| text2     | 450     |
=======================
|||

First table is for classic format (single line data) with label and foot note which is detected because there is no last line in the table.

Last table illustrate multiline, cell merging and higlighting another line than the header.