Timothy writes:
> Hi Ihor,
>
>> Then would you mind proposing a patch for org-fill-element in
>> particular? At least, you seem to have a motivation for this particular
>> function ;)
>
> Perhaps in a few weeks, for now I’m a bit to busy for anything other than
> “accidental” patches.
Quite a
My thanks to Ihor for the argument concerning code of (maybe external)
exproters and to Tom for parser-related considerations.
I think it is a kind of trade-off: breaking change vs. continuously
breaking user experience. Do not worry too much, there is almost no
chance that I will try to
Hi Org-mode community!
> Does anybody have any other thoughts?
I have been following your discussion for several days
and if I understand it correctly promoting \[ to an element
is the most controversial.
Isn’t the behavior of fill-paragraph
(see https://emacs.stackexchange.com/q/29122/14127
Hi Tom,
> From time to time I encounter random patterns that I don’t want to be
> reformatted during a fill operation. Maybe a custom variable like
> org-fill-paragraph-skip-regexp or similar that could be set by the user?
> For Timothy’s use case he would set it to the regexp provided in the
>
> Does anybody have any other thoughts?
>From time to time I encounter random patterns that I don't want to be
reformatted during a fill operation. Maybe a custom variable like
org-fill-paragraph-skip-regexp or similar that could be set by the user?
For Timothy's use case he would set it to the
Hi All,
Given the way the conversation has evolved I think it may be worth revisiting
another viewpoint to see if anybody has any nice ideas.
As things are, regardless of the complexities of parsing and inline vs.
block elements etc., just considering the user experience when running
org-fill
Some thoughts.
> Maybe you are right and Tom was actually assuming \begin{equation*}, not
> #+begin_export latex.
Correct. My bad on that one.
> Just as Timothy, I believe that \begin{equation*} is unnecessary verbose
> when \[ works *mostly* in a similar way.
\begin{equation*} is absolutely
Max Nikulin writes:
>> Making \[ \] available outside of a paragraph would be a massive
>> breaking change.
>
> Is it really breaking? I can not estimate required amount of work to
> implement it. However at the user side at first glance most of files
> should remain valid and I could not
On 03/10/2021 17:56, Stefan Nobis wrote:
Max Nikulin writes:
On 03/10/2021 00:51, Tom Gillespie wrote:
I guess one thing I'm missing/not understanding is when/why people
want to use \[ \] instead of full #+begin_export latex block?
For example, because document without equations may
Max Nikulin writes:
> On 03/10/2021 00:51, Tom Gillespie wrote:
>> I guess one thing I'm missing/not understanding is when/why people
>> want to use \[ \] instead of full #+begin_export latex block?
> For example, because document without equations may become almost
> useless in the case of
Hi Ihor,
> Then would you mind proposing a patch for org-fill-element in
> particular? At least, you seem to have a motivation for this particular
> function ;)
Perhaps in a few weeks, for now I’m a bit to busy for anything other than
“accidental” patches.
All the best,
Timothy
Timothy writes:
> Ihor Radchenko writes:
>
>> I personally would prefer modular function as a whole. For my taste,
>> Org code has too much of (case (variant 1) (variant 2) …)-style
>> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
>> etc) and they are a pain to debug
Ihor Radchenko writes:
> I personally would prefer modular function as a whole. For my taste,
> Org code has too much of (case (variant 1) (variant 2) …)-style
> functions (i.e. org-todo, org-cycle, org-ctrl-c-ctrl-c, org-store-link,
> etc) and they are a pain to debug and advice for users.
Timothy writes:
> Hi Ihor,
>
>> What about making org-fill-element modular? We may define separate fill
>> functions for different elements and let the user override them
>> individually if the user prefer so. It may be implemented similar to
>> export functionality with customisable
Hi Ihor,
> What about making org-fill-element modular? We may define separate fill
> functions for different elements and let the user override them
> individually if the user prefer so. It may be implemented similar to
> export functionality with customisable formatters for different
>
On 03/10/2021 00:51, Tom Gillespie wrote:
do not see a reason for idiosyncrasy that markup intended to add LaTeX
snippet that looks like exactly as LaTeX commands for this purpose and
even actually preserved during export to LaTeX should have different
semantics for Org parser.
The answer is
Timothy writes:
> Hi Nicolas,
>
>> *snip lots of text*
>
> Thanks for going through my points in detail. I think I understand your
> perspective much better now. At this point though, I’m not really sure what to
> make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
>
Hi Timothy,
> │ \[
> │ not part of a paragraph
> │ \]
My point is that that parses first as a paragraph (check org-element-at-point).
\[ and \] would be meaningless if it did not first parse as a paragraph.
> I also don’t see how footnotes are analogous, as footnotes are placed in the
>
Hi Tom,
> The answer is that can only occur inside paragraphs. The issues
> here are exactly the same as the issues for inline footnotes. Org gives
> us a bit more power, but not the full power because Org is Org, not
> Latex. Making available outside of a paragraph would be a massive
>
> do not see a reason for idiosyncrasy that markup intended to add LaTeX
> snippet that looks like exactly as LaTeX commands for this purpose and
> even actually preserved during export to LaTeX should have different
> semantics for Org parser.
The answer is that \[ \] can only occur inside
On 02/10/2021 18:24, Eric S Fraga wrote:
On Saturday, 2 Oct 2021 at 18:18, Timothy wrote:
I can’t help but think that this line of thinking is a bit of a trap, because
I think you're right. Nicolas's view that we should not think of org as
a front-end for LaTeX is probably more to the
Hi Nicolas,
> *snip lots of text*
Thanks for going through my points in detail. I think I understand your
perspective much better now. At this point though, I’m not really sure what to
make of `\[ ... \]', I now feel like it’s sitting in some sort of markup limbo
where it can’t be either fully
On Saturday, 2 Oct 2021 at 18:18, Timothy wrote:
> I can’t help but think that this line of thinking is a bit of a trap, because
I think you're right. Nicolas's view that we should not think of org as
a front-end for LaTeX is probably more to the point. As Stefan has
noted, how LaTeX processes
Hello,
Timothy writes:
> Is it? I can't use verbatim like this:
>
> =
> some
> verbatim
> text
> =
>
> but I can do
>
> \[
> some
> display
> equation
> \]
>
> It seems to me that \[ ... \] is already treated differently from other
> inline markup.
There is some misunderstanding here.
You
Hi Eric,
>> text
>> 1+1=3
>> text
>>
>> is a single paragraph in LaTeX.
> This is true and probably the most convincing argument in this debate.
I can’t help but think that this line of thinking is a bit of a trap, because
what LaTeX’s idea of a paragraph does not line up with Org’s. I think
On Friday, 1 Oct 2021 at 22:41, Nicolas Goaziou wrote:
> Yes: habit. Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.
This is true and probably the most convincing argument in this debate.
I have no
Nicolas Goaziou writes:
> Also, I don't think LaTeX treats it as a block element.
> E.g.,
>
> text
> \[1+1=3\]
> text
>
> is a single paragraph in LaTeX.
Yes and no. LaTeX is a bit more complex and does not only see inline
or block elements. It has paragraph mode (and inner
Hello,
Stefan Nobis writes:
> I wonder, why it is not a block element. As far as I know, the only
> difference (even in the context of Org) between \(...\) and \[...\]
> is, that the former denotes inline math and the latter denotes a math
> block. And at least exporting to HTML (with MathJax)
hi, Timothy, et al.,
like Tim, i can see both sides here. but, a fundamental of org-mode is
this statement of Nicolas', "Org is not a LaTeX front-end."
i ran into this precisely with $...$, i.e., the restrictions that
org-mode requires, in order to protect from confusing a currency
indicator
Nicolas Goaziou writes:
> Timothy writes:
>
>> I think there are also some relevant points which I haven’t mentioned so far,
>> separate from my thoughts that since we’re using the LaTeX syntax we should
>> be
>> consistent with how LaTeX treats this.
>
> I'm not convinced about this. I
Nicolas Goaziou writes:
> Now, if you want to discuss changing syntax for \[...\] and make it
> a block element
I wonder, why it is not a block element. As far as I know, the only
difference (even in the context of Org) between \(...\) and \[...\]
is, that the former denotes inline math and the
Timothy writes:
> I think there are also some relevant points which I haven’t mentioned so far,
> separate from my thoughts that since we’re using the LaTeX syntax we should be
> consistent with how LaTeX treats this.
I'm not convinced about this. I don't think it is even possible.
>> As I
Nicolas Goaziou writes:
> Hello,
>
> Colin Baxter writes:
>
>>> Nicolas Goaziou writes:
>>
>> > Timothy writes:
>> >> Nicolas Goaziou writes:
>> >>
>> >>> I strongly disagree with this. \[...\] is an inline element, not
>> >>> a block element. As such, it can be
Hello,
Colin Baxter writes:
>> Nicolas Goaziou writes:
>
> > Timothy writes:
> >> Nicolas Goaziou writes:
> >>
> >>> I strongly disagree with this. \[...\] is an inline element, not
> >>> a block element. As such, it can be filled, and filling function
> >>>
Hi Nicolas,
I think there are also some relevant points which I haven’t mentioned so far,
separate from my thoughts that since we’re using the LaTeX syntax we should be
consistent with how LaTeX treats this.
> As I wrote above, they do not belong to the same category of syntax.
> There’s no
Nicolas Goaziou writes:
>> Given that \[ ... \] is an alias for \begin{equation*} ...
>> \end{equation*}
>
> This is true in LaTeX, not in Org, obviously.
Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be
> Nicolas Goaziou writes:
> Timothy writes:
>> Nicolas Goaziou 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
Timothy writes:
> Nicolas Goaziou 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.,
>>
Nicolas Goaziou 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.,
>
Hello,
Timothy writes:
> If a displayed equation (`\[ ... \]') starts on its own line, I don’t think it
> should be filled into the rest of the text. I.e.,
>
> ┌
> │ some nice text
> │ \[
> │ 1+1=2
> │ \]
> │ more text.
> └
> should not become,
> ┌
> │ some nice text \[ 1+1=3 \]
The initial patch was just slightly off. Here's a correct version.
Timothy writes:
> As such, I have attached a patch which adds fill “cuts” around `\[' and
> `\]', when `\[' occurs at the start of a line. This leaves the display
> equation
> delimiters on their own line.
>From
41 matches
Mail list logo
