[POLL] Syntax change: make \[...\] non-inline (+1)

[POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

Who is entitled to vote? If I am then here is my vote in favor for the
following reasons:

1. the construct \[...\] has been defined in LaTeX for equations which
must stand out and therefore belong on separate lines. It would
therefore make sense to conform to the borrowed syntax.

2. the alternative displaymath environment could in principle be used
instead of \[...\]. However, this is not very nice because when
exporting to a text file the former is very invasive, while latter is
not.

3. Right now the \[...\] construct when exported to LaTeX produces
equations on dedicated lines. While the same construct when exported
to a text file results in an inline equation. This is inconsistent and
would be corrected by the change.

4. There are 2 other constructs dedicated to inline equations: \(...\)
and $...$.

5. Existing documents are very easy to fix.

6. Exporting to html can be adapted to produces any desired result and
should therefore not be a concern.

Regards,
Federico

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Nick Dokos]

Federico Beffa <beffa@ieee.org> writes:

> Who is entitled to vote? If I am then here is my vote in favor for the
> following reasons:
>
> 1. the construct \[...\] has been defined in LaTeX for equations which
> must stand out and therefore belong on separate lines. It would
> therefore make sense to conform to the borrowed syntax.
>

I don't quite understand why you are so gung-ho for this but the
following works fine:

--8<---------------cut here---------------start------------->8---
\documentclass{article}

\begin{document}
This is a displayed \[ x = 3 \] equation.
\end{document}
--8<---------------cut here---------------end--------------->8---

So what exactly is the problem?

> 5. Existing documents are very easy to fix.
>

Backwards compatibility is important. It has been broken
before, for very good reasons, and even though it was done very
carefully, it still caused many problems (still does).
So I don't buy the "very easy to fix" part: it will bite somebody
two minutes before he/she has to make a presentation (or even during the
presentation - DAMHIKT).

Nick

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

> So what exactly is the problem?

The problem is that \[...\] is often used for long/complicated
equations. If you allow auto-fill to change/modify your carefully
written equation, it becomes very difficult to read.

Regards,
Fede

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Rasmus]

Federico Beffa <beffa@ieee.org> writes:

> Who is entitled to vote? If I am then here is my vote in favor for the
> following reasons:
>
> 1. the construct \[...\] has been defined in LaTeX for equations which
> must stand out and therefore belong on separate lines. It would
> therefore make sense to conform to the borrowed syntax.

Background:

It works sensibly in latex-mode.  If your text is

   My displayed \[equation\]
   is here

M-q will make it 

   My displayed \[equation\] is here

But 

   My displayed
   \[equation\]
   is here

Is unaltered by M-q (though it was not obvious to me how tex-mode.el
implemented this).

I didn't read the other thread is details, but it seems the most
sensible thing to do is alter the org fill function(s).  These seems
to rely on org-element, though, and I'm guessing that is why a syntax
change is necessary, yes?

—Rasmus

-- 
You people at the NSA are becoming my new best friends!

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

> I didn't read the other thread is details, but it seems the most
> sensible thing to do is alter the org fill function(s).  These seems
> to rely on org-element, though, and I'm guessing that is why a syntax
> change is necessary, yes?

I would be perfectly happy with this behavior. Can't comment on
implementation aspects.

Regards,
Federico

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Nicolas Goaziou]

Hello,

Rasmus <rasmus@gmx.us> writes:

> It works sensibly in latex-mode.  If your text is
>
>    My displayed \[equation\]
>    is here
>
> M-q will make it 
>
>    My displayed \[equation\] is here
>
> But 
>
>    My displayed
>    \[equation\]
>    is here
>
> Is unaltered by M-q (though it was not obvious to me how tex-mode.el
> implemented this).
>
> I didn't read the other thread is details, but it seems the most
> sensible thing to do is alter the org fill function(s).  These seems
> to rely on org-element, though, and I'm guessing that is why a syntax
> change is necessary, yes?

As explained in the original thread, this is not quite possible. Unlike
to LaTeX, Org puts a strong emphasis on the difference between inline
and non-inline blocks. You can write

  #+begin_center
  contents
  #+end_center

but not

  #+begin_center contents #+end_center

As you know, it doesn't matter much in LaTeX,

  \begin{equation} contents \end{equation}

is as fine as

  \begin{equation}
  contents
  \end{equation}

Of course, it would be possible to add extra code in filling functions
(and more) to mimic this behaviour, but that would really go against the
syntax.

Org is not LaTeX, nor it is meant to mimic it. \[...\] are either inline
or not, like every other construct. In the first case, M-q will fill
them within a paragraph. In the second case, it will not be possible to
have \[...\] in the middle of the line. Hence the poll.

IMO, filling \[...\] is a minor issue since you can write, e.g.,

  \begin{displaymath}
  ...
  \end{displaymath}

when you absolutely don't want M-q to be active. There is no strong
incentive to alter syntax or filling functions.


Regards,

-- 
Nicolas Goaziou

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

>> 5. Existing documents are very easy to fix.
>>
>
>Backwards compatibility is important. It has been broken
>before, for very good reasons, and even though it was done very
>carefully, it still caused many problems (still does).
>So I don't buy the "very easy to fix" part: it will bite somebody
>two minutes before he/she has to make a presentation (or even during the
>presentation - DAMHIKT).

