line breaking in grid table cells

line breaking in grid table cells

[John MacFarlane]

I'd like to get feedback about a possible change in the
way pandoc formats grid tables (used in markdown, rst, muse,
and haddock).

Currently column widths are strictly enforced, so if a table
cell contains a long verbatim code snippet or a long URL, it
will be broken up so that the contents fit into the cell.

An alternate behavior, suggested in
https://github.com/jgm/pandoc/issues/4572,
would be to let the cell expand past its prescribed width
to accommodate the "unbreakable" content.

PR #4572 suggests making this available as an option, but
I'm thinking maybe it should just be the default behavior,
and I wonder if people could comment on that.  We could emit
a warning when cell widths are expanded to fit content.

Re: line breaking in grid table cells

[Anton Sharonov]

On Wed, 9 Jun 2021 at 16:44, John MacFarlane <jgm-TVLZxgkOlNX2fBVCVOL8/A@public.gmane.org> wrote:
>
>
> I'd like to get feedback about a possible change in the
> way pandoc formats grid tables (used in markdown, rst, muse,
> and haddock).
>
> Currently column widths are strictly enforced, so if a table
> cell contains a long verbatim code snippet or a long URL, it
> will be broken up so that the contents fit into the cell.
>
> An alternate behavior, suggested in
> https://github.com/jgm/pandoc/issues/4572,
> would be to let the cell expand past its prescribed width
> to accommodate the "unbreakable" content.
>
> PR #4572 suggests making this available as an option, but
> I'm thinking maybe it should just be the default behavior,
> and I wonder if people could comment on that.  We could emit
> a warning when cell widths are expanded to fit content.


Disclaimer: everything below is just humble opinion of one person.

Said that, my vote goes as +1 to "make it an option".

Arguments:

Like it is now - breaking the verbatim content looks ugly of course.
But expanding column sizes potentially leads to very wide total table
width, hard to read and maintain - which in my opinion is even more
ugly. So +1 for to make it an option - at  least allow to keep current
status quo.

And since you are asking:

Another idea to deal with this kind of problem ("unbreakable content"
on inconvenient places like table cells) would be to create new syntax
extension lets call it for the moment "AST segment replacement",
controlled by an  option (this "AST segment replacement" was described
by my post few weeks ago - in short it can be something like a
footnote, where "unbreakable content" can be defined outside the table
and referenced from the table using "replacement pointer". Abstract
syntax tree segment can be "transplanted" from segment definition
point - expressed as kind of "footnote" - to that target position
inside the table cell. That way "unbreakable content" can be replaced
by some rather short generated identifier used as "replacement
pointer", keeping the table column slim and good observable,
outsourcing definition of long "inconvenient" segments to another
places in the document, not disturbed by any table formatting
concerns. Right now draft implementation of that idea exists in form
of lua filter, utilizing self invented flavor of possible syntax.
Having support for folding "unbreakable content" in that way from
pandoc core as an optional behavior would be absolutely cool)

Thanks and with best regards, Anton

>
> --
> You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/m2o8cf9jy7.fsf%40MacBook-Air.hsd1.ca.comcast.net.

Re: line breaking in grid table cells

[John MacFarlane]

Anton Sharonov <anton.sharonov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Said that, my vote goes as +1 to "make it an option".
>
> Arguments:
>
> Like it is now - breaking the verbatim content looks ugly of course.
> But expanding column sizes potentially leads to very wide total table
> width, hard to read and maintain - which in my opinion is even more
> ugly. So +1 for to make it an option - at  least allow to keep current
> status quo.

Agreed that the widened cells would be ugly.  But, breaking the
URLs or verbatim content changes the meaning and makes them
unusable.  Given this choice, wouldn't everyone prefer "ugly"?
Especially if they're given a warning which allows them to
make adjustments to the table to make it look nicer?

Simplicity is better in general, so I lean towards not making
it an option until I see a good reason why people might prefer
beautiful+broken to ugly+working.