Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Hello, > > Colin Baxter <m43...@yandex.com> writes: > >>>>>>> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> >> > Timothy <tecos...@gmail.com> writes: >> >> Nicolas Goaziou <m...@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.