Re: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Hi, Federico Beffa be...@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
Re: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Federico Beffa be...@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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Federico Beffa be...@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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Hello,
Rasmus ras...@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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Federico Beffa be...@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!
[O] [POLL] Syntax change: make \[...\] non-inline (+1)
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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
Federico Beffa be...@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: [O] [POLL] Syntax change: make \[...\] non-inline (+1)
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: [O] [POLL] Syntax change: make \[...\] non-inline (-1)
You wrote:
Hello,
As discussed in a recent thread[fn:1], \[...\] constructs are
counter-intuitive to some users.
At the time being, \[...\] are inline-able. As a consequence, they are
can be written in the middle of a line, and filled, much like \(...\).
Even though it is also possible to inline them in a LaTeX document, the
intent is to make them stand out in their own lines.
The current proposal is to make them elements instead of objects in Org
syntax (i.e, a `latex-environment' instead of a `latex-fragment'). In
a nutshell:
- Pros:
+ conform to LaTeX intent,
+ impossible to fill.
- Cons:
- documents containing \[...\] mid-line will be broken (such
constructs will not be recognized anymore).
WDYT?
Regards,
[fn:1] http://permalink.gmane.org/gmane.emacs.orgmode/2
Hello,
I often use \[...\] to write maths fragments that constitute grammatical
units of a plain sentence, yet are better read on their own line when
rendered, as in \[x = \mathit{some~complex~stuff} \mbox{ and}\] \[y =
\mathit{more~complex~stuff}\] where \(\mathit{stuff} =
\mathit{less~intricate~stuff}\).
(Recall that LaTeX is in principle intended to allow focusing on
contents instead of formatting, some LaTeX packages may also change the
behavior of \[...\] I think).
Also note that MathJax automatically adds divs when it encounters
such constructs in paragraphs like p...\[...\].../p, and those
divs can still further be customized with CSS ; what would be the
result of exporting to HTML if they were not inline?.
As it is always possible to use displaymath environments, I don't think
any change regarding \[...\] is necessary.
Regards,
N.
--
Nicolas BerthierFSF Member #7975
