From: Ihor Radchenko <yantar92@posteo.net>
To: Jean Louis <bugs@gnu.support>
Cc: emacs-orgmode@gnu.org
Subject: Re: org table proposal: merge and split cells in org-tables
Date: Mon, 31 Oct 2022 08:50:02 +0000 [thread overview]
Message-ID: <874jvkjs1x.fsf@localhost> (raw)
In-Reply-To: <Y19jilSK8sv16dfh@protected.localdomain>
Jean Louis <bugs@gnu.support> writes:
>> I am sorry, but this looks unreadable. I would avoid re-using such
>> syntax ideas.
>
> You have got an extreme reference on what can be done. Other people
> and other projects have faced same issues as you are facing in Org
> mode, and have resolved it. To understand anything one cannot just
> read simple reference, but better understand the surrounding meanings,
> the context.
Indeed. I was expecting a link describing the concepts. What your
provided was not very helpful.
> Org tables are nothing harder or simpler than tables in other
> lightweight markup languages.
Somewhat harder. Somewhat simpler. We do not support some features
ASCIIDOC supports. ASCIIDOC does not support spreadsheet features of Org
tables. That's why we need context. We cannot blindly copy from
ASCIIDOC.
> What appears "unreadable" to you is readable to other
> person. In fact, there is no single char in the extreme example of
> Asciidoc table below that you can't read. The meaning of
> "unreadable" is most probably "not understandable".
Sure. But we have different proposals in the previous emails. Compared
to the existing proposals, this looks unreadable. (which does not mean
that it is worse - maybe ASCIIDOC has more flexibility; but less
readable compared to other proposals for sure).
> In fact, looking into functionality of other lightweigh markup
> languages may only be helpful for Org development.
>
> For [cols="e,m,^p,>s",width="25%"] look here:
> https://docs.asciidoctor.org/asciidoc/latest/tables/format-column-content/
> Thus `e' before first comma, means emphasized (I guess) and in fact on
> the original demonstration one can see that first column is
> emphasized.
>
> The fact that one may "describe" column's font style in Asciidoc(tor) could
> be adopted as well in Org mode.
Thanks for the link! This specific link is out of scope of this
discussion (I do not think that we need to specify formatting for the
whole column), but another link nearby looks more useful:
https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/
> I would like it if Org mode could provide such functionality for
> tables, to specify various attributes for columns. It does provide,
> though I am not sure if it can provide so many.
Please open a discussion about other attributes in a separate thread.
Let's stay on the topic of merging cells and columns in this thread.
It is already difficult enough.
> It is good to read about span factor:
> https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/
I think a slightly more clear example is (from the link; they also
provide how html export of the below table looks like)
|===
|Column 1, header row |Column 2, header row |Column 3, header row |Column 4, header row
|Cell in column 1, row 2
2.3+|This cell spans columns 2 and 3 and rows 2, 3, and 4 because its specifier contains a span of `2.3+`
|Cell in column 4, row 2
|Cell in column 1, row 3
|Cell in column 4, row 3
|Cell in column 1, row 4
|Cell in column 4, row 4
|===
I can see the idea here. For columns, it is similar to Timothy's ||||,
but uses a number. For rows, I'm afraid that we cannot use the same
approach because of conceptually different table structure.
Takeaway:
TEC's:
|---- |||||||| Sales |
can become
|---- 2+| Sales |
> One need not wait for that feature X to be implemented in Org, while
> there is plenty of available options to reach the purpose of feature
> X.
>
> #+BEGIN_SRC shell :results raw
> echo "
> [cols=\"e,m,^,>s\",width=\"25%\"]
> ...
> |===
> " | asciidoctor -e -o - -
>
> #+END_SRC
Indeed. But it is not what we are discussing here.
We are discussing concrete ideas to implement feature X. X being merged
table cells. Let's not sidestep into other topics.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2022-10-31 8:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-29 16:53 org table proposal: merge and split cells in org-tables Uwe Brauer
2022-10-30 3:54 ` Ihor Radchenko
2022-10-30 7:22 ` Uwe Brauer
2022-10-30 9:13 ` Jean Louis
2022-10-30 9:25 ` Ihor Radchenko
2022-10-31 5:56 ` Jean Louis
2022-10-31 8:50 ` Ihor Radchenko [this message]
2022-10-30 9:13 ` Timothy
2022-11-04 7:38 ` Max Nikulin
2022-11-05 5:44 ` Ihor Radchenko
-- strict thread matches above, loose matches on Subject: below --
2022-10-30 8:23 Mati
2022-10-30 8:35 ` Ihor Radchenko
2022-10-30 8:47 ` Timothy
2022-10-30 8:56 ` Ihor Radchenko
2022-10-30 9:08 ` Timothy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jvkjs1x.fsf@localhost \
--to=yantar92@posteo.net \
--cc=bugs@gnu.support \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).