[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export

From: Ihor Radchenko
Subject: Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export
Date: Thu, 12 May 2022 17:29:46 +0800

Pride Allman <allmanpride@gmail.com> writes:

> So basically, the export function is doing the overwrite for user options
> but to reduce the number of inconsistency we can't use this patch for only
> one such option.
> Now you explained it I can't think of a way to solve it without rewriting
> the whole thing. Or maybe I need to read the source code more deeply.

> Would it be too much to hope for it to be integrated on the basis that
> things like this can be added for other options in other export backend
> too? Or somehow introduce the global settings there.

As an option, the override arguments can be factored out into
defcustoms. Then, you would have an option to deal with the problem you

Another possibility comes from the fact that the overrides are mostly
copying the defaults or trying to transfer alternative option names into
export options:
(list :backend 'latex
          :latex-default-table-mode 'table ;; <- this is default
          :latex-tables-centered nil <- this is _not_ default. The current 
default is t
          :latex-tables-booktabs (plist-get params :booktabs) <- default is nil
          :latex-table-scientific-notation nil <- this is also default
          :latex-default-table-environment <- default is "tabular" but 
:environment is transferred
          (or (plist-get params :environment) "tabular"))

Then, we can:
1. Remove options directly overriding the defaults
2. Do not assign :latex-tables-booktabs and
   :latex-default-table-environment unless :booktabs and :environment
   options are actually provided. Currently, when the latter options are
   not set by user (via #+attr_latex), they are treated as if the user
   force-set them to nil (because plist-get does not distinguish
   (:property nil) and complete absence of :property).

I like the second possibility better because it will make table export
consistent with the rest of export customisation. The downside is that
we can break the existing workflows relying on current behaviour (which
is not too much of a big deal though - we can always document this
change in ORG-NEWS).

The first possibility, on the other hand, will not break the current
behaviour. However, it will only help people who manage to find this new
customisation. We already have too many customisations.

> And considering the answer is no for the previous question; is there a
> workaround for this? Something people use? Because having to manually edit
> the table everytime I export is a bit too much for me.

Yes, there should be a workaround. org-table functions only override
global export settings, not file-local and element-local. That is you
should be able to set #+bind: org-latex-tables-booktabs
org-latex-tables-booktabs. Or #+attr_latex: :booktabs t
Of course, it is not very intuitive and relies on internal knowledge of
the code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]