* [POLL] Syntax change: make \[...\] non-inline (+1)
@ 2014-07-30 16:50 Federico Beffa
2014-07-30 17:17 ` Nick Dokos
2014-07-31 9:03 ` Rasmus
0 siblings, 2 replies; 11+ messages in thread
From: Federico Beffa @ 2014-07-30 16:50 UTC (permalink / raw)
To: mail, emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-07-30 16:50 [POLL] Syntax change: make \[...\] non-inline (+1) Federico Beffa
@ 2014-07-30 17:17 ` Nick Dokos
2014-07-31 9:03 ` Rasmus
1 sibling, 0 replies; 11+ messages in thread
From: Nick Dokos @ 2014-07-30 17:17 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-07-30 16:50 [POLL] Syntax change: make \[...\] non-inline (+1) Federico Beffa
2014-07-30 17:17 ` Nick Dokos
@ 2014-07-31 9:03 ` Rasmus
2014-08-02 19:12 ` Nicolas Goaziou
1 sibling, 1 reply; 11+ messages in thread
From: Rasmus @ 2014-07-31 9:03 UTC (permalink / raw)
To: emacs-orgmode
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!
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-07-31 9:03 ` Rasmus
@ 2014-08-02 19:12 ` Nicolas Goaziou
0 siblings, 0 replies; 11+ messages in thread
From: Nicolas Goaziou @ 2014-08-02 19:12 UTC (permalink / raw)
To: Rasmus; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
@ 2014-07-30 20:19 Federico Beffa
0 siblings, 0 replies; 11+ messages in thread
From: Federico Beffa @ 2014-07-30 20:19 UTC (permalink / raw)
To: ndokos, emacs-orgmode
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
@ 2014-08-01 8:22 Federico Beffa
0 siblings, 0 replies; 11+ messages in thread
From: Federico Beffa @ 2014-08-01 8:22 UTC (permalink / raw)
To: rasmus, emacs-orgmode
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
@ 2014-08-03 16:32 Federico Beffa
2014-08-03 18:19 ` Nick Dokos
0 siblings, 1 reply; 11+ messages in thread
From: Federico Beffa @ 2014-08-03 16:32 UTC (permalink / raw)
To: ndokos, emacs-orgmode
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-08-03 16:32 Federico Beffa
@ 2014-08-03 18:19 ` Nick Dokos
0 siblings, 0 replies; 11+ messages in thread
From: Nick Dokos @ 2014-08-03 18:19 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
@ 2014-08-03 20:05 Federico Beffa
2014-08-03 20:48 ` Nick Dokos
2014-08-04 8:55 ` Rasmus
0 siblings, 2 replies; 11+ messages in thread
From: Federico Beffa @ 2014-08-03 20:05 UTC (permalink / raw)
To: Nick Dokos, emacs-orgmode
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-08-03 20:05 Federico Beffa
@ 2014-08-03 20:48 ` Nick Dokos
2014-08-04 8:55 ` Rasmus
1 sibling, 0 replies; 11+ messages in thread
From: Nick Dokos @ 2014-08-03 20:48 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [POLL] Syntax change: make \[...\] non-inline (+1)
2014-08-03 20:05 Federico Beffa
2014-08-03 20:48 ` Nick Dokos
@ 2014-08-04 8:55 ` Rasmus
1 sibling, 0 replies; 11+ messages in thread
From: Rasmus @ 2014-08-04 8:55 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-08-04 8:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-30 16:50 [POLL] Syntax change: make \[...\] non-inline (+1) Federico Beffa
2014-07-30 17:17 ` Nick Dokos
2014-07-31 9:03 ` Rasmus
2014-08-02 19:12 ` Nicolas Goaziou
-- strict thread matches above, loose matches on Subject: below --
2014-07-30 20:19 Federico Beffa
2014-08-01 8:22 Federico Beffa
2014-08-03 16:32 Federico Beffa
2014-08-03 18:19 ` Nick Dokos
2014-08-03 20:05 Federico Beffa
2014-08-03 20:48 ` Nick Dokos
2014-08-04 8:55 ` Rasmus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).