Re: (Feature Request) add more entry points to configure some export functionality

[Timothy]

Nicolas Goaziou <address@hidden> 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 <address@hidden> wrote:

> Timothy <address@hidden> 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.
>