Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > As a side note, I think sending plain text messages, instead of HTML, > is better, at least on a (this?) mailing list. Good news on that front --- I didn't think my mail client did that, turns out that it does :)
> This argument doesn't scale. There's no guarantee an equivalent is > meaningful in every export back end. E.g., what is the HTML equivalent > for `org-latex-classes', or `org-latex-default-table-environment'? Oh nothing like this should be applied blindly, it just seems /somewhat/ sensible to me that if the same feature exists in two commonly used export backends, that you'd want to either be able to configure it in both or neither ¯\_(ツ)_/¯ > In any case, if a "consistency patrol" wants to look into export back > ends and handle "fixable" inconsistencies, why not. I assume this > requires a good knowledge in every output format so as to make sure this > is consistent everywhere. I like consistancy, but not enough to sign up for that :P Timothy. On May 19 2020, at 9:17 pm, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Timothy <tecos...@gmail.com> writes: > > As a side note, I think sending plain text messages, instead of HTML, is > better, at least on a (this?) mailing list. > >> Indeed. Though my 2c on this sort of thing that the most important >> factor is consistency. IMO if org-html-checkbox-types exists, then an >> equivalent should also exist for other primary/default export >> backends. > > This argument doesn't scale. There's no guarantee an equivalent is > meaningful in every export back end. E.g., what is the HTML equivalent > for `org-latex-classes', or `org-latex-default-table-environment'? > > In any case, if a "consistency patrol" wants to look into export back > ends and handle "fixable" inconsistencies, why not. I assume this > requires a good knowledge in every output format so as to make sure this > is consistent everywhere. >