Re: [PATCH] Don't fill displayed equations

[Tim Cross <theophilusx@gmail.com>]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Colin Baxter <m43cap@yandex.com> writes:
>
>>>>>>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>     > Timothy <tecosaur@gmail.com> writes:
>>     >> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>     >> 
>>     >>> I strongly disagree with this. \[...\] is an inline element, not
>>     >>> a block element. As such, it can be filled, and filling function
>>     >>> should obey to the inner structure of the document.
>>     >>> 
>>     >>> You can use a real block element here, e.g.,
>>     >>> \begin{equation*}...\end{equation*}, which will not be filled.
>>     >> 
>>     >> Given that \[ ... \] is an alias for \begin{equation*} ...
>>     >> \end{equation*}
>>
>>     > This is true in LaTeX, not in Org, obviously.
>>
>> But shouldn't org be consistent with LaTeX. 
>
> Org supports, as a small part of its syntax, some limited LaTeX markup.
> It doesn't imply it should strive for consistency with LaTeX. Actually,
> I think it's quite the opposite. Org is not a LaTeX front-end.
>

I think this is an important point. Org, like other 'markdown' style
abstractions is a lot more than just a convenience abstraction for
writing Latex. Like other markdown dialects which have an 'escape hatch'
which allows you to embed raw HTML in your document, org allows
embedding 'latex' fragments, but that does not mean it is a latex
front-end. How document elements are displayed in the buffer should not
be determined just by what/how latex does it - it might provide some
guidance, but should not be the sole decider (i.e. because this is how
latex does it is not sufficient justification in itself).

With respect to this patch, I can see both sides having merit. Timothy's
points make sense from an end user's perspective and how things look in
the buffer. However, Nicolas point is also very relevant, especially if
we hope to have a markup syntax which is consistent and parsed
consistently. I'm not convinced that one inline element should be
treated differently  because in some situations, it is easier to
read/edit. Changing the visual representation of this inline block may
also have impact on user expectations for export and could lead to
further confusion.