The shrink option via <2> , hide columns and problems

[ouboub]

+STARTUP: shrink

It is convenient for large tables with a lot of column to use headers or rows like this

| <0> | <0> | <0> | <2> |   |  |

Then putting the option

#+STARTUP: shrink

«hides» these columns by shrinking them. There are two issues/feature-requests/bugs

1. Could shrinking be translated to hiding

   #+Name: hide-no-formula
   | <0>   | <0>      |   <0> |    <0> |        |        |
   | Smith | Number   | Value | Value2 | Value3 | Value4 |
   |-------+----------+-------+--------+--------+--------|
   |       | posición |   242 |     51 |     15 |    202 |
   |       | rango    |   329 |    329 |    329 |    329 |
   |       | peso     |    88 |    279 |    315 |    128 |

   currently it is not.

2. If you table with a shrinking row and a FORUMLA is converted the first row gets ignored and the formula are then wrong

   #+Name: hide-with-formula
   | <0>   | <0>      |   <0> |    <0> |        |        |
   | Smith | Number   | Value | Value2 | Value3 | Value4 |
   |-------+----------+-------+--------+--------+--------|
   |       | posición |   242 |     51 |     15 |    202 |
   |       | rango    |   329 |    329 |    329 |    329 |
   |       | peso     |    88 |    279 |    315 |    128 |
   #+TBLFM: @5$3..@5$6=@4+1-@3

BTW, it does not matter whether I put the «shrinking option» in the first row or in any other one

bughide#hide-with-formula.ods bughide#hide-no-formula.ods

[kjambunathan]

Regarding collapsible columns on ODS side ....

Why would you like to shrink the columns?

Unless the recipient of ODS sheet is looking out for hidden columns, it is going to surprise / trip them.

If it is for you own editing convenience, you can always use the UI to toggle the visibility.

If the data is hidden, and if the table you are editing is what pays for your bread, then you want to make sure the columns and data are visible, and your computation is not off the mark. In other words, at some point in time you will have to resort to un-hide the column and the exporter can NOT come to your rescue then.

And if you are going to hide certain columns always, it is best to NOT put them out on the ODS sheet in first place **(I know that you have been asking for commenting / filtering out the columns in the output)**

In other words,

• when you are asking for hidden columns you aren't really asking for commenting out the columns at all
• what advantage does collapsing a column on the ODS side give you ... "I save couple of mouse driven menu operations on the LO side" doesn't seem like good argument to me

If you put forth a strong argument, I can roll out the visible/collapse feature ... It is not hard to do. But I want strong arguments. Mostly, I also want to make sure that when you are asking for X, you are asking for X alone and not Y. X = collapse column here and Y = strip the columns from output.

The cookies line is doing too many things ... and its primary intent is to make editing of Org table within Emacs convenient and easier. Strictly speaking it has nothing to do with how the table column widths should be rendered on ODT/ODS side.

The right way to control the column attributes is through :col-cookies attribute in ATTR_ODT line. See Support for `:col-cookies’ attribute

What you propose ...

#+Name: hide-no-formula
| <0>   | <0>      |   <0> |    <0> |        |        |
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |

What I am likely to go with ...  A ~dot~ in ~:col-cookie` will
collapse that column on output.

#+ATTR_ODT: :col-cookies "| <.>   | <.>      |   <.> |    <.> |        |        |"
#+Name: hide-no-formula
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |

[kjambunathan]

Regarding collapsible columns on ODS side ....

To spot the hidden columns, you need to have a strong eyesight--the visible indication for presence of hidden column is quite feeble and almost imperceptible--and if you are on the wrong side of 40s or worse, you may have to recite the alphabet to identify the alphabetic letters that are getting skipped.

Are you hiding the column to be secretive about your private notes ... Hiding doesn't strip the date from the table and hidden != absent

If I think about it, the arguments are stronger for leaving the columns visible ... or there is something special about the nature of the data which necessitates the request you are making right now ...

[kjambunathan]

BTW, it does not matter whether I put the «shrinking option» in the first row or in any other one

If you put it at the last there won't be any issue.

The cookies row is a formatting row and not a data row.

So, the non-data cookie row doesn't make its way in to the final ODS table.

It means that I have to adjust the row indices (in the formula) to account for the elided cookies row. (Obviously I am making some error in adjusting the row indices ...)

If you put the cookie column at last, the row indices of the data rows won't change at all. So, as a temporary suggestion move the cookie row to the last

Try these ones as temporary measure .... and note that the cookie column is the very last row in the examples below.

#+Name: hide-no-formula
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |
| <0>   | <0>      |   <0> |    <0> |        |        |

