[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (Feature Request) add more entry points to configure some export fun
From: |
Timothy |
Subject: |
Re: (Feature Request) add more entry points to configure some export functionality |
Date: |
Tue, 19 May 2020 21:23:36 +0800 |
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.
>