Pride Allman <allmanpr...@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 encountered. 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. Best, Ihor