3

The Linux distribution I use (Fedora 32) recently upgraded the included Emacs version from 26.3 to 27.1. With this new version, it appears that the "width cookie" for the org-mode tables are no longer working.

For example, if I have the following:

| Test Column A | Test Column B |
|---------------+---------------|
| <30>          | <5>           |
|---------------+---------------|
| Data          | Data          |
| Data          | Data          |
| ...           | ...           |

While the tags are highlighted (a.k.a. recognized), they will neither expand column "A" nor shrink column "B". In Emacs 26.3 it was working as expected.

The additional tags <l> and <r> (either with or without a number) keep on aligning the text as before.

As a side-note: Numbers are not right-aligned unless <r> is specified for the entire column. That was also auto-detected before.

Is this a change in behavior for which I missed to change an option or is this a bug?

The answer to this question seems to be a crude workaround rather than a solution and would not be what I was looking for. It used to be automatic on cell change after using TAB.

Phoenix
  • 341
  • 1
  • 8
  • 1
    See [*** =align= STARTUP value no longer narrow table columns](https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L1112) and [*** Dynamically narrow table columns](https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L1214). Alignment and shrinking are now independent of each other. – NickD Sep 06 '20 at 15:19
  • @NickD, so it is actually this crude workaround/alternative people need to use then. How sad. Thanks anyway. – Phoenix Sep 06 '20 at 15:49
  • @NickD: Please consider posting your comment as an answer. Comments can be deleted at any time. Thx. – Drew Sep 06 '20 at 18:05

1 Answers1

3

See *** =align= STARTUP value no longer narrow table columns and *** Dynamically narrow table columns. Alignment and shrinking are now independent of each other.

If you will allow me an editorial comment, I was as upset as you were when I encountered the change, but I no longer miss the old behavior at all. So give it a try, use #+STARTUP: align shrink (or the "permanent" equivalents, using org-startup-align-all-tables and org-startup-shrink-all-tables) and see if it grows on you.

I have not noticed any number alignment problems, but maybe you can provide a MWE (= Minimal Working Example)? Or maybe better, ask it as a separate question.

NickD
  • 27,023
  • 3
  • 23
  • 42
  • If you let me know what an MWE is, I may. – Phoenix Sep 06 '20 at 19:08
  • Edited to add the definition (although in this case, you might provide a Minimal Non-working Example :-) ) – NickD Sep 06 '20 at 19:13
  • Just tried the `#+STARTUP: align shrink`, but seeing that even when exiting out of org-mode, those triple dots at the right of each table remain. If one removes them, the entire table collapses (into an unaligned mess) and one is better off to manually align it to the desired width. Since the Emacs devs apparently find this the new way to go, I will keep this the accepted answer, but coming to perfect alignment, I would possibly need to look for a different option/tool than org-mode or go back to manually aligning it. – Phoenix Sep 06 '20 at 19:28
  • The triple dots are *NOT* part of the table: they are overlays indicating a shrunk column. If you `cat` the file in a terminal, you will see that they are not there. If you mean something else, maybe you can edit your question and add details (in particular, "...works as expected" needs to be explained more precisely). – NickD Sep 06 '20 at 19:39
  • Before, the table was physically enlarged (if using larger numbers than the actual content). That was perfect as one could exit org-mode, use another editor or whatever and the table would look exactly the same as outlined while using org-mode. The new behavior only super-imposes this, which basically collapses as soon as you exit the file. While maybe useful when only in org-mode, if you use features of org-mode to create content for non-org-mode uses, it is no longer usable... unfortunately. – Phoenix Sep 06 '20 at 19:58