[spec] Possible Tables Syntax

[John Cowan]

"User" editors usually don't generate HT when the user presses the TAB key.

On Sat, Jan 2, 2021 at 4:35 PM <nothien at uber.space> wrote:

> There is a new discussion about table formats under the [users]
> category, but I've thought of one possibility that roughly matches the
> look of tables but keeps each cell on its own line, and I wanted to see
> what others think of it in a more [spec]-relevant area.  Essentially,
> indentation (tabs) is used to represent which column a cell is in.
> Wrapping cell text is possible, so I hesitate to put it in a
> preformatted block, but it's the best way to show that it's an
> unfamiliar format.
>
> > +--------------------------------+-------+
> > | Food                           | Price |
> > +--------------------------------+-------+
> > | Eggs                           | $2    |
> > | Eggs and spam                  | $4    |
> > | Eggs, spam, eggs and spam      | $8    |
> > | Spam spam baked beans and spam | $8    |
> > | Just spam                      | $2    |
> > +--------------------------------+-------+
>
> ```table
> Food
>         Price
> Eggs
>         $2
> Eggs and spam
>         $4
> Eggs, spam, eggs and spam
>         $8
> Spam spam baked beans and spam
>         $8
> Just spam
>         $2
> ```
>
> It needs to be tried out a lot more to see how flexible it really is,
> but it looks promising to me.  It looks quite structured visually, and
> should be very easy to parse programmatically as well.  Of course, it
> would be more difficult to visualize with more columns and longer cell
> texts, but it's (much) better than nothing.
>
> Each cell is on a different block, and the general expectation is that
> the indentation level increases by one horizontal tab for every next
> column, then resetting to no indentation for the next row.  We could
> probably give specific interpretation to other possible things that
> happen (e.g. 'jumps' in indentation level which are not resetting to
> rows), or we could outright ban them, but I would prefer the former (as
> then there is no room for extension).
>
> I know that we're looking to finalize the spec, and that this will
> probably not make it in (even if it gets accepted).  Tables are quite
> uncommon, after all, so I don't there would be a big enough push to
> warrant making it official.  But I argue that tables are a very
> difficult thing to format to satisfy both humans and computers, so at
> the minimum we would add this (or any agreed-upon table format) to the
> best practices document.  The best-case scenario to me is that it gets
> added to the gemtext spec as an optional type to parse, similar to how
> one would parse other preformatted blocks (but with more state to keep
> track of).
>
> What do you think?
>
> ~aravk | ~nothien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailing-list-archive.gemi.dev/www/attachments/20210102/80f9e9d3/attachment-0001.htm>