emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* [POLL] Syntax change: make \[...\] non-inline
@ 2014-07-28 12:21 Nicolas Goaziou
  2014-07-28 12:26 ` Bastien
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Nicolas Goaziou @ 2014-07-28 12:21 UTC (permalink / raw)
  To: Org Mode List

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/88882

-- 
Nicolas Goaziou                                                0x80A93738

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [POLL] Syntax change: make \[...\] non-inline
  2014-07-28 12:21 [POLL] Syntax change: make \[...\] non-inline Nicolas Goaziou
@ 2014-07-28 12:26 ` Bastien
  2014-07-28 13:12 ` [POLL] Syntax change: make \[...\] non-inline (-1) Nicolas Berthier
  2014-07-28 14:56 ` [POLL] Syntax change: make \[...\] non-inline Rasmus
  2 siblings, 0 replies; 4+ messages in thread
From: Bastien @ 2014-07-28 12:26 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Org Mode List

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>     - documents containing \[...\] mid-line will be broken (such
>       constructs will not be recognized anymore).

That's a big cons for only a small benefit IMHO.

But I don't feel strongly about it.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [POLL] Syntax change: make \[...\] non-inline (-1)
  2014-07-28 12:21 [POLL] Syntax change: make \[...\] non-inline Nicolas Goaziou
  2014-07-28 12:26 ` Bastien
@ 2014-07-28 13:12 ` Nicolas Berthier
  2014-07-28 14:56 ` [POLL] Syntax change: make \[...\] non-inline Rasmus
  2 siblings, 0 replies; 4+ messages in thread
From: Nicolas Berthier @ 2014-07-28 13:12 UTC (permalink / raw)
  To: Org Mode List

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/88882

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 "<div>"s when it encounters
such constructs in paragraphs like "<p>...\[...\]...</p>", and those
<div>s 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 Berthier                                        FSF Member #7975

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [POLL] Syntax change: make \[...\] non-inline
  2014-07-28 12:21 [POLL] Syntax change: make \[...\] non-inline Nicolas Goaziou
  2014-07-28 12:26 ` Bastien
  2014-07-28 13:12 ` [POLL] Syntax change: make \[...\] non-inline (-1) Nicolas Berthier
@ 2014-07-28 14:56 ` Rasmus
  2 siblings, 0 replies; 4+ messages in thread
From: Rasmus @ 2014-07-28 14:56 UTC (permalink / raw)
  To: emacs-orgmode

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> The current proposal is to make them elements instead of objects in Org
> syntax (i.e, a `latex-environment' instead of a `latex-fragment'). 
> [...]
> WDYT?

I think it's a bad idea.

One can use
  \begin{EQUATION} · \end{EQUATION}
(where EQUATION is one's favorite math-construct) for that purpose.
With cdlatex, structure templates (org-structure-template-alist) or
key-chord.el it need not require much effort to insert such an
environment.  Thus, the pros seem trivial in my opinion.

OTOH, it's nice to have a inline display-math constructor, \[·\], and
the up-front cost of comparability-issues seems expensive.

Cheers,
Rasmus

-- 
The right to be left alone is a human right

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-07-28 17:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-28 12:21 [POLL] Syntax change: make \[...\] non-inline Nicolas Goaziou
2014-07-28 12:26 ` Bastien
2014-07-28 13:12 ` [POLL] Syntax change: make \[...\] non-inline (-1) Nicolas Berthier
2014-07-28 14:56 ` [POLL] Syntax change: make \[...\] non-inline 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).