emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don't fill displayed equations


From: Tim Cross
Subject: Re: [PATCH] Don't fill displayed equations
Date: Fri, 01 Oct 2021 08:26:23 +1000
User-agent: mu4e 1.7.0; emacs 28.0.60

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. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]