#+Name: hide-with-formula
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |
| <0>   | <0>      |   <0> |    <0> |        |        |
#+TBLFM: @4$3..@4$6=@3+1-@2

[kjambunathan]

I happened to see your shrink tables automatically, but individually | emacs-orgmode , you may want to go with one of the suggestions here Fold tables in org mode | Emacs Stackexchange

Make a suggestion to add an #+ATTR_ORG: fold or some such thing ... Ihar has improved the fold infrastructure, and he would be happy to respond if you make your question in terms of fold-ing the table, instead of shrink-ing the table.

[ouboub]

I happened to see your shrink tables automatically, but individually | emacs-orgmode , you may want to go with one of the suggestions here Fold tables in org mode | Emacs Stackexchange

Make a suggestion to add an #+ATTR_ORG: fold or some such thing ... Ihar has improved the fold infrastructure, and he would be happy to respond if you make your question in terms of fold-ing the table, instead of shrink-ing the table.

thanks, that is also very helpful I will look into this right now

[ouboub]

BTW, it does not matter whether I put the «shrinking option» in the first row or in any other one

If you put it at the last there won't be any issue.

The cookies row is a formatting row and not a data row.

So, the non-data cookie row doesn't make its way in to the final ODS table.

It means that I have to adjust the row indices (in the formula) to account for the elided cookies row. (Obviously I am making some error in adjusting the row indices ...)

If you put the cookie column at last, the row indices of the data rows won't change at all. So, as a temporary suggestion move the cookie row to the last

Try these ones as temporary measure .... and note that the cookie column is the very last row in the examples below.

#+Name: hide-no-formula
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |
| <0>   | <0>      |   <0> |    <0> |        |        |

#+Name: hide-with-formula
| Smith | Number   | Value | Value2 | Value3 | Value4 |
|-------+----------+-------+--------+--------+--------|
|       | posición |   242 |     51 |     15 |    202 |
|       | rango    |   329 |    329 |    329 |    329 |
|       | peso     |    88 |    279 |    315 |    128 |
| <0>   | <0>      |   <0> |    <0> |        |        |
#+TBLFM: @4$3..@4$6=@3+1-@2

Ok fair enough, here is the scenario. As I said I am currently preparing a spreadsheet, which will be discussed tomorrow in a videoconference. Originally the spreadsheet had 12 column (that is a reasonable size)

However in order to calculate the value of each column, the best way (that is the way to avoid errors) is to add to each of these 12 column so to speak between 4 and 5 auxiliary columns,

Like this

Just to get an idea

Original table

| name            | research | teaching |
| candidate 1 |          |          |

now

| name       | publication | international projects | eu projects | national projects | result_reseach | result_research_recaled |
| candiate 1 |             |                        |             |                   |                |                         |

So this approach leads to 56 columns, and I don't know any way to display that in an convenient way in ods. So I thought of hiding the additional column in the ods spreadsheet and tomorrow display them on demand.

If you tell me there is another way to do that in a convenient form, I'd love to hear about it

So before proceeding with our discussion. Do you think what I propose is reasonable? …

[ouboub]

I happened to see your shrink tables automatically, but individually | emacs-orgmode , you may want to go with one of the suggestions here Fold tables in org mode | Emacs Stackexchange

Make a suggestion to add an #+ATTR_ORG: fold or some such thing ... Ihar has improved the fold infrastructure, and he would be happy to respond if you make your question in terms of fold-ing the table, instead of shrink-ing the table.

I just tried it out, maybe I miss the point but this code folds the whole table, that is not what I want/need I'd like to fold (or shrink) the columns that I consider as auxiliary columns

[kjambunathan]

The problem with your suggestion is hiding or unhiding is difficult ... as it difficult as opening or closing a door WITHOUT a handy knob

What you need is grouping of columns (or rows) and A CONVENIENT KNOB

Read https://findnerd.com/list/view/Grouping-columns-and-rows-in-Excel-and-Open-Office-Calc/4559/

Grouping/Ungrouping will take effort ...

If you are sure that you will NEVER UNHIDE what is hidden, I can add the feature you request ...

Have you tried unhiding a set of hidden columns ... I found it annoying .. You have to unhide them one by one by dragging a flimsy slider ...

[ouboub]

"k" == kjn @.***> writes:

The problem with your suggestion is hiding or unhiding is difficult ... as it difficult as opening or closing a door WITHOUT a handy knob

Sounds like Houdini job, then.

What you need is grouping of columns (or rows) and A CONVENIENT KNOB

Read https://findnerd.com/list/view/Grouping-columns-and-rows-in-Excel-and-Open-Office-Calc/4559/

Grouping/Ungrouping will take effort ...

If you are sure that you will NEVER UNHIDE what is hidden, I can add the feature you request ...

