emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* org table proposal: merge and split cells in org-tables
@ 2022-10-29 16:53 Uwe Brauer
  2022-10-30  3:54 ` Ihor Radchenko
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Uwe Brauer @ 2022-10-29 16:53 UTC (permalink / raw)
  To: emacs-orgmode


Hi

This subject is brought up regularly. 

In a conversation with Ihor Radchenko it was considered as being helpful
to provide a table in which cells are merged and split.

Here is one

+--------+-------------------------------------------------+
| Region |                      Sales                      |
|        +-------------+-----------+-----------+-----------+
|        |      Q1     |    Q2     |    Q3     |    Q4     |
|        +-------+-----+-----+-----+-----+-----+-----+-----+
|        | foo   | bar | foo | bar | foo | bar | foo | bar |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+
| North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+
| South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
+--------+-------+-----+-----+-----+-----+-----+-----+-----+

Or better




------------------------------------------------------------
| Region |                      Sales                      |
|        ---------------------------------------------------
|        |      Q1     |    Q2     |    Q3     |    Q4     |
|        ---------------------------------------------------
|        | foo   | bar | foo | bar | foo | bar | foo | bar |
------------------------------------------------------------
| North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
------------------------------------------------------------
| South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
------------------------------------------------------------





-- 
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/



^ permalink raw reply	[flat|nested] 15+ messages in thread

• * Re: org table proposal: merge and split cells in org-tables
    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
                     ` (2 subsequent siblings)
    3 siblings, 1 reply; 15+ messages in thread
  From: Ihor Radchenko @ 2022-10-30  3:54 UTC (permalink / raw)
    To: Uwe Brauer; +Cc: emacs-orgmode
  
  Uwe Brauer <oub@mat.ucm.es> writes:
  
  > In a conversation with Ihor Radchenko it was considered as being helpful
  > to provide a table in which cells are merged and split.
  
  We should consider this idea seriously as this and related features are
  being requested frequently in the community. I recall the following
  contexts:
  
  - Support merging cells when exporting to LaTeX tables
  - Text filling inside tables
  
  > Here is one
  >
  > +--------+-------------------------------------------------+
  > | Region |                      Sales                      |
  > |        +-------------+-----------+-----------+-----------+
  > |        |      Q1     |    Q2     |    Q3     |    Q4     |
  > |        +-------+-----+-----+-----+-----+-----+-----+-----+
  > |        | foo   | bar | foo | bar | foo | bar | foo | bar |
  > +--------+-------+-----+-----+-----+-----+-----+-----+-----+
  > | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
  > +--------+-------+-----+-----+-----+-----+-----+-----+-----+
  > | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
  > +--------+-------+-----+-----+-----+-----+-----+-----+-----+
  
  This essentially suggests supporting table.el syntax natively. Or maybe
  extending it by mixing with native Org tables.
  
  In terms of syntax, adding cell boundary support might be simply a
  question of allowing +----+ in Org tables. It will not break anything as
  we already parse +-----+ as table.el tables.
  
  At lower level of org-element representation, we do not need to change
  much either. table-row elements are already not tied to a fixed number
  of cells in every row. And we may extend table-row 'rule type to define
  the "+----+   +   +---+--+" cell boundaries.
  
  However, in order to support merging cells, one needs to rework Org in a
  number of places. At least:
  
  1. org-element parser and interpreter
  2. org-table.el in its totality
  3. export backends
  4. table formulas; in particular, cell references
  5. update syntax document
  
  > Or better
  
  > ------------------------------------------------------------
  > | Region |                      Sales                      |
  > |        ---------------------------------------------------
  > |        |      Q1     |    Q2     |    Q3     |    Q4     |
  > |        ---------------------------------------------------
  > |        | foo   | bar | foo | bar | foo | bar | foo | bar |
  > ------------------------------------------------------------
  > | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
  > ------------------------------------------------------------
  > | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
  > ------------------------------------------------------------
  
  This will clash with horizontal-rule syntax. Not acceptable. Also,
  parsing this kind of table will be significantly harder programatically.
  
  -- 
  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>
  
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• • * Re: org table proposal: merge and split cells in org-tables
      2022-10-30  3:54 ` Ihor Radchenko
    @ 2022-10-30  7:22   ` Uwe Brauer
      0 siblings, 0 replies; 15+ messages in thread
    From: Uwe Brauer @ 2022-10-30  7:22 UTC (permalink / raw)
      To: Ihor Radchenko; +Cc: Uwe Brauer, emacs-orgmode
    
    [-- Attachment #1: Type: text/plain, Size: 3741 bytes --]
    
    >>> "IR" == Ihor Radchenko <yantar92@posteo.net> writes:
    
    > Uwe Brauer <oub@mat.ucm.es> writes:
    >> In a conversation with Ihor Radchenko it was considered as being helpful
    >> to provide a table in which cells are merged and split.
    
    > We should consider this idea seriously as this and related features are
    > being requested frequently in the community. I recall the following
    > contexts:
    
    > - Support merging cells when exporting to LaTeX tables
    > - Text filling inside tables
    
    I would suggest that filling, might be the point to start, since this
    the lack of this feature is one of the inconvenience of org-tables.
    
    I am sometimes running org-table-wrap 
    found in 
    https://github.com/analyticd/org-table-wrap-functions.git 
    
    It is nice but takes a long long time to finish.
    
    
    >> Here is one
    >> 
    >> +--------+-------------------------------------------------+
    >> | Region |                      Sales                      |
    >> |        +-------------+-----------+-----------+-----------+
    >> |        |      Q1     |    Q2     |    Q3     |    Q4     |
    >> |        +-------+-----+-----+-----+-----+-----+-----+-----+
    >> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
    >> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
    >> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
    >> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
    >> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
    >> +--------+-------+-----+-----+-----+-----+-----+-----+-----+
    
    > This essentially suggests supporting table.el syntax natively. Or maybe
    > extending it by mixing with native Org tables.
    
    > In terms of syntax, adding cell boundary support might be simply a
    > question of allowing +----+ in Org tables. It will not break anything as
    > we already parse +-----+ as table.el tables.
    
    > At lower level of org-element representation, we do not need to change
    > much either. table-row elements are already not tied to a fixed number
    > of cells in every row. And we may extend table-row 'rule type to define
    > the "+----+   +   +---+--+" cell boundaries.
    
    > However, in order to support merging cells, one needs to rework Org in a
    > number of places. At least:
    
    > 1. org-element parser and interpreter
    > 2. org-table.el in its totality
    > 3. export backends
    > 4. table formulas; in particular, cell references
    > 5. update syntax document
    
    Or would leave 4 and 5 out for the moment, since it sounds like a headache
    >> Or better
    
    >> ------------------------------------------------------------
    >> | Region |                      Sales                      |
    >> |        ---------------------------------------------------
    >> |        |      Q1     |    Q2     |    Q3     |    Q4     |
    >> |        ---------------------------------------------------
    >> |        | foo   | bar | foo | bar | foo | bar | foo | bar |
    >> ------------------------------------------------------------
    >> | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
    >> ------------------------------------------------------------
    >> | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
    >> ------------------------------------------------------------
    
    > This will clash with horizontal-rule syntax. Not acceptable. Also,
    > parsing this kind of table will be significantly harder programatically.
    
    
    Ok.
    
    
    -- 
    Warning: Content may be disturbing to some audiences
    I strongly condemn Putin's war of aggression against the Ukraine.
    I support to deliver weapons to Ukraine's military. 
    I support the ban of Russia from SWIFT.
    I support the EU membership of the Ukraine. 
    https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
    
    [-- Attachment #2: smime.p7s --]
    [-- Type: application/pkcs7-signature, Size: 5673 bytes --]
    
    ^ permalink raw reply	[flat|nested] 15+ messages in thread

• * Re: org table proposal: merge and split cells in org-tables
    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  9:13 ` Jean Louis
    2022-10-30  9:25   ` Ihor Radchenko
    2022-10-30  9:13 ` Timothy
    2022-11-04  7:38 ` Max Nikulin
    3 siblings, 1 reply; 15+ messages in thread
  From: Jean Louis @ 2022-10-30  9:13 UTC (permalink / raw)
    To: emacs-orgmode
  
  To solve that problem personally, I use Asciidoctor, see how it is
  done there:
  
  Example 76. Table with formatted, aligned and merged cells:
  https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format
  
  Org has Babel, for purposes of HTML output, Org file could use Bable
  to get HTML return from Babel containing Asciidoc and embed it in Org
  HTML.
  
  That solution is definitely not general solution, it may be personal one.
  
  -- 
  Jean
  
  Take action in Free Software Foundation campaigns:
  https://www.fsf.org/campaigns
  
  In support of Richard M. Stallman
  https://stallmansupport.org/
  
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• • * Re: org table proposal: merge and split cells in org-tables
      2022-10-30  9:13 ` Jean Louis
    @ 2022-10-30  9:25   ` Ihor Radchenko
      2022-10-31  5:56     ` Jean Louis
      0 siblings, 1 reply; 15+ messages in thread
    From: Ihor Radchenko @ 2022-10-30  9:25 UTC (permalink / raw)
      To: Jean Louis; +Cc: emacs-orgmode
    
    Jean Louis <bugs@gnu.support> writes:
    
    > To solve that problem personally, I use Asciidoctor, see how it is
    > done there:
    >
    > Example 76. Table with formatted, aligned and merged cells:
    > https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format
    
    I am sorry, but this looks unreadable. I would avoid re-using such
    syntax ideas.
    
    > Org has Babel, for purposes of HTML output, Org file could use Bable
    > to get HTML return from Babel containing Asciidoc and embed it in Org
    > HTML.
    
    Sure. And we do use pretty much the same approach to export table.el
    tables, which are supported by Org natively (up to a limit). But this
    proposal is about bringing cell merging into native Org tables.
    
    -- 
    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>
    
    
    ^ permalink raw reply	[flat|nested] 15+ messages in thread

  • • * Re: org table proposal: merge and split cells in org-tables
        2022-10-30  9:25   ` Ihor Radchenko
      @ 2022-10-31  5:56     ` Jean Louis
        2022-10-31  8:50       ` Ihor Radchenko
        0 siblings, 1 reply; 15+ messages in thread
      From: Jean Louis @ 2022-10-31  5:56 UTC (permalink / raw)
        To: Ihor Radchenko; +Cc: emacs-orgmode
      
      * Ihor Radchenko <yantar92@posteo.net> [2022-10-30 12:27]:
      > Jean Louis <bugs@gnu.support> writes:
      > 
      > > To solve that problem personally, I use Asciidoctor, see how it is
      > > done there:
      > >
      > > Example 76. Table with formatted, aligned and merged cells:
      > > https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#ex-cell-format
      > 
      > 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.
      
      Org tables are nothing harder or simpler than tables in other
      lightweight markup languages.
      
      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". That is why I
      said, one has to inspect the context and look for definitions.
      
      [cols="e,m,^,>s",width="25%"]
      |===
      |1 >s|2 |3 |4
      ^|5 2.2+^.^|6 .3+<.>m|7
      ^|8
      |9 2+>|10nnp
      |===
      
      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.
      
      `m' after first comma says that text of that column shall be in
      monospaced font, which I find very useful for table columns.
      
      `^' signifies centered column in `[cols="e,m,^,>s",width="25%"]'
      
      and `>s' means right centered, bold column;
      
      `width=25%' tells about table width.
      
      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.
      
      And in that extreme example then we have following lines:
      
      |===
      for begin of the table
      
      |1 >s|2 |3 |4
      the second `|' has attribute `>s' or complete `>s|' which specifically
      formats number "2" to be bold and right centered. 
      
      ^|5 2.2+^.^|6 .3+<.>m|7
      
      It is good to read about span factor:
      https://docs.asciidoctor.org/asciidoc/latest/tables/span-cells/
      
      2.2+^.^|6 -- talks about spanning 2 columns, two rows and its alignment.
      
      while .3+<.>m|7 talks about spanning 3 rows, that is where number 7 comes.
      
      |===
      for end of the table
      
      It is surely good to try to make visual tables with merged cells as
      general Org functionality. 
      
      It is also very useful to look how other people implement various
      functionalities and try to see if such could be useful in Org as well.
      
      But when you don't have the functionality yet, due to the Babel and
      inclusion of other files, one may achieve the final result by
      including HTML directly, or by using external tools.
      
      Org is integrator of almost anything. Babel and integration of, to the
      Org external tools, allows user to include almost any value or results
      from outside the file.
      
      I do agree that it is "hard" to understand at once what it is, but it
      is a solution for reason that Org allows external tools' values to be
      included in the Org file. In this case it is the HTML output from
      Asciidoctor. 
      
      This elaboration is for opening the mind of Org user, it is to
      understand that extensibility, due to Babel and inclusion of any
      external tools has no limits at any point of time.
      
      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%\"]
      |===
      |1 >s|2 |3 |4
      ^|5 2.2+^.^|6 .3+<.>m|7
      ^|8
      |9 2+>|10nnp
      |===
      " | asciidoctor -e -o - -
      
      #+END_SRC
      
      #+RESULTS:
      <table class="tableblock frame-all grid-all" style="width: 25%;">
      <colgroup>
      <col style="width: 25%;">
      <col style="width: 25%;">
      <col style="width: 25%;">
      <col style="width: 25%;">
      </colgroup>
      <tbody>
      <tr>
      <td class="tableblock halign-left valign-top"><p class="tableblock"><em>1</em></p></td>
      <td class="tableblock halign-right valign-top"><p class="tableblock"><strong>2</strong></p></td>
      <td class="tableblock halign-center valign-top"><p class="tableblock">3</p></td>
      <td class="tableblock halign-right valign-top"><p class="tableblock"><strong>4</strong></p></td>
      </tr>
      <tr>
      <td class="tableblock halign-center valign-top"><p class="tableblock"><em>5</em></p></td>
      <td class="tableblock halign-center valign-middle" colspan="2" rowspan="2"><p class="tableblock"><code>6</code></p></td>
      <td class="tableblock halign-left valign-bottom" rowspan="3"><p class="tableblock"><code>7</code></p></td>
      </tr>
      <tr>
      <td class="tableblock halign-center valign-top"><p class="tableblock"><em>8</em></p></td>
      </tr>
      <tr>
      <td class="tableblock halign-left valign-top"><p class="tableblock"><em>9</em></p></td>
      <td class="tableblock halign-right valign-top" colspan="2"><p class="tableblock"><code>10nnp</code></p></td>
      </tr>
      </tbody>
      </table>
      
      -- 
      Jean
      
      Take action in Free Software Foundation campaigns:
      https://www.fsf.org/campaigns
      
      In support of Richard M. Stallman
      https://stallmansupport.org/
      
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • • * Re: org table proposal: merge and split cells in org-tables
          2022-10-31  5:56     ` Jean Louis
        @ 2022-10-31  8:50       ` Ihor Radchenko
          0 siblings, 0 replies; 15+ messages in thread
        From: Ihor Radchenko @ 2022-10-31  8:50 UTC (permalink / raw)
          To: Jean Louis; +Cc: emacs-orgmode
        
        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>
        
        
        ^ permalink raw reply	[flat|nested] 15+ messages in thread

• * Re: org table proposal: merge and split cells in org-tables
    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  9:13 ` Jean Louis
  @ 2022-10-30  9:13 ` Timothy
    2022-11-04  7:38 ` Max Nikulin
    3 siblings, 0 replies; 15+ messages in thread
  From: Timothy @ 2022-10-30  9:13 UTC (permalink / raw)
    To: Uwe Brauer; +Cc: emacs-orgmode
  
  [-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
  
  Hi Uwe and Ihor,
  
  > This subject is brought up regularly.
  >
  > In a conversation with Ihor Radchenko it was considered as being helpful
  > to provide a table in which cells are merged and split.
  
  This reminds me of a proposal I made in 2020 on this very matter:
  <https://list.orgmode.org/87k0v361x9.fsf@gmail.com>.
  
  I won’t re-hash it here, but if I am to apply that proposed syntax to the
  example table it would look like this:
  
  ┌────
  │ |----    ||||||||               Sales                      |
  │ | Region |-------------+-----------+-----------+-----------|
  │ |        ||     Q1     ||   Q2     ||   Q3     ||   Q4     |
  │ |        | foo   | bar | foo | bar | foo | bar | foo | bar |
  │ |--------+-------+-----+-----+-----+-----+-----+-----+-----|
  │ | North  | 350   |  46 | 253 |  34 | 234 |  42 | 382 |  68 |
  │ | South  | 462   |  84 | 511 |  78 | 435 |  45 | 534 |  89 |
  └────
  
  All the best,
  Timothy
  
  -- 
  Timothy (‘tecosaur’/‘TEC’), 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/tec>.
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• * Re: org table proposal: merge and split cells in org-tables
    2022-10-29 16:53 org table proposal: merge and split cells in org-tables Uwe Brauer
                     ` (2 preceding siblings ...)
    2022-10-30  9:13 ` Timothy
  @ 2022-11-04  7:38 ` Max Nikulin
    2022-11-05  5:44   ` Ihor Radchenko
    3 siblings, 1 reply; 15+ messages in thread
  From: Max Nikulin @ 2022-11-04  7:38 UTC (permalink / raw)
    To: emacs-orgmode
  
  I believe that tables in Org are already too complicated due to the 
  spreadsheet feature. However those who are brave enough to add cells 
  spanning columns and rows may take some inspiration from 
  reStructuredText, in particular horizontal lines marked by "+===+===+"
  
  https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#tables
  > Grid tables are described with a visual grid made up of the characters "-", "=", "|", and "+". The hyphen ("-") is used for horizontal lines (row separators). The equals sign ("=") may be used to separate optional header rows from the table body (not supported by the Emacs table mode). The vertical bar ("|") is used for vertical lines (column separators). The plus sign ("+") is used for intersections of horizontal and vertical lines. Example:
  > 
  > +------------------------+------------+----------+----------+
  > | Header row, column 1   | Header 2   | Header 3 | Header 4 |
  > | (header rows optional) |            |          |          |
  > +========================+============+==========+==========+
  > | body row 1, column 1   | column 2   | column 3 | column 4 |
  > +------------------------+------------+----------+----------+
  > | body row 2             | Cells may span columns.          |
  > +------------------------+------------+---------------------+
  > | body row 3             | Cells may  | - Table cells       |
  > +------------------------+ span rows. | - contain           |
  > | body row 4             |            | - body elements.    |
  > +------------------------+------------+---------------------+
  
  RST tables have a feature making hard to implement autoalignment. If 
  come cell have "|" with offset in respect to lines above and below then
  it is a regular character.
  
  Besides "grid" tables there are "simple" tables without vertical lines.
  
  Perhaps it better to implement new table features as src blocks for some 
  new language and a dedicated Emacs mode. In the case of success such 
  proof of concept may be merged into Org core.
  
  My impression is that Org tables quickly become hardly maintainable when 
  their complexity is above some quite low threshold. E.g. automatic 
  recalculation works only for first #+tblfm: line. It requires some 
  efforts to figure out association of particular formula with cell spans.
  
  Merge cells add more complexity to formula ranges. Some protocol should 
  be defined to allow source blocks to generate extended cells.
  
  
  
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• • * Re: org table proposal: merge and split cells in org-tables
      2022-11-04  7:38 ` Max Nikulin
    @ 2022-11-05  5:44   ` Ihor Radchenko
      0 siblings, 0 replies; 15+ messages in thread
    From: Ihor Radchenko @ 2022-11-05  5:44 UTC (permalink / raw)
      To: Max Nikulin; +Cc: emacs-orgmode
    
    Max Nikulin <manikulin@gmail.com> writes:
    
    > I believe that tables in Org are already too complicated due to the 
    > spreadsheet feature.
    
    They are, but merging cells is widely demanded. If we can come up with
    some reasonable extension of Org syntax, it will be a benefit for the
    whole Org community.
    
    > However those who are brave enough to add cells 
    > spanning columns and rows may take some inspiration from 
    > reStructuredText, in particular horizontal lines marked by "+===+===+"
    
    These are the table.el Emacs tables we already support (partially).
    Uwe's proposal is supporting table.el more fully, but it will be
    incompatible (if taken as is) with the current Org table syntax.
    
    We can learn from the design, but cannot just blindly re-use it.
    
    > Besides "grid" tables there are "simple" tables without vertical lines.
    
    That's similar to the ASCIIDoctor tables as I read it in the link.
    I do not think that it is a good option to move away from the visual
    table style employed in Org.
    
    > Perhaps it better to implement new table features as src blocks for some 
    > new language and a dedicated Emacs mode. In the case of success such 
    > proof of concept may be merged into Org core.
    
    That's what our table.el integration does. But it is not enough.
    
    Some features are only present in native Org tables and some features
    are only present in table.el tables. We will end up needing to extend
    either of the table syntaxes to obtain full Org table functionality.
    
    Then, it is better to extend native Org tables rather than replacing the
    existing table syntax with third party.
    
    > My impression is that Org tables quickly become hardly maintainable when 
    > their complexity is above some quite low threshold. E.g. automatic 
    > recalculation works only for first #+tblfm: line. It requires some 
    > efforts to figure out association of particular formula with cell spans.
    
    I'd say that the problem is mostly with org-table.el which heavily
    relies on direct regexp matching. If we generalize things using parser,
    it should become easier to maintain even with merge cells.
    
    > Merge cells add more complexity to formula ranges. Some protocol should 
    > be defined to allow source blocks to generate extended cells.
    
    Agree. And such protocol will improve maintainability even if
    implemented without extended cells. Either way, it is a good idea to
    refactor org-table.el
    
    -- 
    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>
    
    
    ^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: org table proposal: merge and split cells in org-tables
@ 2022-10-30  8:23 Mati
  2022-10-30  8:35 ` Ihor Radchenko
  0 siblings, 1 reply; 15+ messages in thread
From: Mati @ 2022-10-30  8:23 UTC (permalink / raw)
  To: emacs-orgmode

I don't know is this helpful, but on reddit some people mentioned that 
cell-mode is very promising for tables. Maybe it can ease table 
development. I'm not into programming at all so I can't evaluate.



^ permalink raw reply	[flat|nested] 15+ messages in thread

• * Re: org table proposal: merge and split cells in org-tables
    2022-10-30  8:23 Mati
  @ 2022-10-30  8:35 ` Ihor Radchenko
    2022-10-30  8:47   ` Timothy
    0 siblings, 1 reply; 15+ messages in thread
  From: Ihor Radchenko @ 2022-10-30  8:35 UTC (permalink / raw)
    To: Mati; +Cc: emacs-orgmode
  
  Mati <mati@electrum-bikes.pl> writes:
  
  > I don't know is this helpful, but on reddit some people mentioned that 
  > cell-mode is very promising for tables. Maybe it can ease table 
  > development. I'm not into programming at all so I can't evaluate.
  
  While cell-mode (https://gitlab.com/dto/cell-mode) is a nice idea, but
  it is not plain text. I doubt that we can get much inspiration from
  there.
  
  -- 
  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>
  
  
  ^ permalink raw reply	[flat|nested] 15+ messages in thread

• • * Re: org table proposal: merge and split cells in org-tables
      2022-10-30  8:35 ` Ihor Radchenko
    @ 2022-10-30  8:47   ` Timothy
      2022-10-30  8:56     ` Ihor Radchenko
      0 siblings, 1 reply; 15+ messages in thread
    From: Timothy @ 2022-10-30  8:47 UTC (permalink / raw)
      To: Ihor Radchenko; +Cc: Mati, emacs-orgmode
    
    [-- Attachment #1: Type: text/plain, Size: 558 bytes --]
    
    Hi Ihor,
    
    > While cell-mode (<https://gitlab.com/dto/cell-mode>) is a nice idea, but
    > it is not plain text. I doubt that we can get much inspiration from
    > there.
    
    This reminds me that ages ago I made a proposal about multi-row/column cells, it
    might be worth reviving that at some point?
    
    All the best,
    Timothy
    
    -- 
    Timothy (‘tecosaur’/‘TEC’), 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/tec>.
    
    ^ permalink raw reply	[flat|nested] 15+ messages in thread

  • • * Re: org table proposal: merge and split cells in org-tables
        2022-10-30  8:47   ` Timothy
      @ 2022-10-30  8:56     ` Ihor Radchenko
        2022-10-30  9:08       ` Timothy
        0 siblings, 1 reply; 15+ messages in thread
      From: Ihor Radchenko @ 2022-10-30  8:56 UTC (permalink / raw)
        To: Timothy; +Cc: Mati, emacs-orgmode
      
      Timothy <orgmode@tec.tecosaur.net> writes:
      
      > This reminds me that ages ago I made a proposal about multi-row/column cells, it
      > might be worth reviving that at some point?
      
      https://orgmode.org/list/878rkyarvm.fsf@localhost, which is the
      exact discussion herein.
      
      -- 
      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>
      
      
      ^ permalink raw reply	[flat|nested] 15+ messages in thread

    • • * Re: org table proposal: merge and split cells in org-tables
          2022-10-30  8:56     ` Ihor Radchenko
        @ 2022-10-30  9:08       ` Timothy
          0 siblings, 0 replies; 15+ messages in thread
        From: Timothy @ 2022-10-30  9:08 UTC (permalink / raw)
          To: Ihor Radchenko; +Cc: Timothy, Mati, emacs-orgmode
        
        [-- Attachment #1: Type: text/plain, Size: 654 bytes --]
        
        Hi Ihor,
        
        > Timothy <orgmode@tec.tecosaur.net> writes:
        >
        >> This reminds me that ages ago I made a proposal about multi-row/column cells, it
        >> might be worth reviving that at some point?
        >
        > <https://orgmode.org/list/878rkyarvm.fsf@localhost>, which is the
        > exact discussion herein.
        
        Ah, I’ll move there. I suppose this is a downside to taking a LIFO approach to
        my inbox 😅.
        
        All the best,
        Timothy
        
        -- 
        Timothy (‘tecosaur’/‘TEC’), 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/tec>.
        
        ^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2022-11-05  5:46 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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).