Don't get me wrong, I value backward compatibility.

However, here for the end user the change would amount to something like

 if \[ is not at the beginning of a line, then insert \n before \[
 if \] does not end a line, then insert \n after \]

for the whole document (or something similar). This should obviously
be documented in the release notes where an exact procedure to fix the
document can be detailed (possibly two query-replace expressions).

And if somebody updates just before a presentation and without reading
the release notes, then it's his own fault.

Regards,
Federico

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Nick Dokos]

Federico Beffa <beffa@ieee.org> writes:

>>> 5. Existing documents are very easy to fix.
>>>
>>
>>Backwards compatibility is important. It has been broken
>>before, for very good reasons, and even though it was done very
>>carefully, it still caused many problems (still does).
>>So I don't buy the "very easy to fix" part: it will bite somebody
>>two minutes before he/she has to make a presentation (or even during the
>>presentation - DAMHIKT).
>
> Don't get me wrong, I value backward compatibility.
>
> However, here for the end user the change would amount to something like
>
>  if \[ is not at the beginning of a line, then insert \n before \[
>  if \] does not end a line, then insert \n after \]
>
> for the whole document (or something similar). This should obviously
> be documented in the release notes where an exact procedure to fix the
> document can be detailed (possibly two query-replace expressions).
>
> And if somebody updates just before a presentation and without reading
> the release notes, then it's his own fault.
>

It's a bit more complicated than that: one upgrades org at some
opportune moment, then three months/years/centuries later, tries to use
that presentation that worked perfectly before - boom. If you go back
and check all your old presentations each time you upgrade org, you are,
I would guess, the exception, not the rule. I certainly don't do that

Just to be clear: on the whole issue you bring up, I'm more or less
neutral (slightly negative to be sure, mostly because I'm not convinced
that it's a serious problem, but I could live with it either way).

I generally put displays in separate paragraphs, I rarely use
autofill[fn:1] and I'm happy to do M-q on individual paragraphs instead,
but if I happen to do it on the wrong paragraph (backtraces, code
fragments, displayed equations), undo is easy enough.

Footnotes:

[fn:1] I use it in gnus message composition modes by default, and I
often swear at it and turn it off because it does things that I don't
want it to do - mostly mangles backtraces and code fragments; I probably
should turn it off completely.

-- 
Nick

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Federico Beffa]

> It's a bit more complicated than that: one upgrades org at some
> opportune moment, then three months/years/centuries later, tries to use
> that presentation that worked perfectly before - boom. If you go back
> and check all your old presentations each time you upgrade org, you are,
> I would guess, the exception, not the rule. I certainly don't do that

Well, if I reuse an old presentation I usually use the old pdf.

> I generally put displays in separate paragraphs, I rarely use
> autofill[fn:1] and I'm happy to do M-q on individual paragraphs instead,
> but if I happen to do it on the wrong paragraph (backtraces, code
> fragments, displayed equations), undo is easy enough.

The problem with that is that a displayed equation should NOT start a
new paragraph (in the generated LaTeX file). This is because if it
does then LaTeX puts more (vertical) space than desirable.

Regards,
Federico

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Nick Dokos]

Federico Beffa <beffa@ieee.org> writes:

>> It's a bit more complicated than that: one upgrades org at some
>> opportune moment, then three months/years/centuries later, tries to use
>> that presentation that worked perfectly before - boom. If you go back
>> and check all your old presentations each time you upgrade org, you are,
>> I would guess, the exception, not the rule. I certainly don't do that
>
> Well, if I reuse an old presentation I usually use the old pdf.
>

Well, if you are lucky enough to have a static presentation that will
cover the past and present as well as the future, fine. But most of mine
are templates that incorporate the latest set of numbers: the old pdf
will not cut it. I suspect that most people do something similar at
least some of the time. It is then that that (mostly forgotten) update
from a couple of weeks ago that broke backwards compatibility will bite.

>> I generally put displays in separate paragraphs, I rarely use
>> autofill[fn:1] and I'm happy to do M-q on individual paragraphs instead,
>> but if I happen to do it on the wrong paragraph (backtraces, code
>> fragments, displayed equations), undo is easy enough.
>
> The problem with that is that a displayed equation should NOT start a
> new paragraph (in the generated LaTeX file). This is because if it
> does then LaTeX puts more (vertical) space than desirable.
>

It's a matter of perspective: I don't expect org to replace latex
(but I realize that some people do).

-- 
Nick

Re: [POLL] Syntax change: make \[...\] non-inline (+1)

[Rasmus]

Hi,

Federico Beffa <beffa@ieee.org> writes:

> The problem with that is that a displayed equation should NOT start a
> new paragraph (in the generated LaTeX file). This is because if it
> does then LaTeX puts more (vertical) space than desirable.

If this is always the case for you, you can "fix" this behavior by
always putting it in a new paragraph and using a filter.

Example:

     paragraph 1

     \[math 1\]

     paragraph 2

Use a final filter to convert this to

     paragraph 1
     \[math 1\]
     paragraph 2

Perhaps you want to have some finer control over whether there should
be a newline between math 1 and paragraph 2, e.g. exploiting the fact
that "\n\n" is exported as "\n\n".

Thus,

     paragraph 1

     \[math 1\]


     paragraph 2

would become

     paragraph 1
     \[math 1\]

     paragraph 2

Cheers,
Rasmus