Have you tried unhiding a set of hidden columns ... I found it annoying .. You have to unhide them one by one by dragging a flimsy slider ...

Well I am not a huge fan of this either. My colleagues tend to use it. Please leave it for the moment.

I have to see how we will deal with it tomorrow.

Maybe the cleanest way would be to split the table in various subtables distributed in different sheets but somehow linked.

That is possible in org mode using orgtbl-aggregate.

But I am not sure whether this is possible in LO, I just posted a corresponding question to that mailing list -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of Ukraine. I support the EU membership of Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[kjambunathan]

Zip file

collapse-some-columns.zip

To get this

do this

Columns that that have a trailing dot in its `:col-cookies' line are
invisible on ODS output.  Specifically, columns 3-4 (= C-D) and
7 (= G) are collapsed / hidden.

#+ATTR_ODT: :col-cookies "|                   |                      |              . |                 . |                |              |                   . |             |"
#+Name: table-with-hidden-columns
| Format            | Fine-grained-control | Initial Effort | Syntax simplicity | Editor Support | Integrations | Ease-of-referencing | Versatility |
|-------------------+----------------------+----------------+-------------------+----------------+--------------+---------------------+-------------|
| Word              |                    2 |              4 |                 4 |              2 |            3 |                   2 |           2 |
| LaTeX             |                    4 |              1 |                 1 |              3 |            2 |                   4 |           3 |
| Org Mode          |                    4 |              2 |               3.5 |              1 |            4 |                   4 |           4 |
| Markdown          |                    1 |              3 |                 3 |              4 |            3 |                   3 |           1 |
| Markdown + Pandoc |                  2.5 |            2.5 |               2.5 |              3 |            3 |                   3 |           2 |

A better alternative would be to use Data Group & Outline feature

Grouping of columns in table below is done by hand ... One way to introduce the feature would be to use << and >> markers (a variation of the already existing < and > markers for col grouping and vertical rules) TODO: How would one do row grouping? or row hiding

[kjambunathan]

Before I asked you for elaborating your needs, I had already some changes in my workarea. I polished it and pushed it. Let me know what you find.

I will find ways to do col / row grouping / outlining. (Implementing this would require great amount of care, so reserving it for later)

[kjambunathan]

I'd like to fold (or shrink) the columns that I consider as auxiliary columns

M-x org-table-shrink and M-x org-table-expand will do the job.

I would have multiple copies of the same long table, with each copy having a different shrink spec, and thus having different view.

org-table-shrink is an autoloaded interactive byte-compiled Lisp
function in ‘org-table.el’.

(org-table-shrink &optional BEGIN END)

Shrink all columns with a width cookie in the table at point.

Columns without a width cookie are expanded.

Optional arguments BEGIN and END, when non-nil, specify the
beginning and end position of the current table.

org-table-expand is an autoloaded interactive byte-compiled Lisp
function in ‘org-table.el’.

(org-table-expand &optional BEGIN END)

Expand all columns in the table at point.
Optional arguments BEGIN and END, when non-nil, specify the
beginning and end position of the current table.

[ouboub]

<#secure method=smime mode=sign>

"k" == kjn @.***> writes:

Before I asked you for elaborating your needs, I had already some changes in my workarea. I polished it and pushed it. Let me know what you find.

I will find ways to do col / row grouping / outlining. (Implementing this would require great amount of care, so reserving it for later)

Thanks, so I have to pull and compile I presume?

Oh wait, this is patch for the commit that is merged with the latest org-mode?

I had several problems with this. Right now I am using still commit cf2d1919c38fcc1bc

(I manually merged your change for the alias vmax-->max into the version I use)

So I better wait, till tomorrow afternoon after the video-conference and then try it out (I need also to get org updated, but not before that conference)

BTW I received a reply from the LO mailing list.

They proposed to transpose the table, I presume there is a way in LO do to this and somehow translating all the formulas, an operation that is impossible in org-mode as far as I know.

So thanks and tomorrow evening I will report back

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

[kjambunathan]

From https://ask.libreoffice.org/t/how-do-i-convert-rows-into-columns-or-vice-versa-in-calc/7125/3

1. Select the area of data you want to “convert”, e.g., click top-left cell, then shift-click bottom right cell. You should how have copied all the rows of data that you want to convert into columns of data.
2. Hit CTRL-C to copy.
3. Go to a new worksheet, click the cell where you want to paste your new columns.
4. Either hit Shift-CTRL-V, or use Edit > Paste Special... from the toolbar to bring up this dialog:
5. Ensure that the Transpose option is selected, then click OK. Done!

The same process works in either direction (cols-to-rows, rows-to-cols).