emacs-orgmode@gnu.org archives
help / color / mirror / code / Atom feed
* [PATCH] Add support for $…$ latex fragments followed by a dash
@ 2022-01-24 16:42 Sébastien Miquel
2022-01-25  7:56  Eric S Fraga
2022-01-26  6:33  Tom Gillespie
0 siblings, 2 replies; 21+ messages in thread
From: Sébastien Miquel @ 2022-01-24 16:42 UTC (permalink / raw)

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

Hi,

The attached patch adds support for $…$ latex fragments followed by a
dash, such as $n$-th.

This pattern is quite common, and the issue was mentionned by Rudolf

This extension of the syntax doesn't conflict with the use of $'s in table formulas, or for currency, AFAICT. Regards, -- Sébastien Miquel [-- Attachment #2: 0001-org-element-Support-LaTeX-fragments-followed-by-a-da.patch --] [-- Type: text/x-patch, Size: 3159 bytes --] From b023fff129a5cc3b1f12b9f170f2e018dc34d237 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Miquel?= <sebastien.miquel@posteo.eu> Date: Sun, 23 Jan 2022 13:28:03 +0100 Subject: [PATCH] =?UTF-8?q?org-element:=20Support=20$=E2=80=A6$=20LaTeX=20?= =?UTF-8?q?fragments=20followed=20by=20a=20dash?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-element.el (org-element-latex-fragment-parser): * lisp/org.el (org-latex-regexps): Allow a dash right after a$…$fragment. * testing/lisp/test-org-element.el (test-org-element/latex-fragment-parser): Add test. Allows such uses as $n$-th' or $n$-dimensional'. --- lisp/org-element.el | 2 +- lisp/org.el | 4 ++-- testing/lisp/test-org-element.el | 4 ++++ 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index b82475a14..40a604578 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -3416,7 +3416,7 @@ Assume point is at the beginning of the LaTeX fragment." (not (memq (char-before (match-beginning 0)) '(?\s ?\t ?\n ?, ?.))) (looking-at-p - "\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|\$$") + "\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|'\\|-\\|\$$") (point))))) (post-blank (if (not after-fragment) (throw 'no-object nil) diff --git a/lisp/org.el b/lisp/org.el index 2d439cd05..3a164ee77 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -629,8 +629,8 @@ An entry can be toggled between COMMENT and normal with '(("begin" "^[ \t]*\$$\\\\begin{\\([a-zA-Z0-9\\*]+\$$[^\000]+?\\\\end{\\2}\\)" 1 t) ;; ("$" "\$$[ \t(]\\|^\$$\$$\\(\\([]\$$\$$[^ \t\n,.].*?\\(\n.*?\$$\\{0,5\\}[^ \t\n,.$]\\)\\4\\)\\)\$$[ \t.,?;:'\")]\\|\$$" 2 nil) ;; \000 in the following regex is needed for org-inside-LaTeX-fragment-p - ("$1" "\$$[^]\\|^\$$\$$\\[^ \t\r\n,;.]\\\$$\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|\$$" 2 nil)
-    ("$" "\$$[^]\\|^\$$\$$\\(\\\\([^ \t\n,;.][^\n\r]*?\\(\n[^\n\r]*?\$$\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|\$$" 2 nil) + ("$1" "\$$[^]\\|^\$$\$$\\[^ \t\r\n,;.]\\\$$\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|\$$" 2 nil)
+    ("$" "\$$[^]\\|^\$$\$$\\(\\\\([^ \t\n,;.][^\n\r]*?\\(\n[^\n\r]*?\$$\\{0,2\\}[^ \t\n,.$]\\)\\$\\)\\)\$$\\s.\\|\\s-\\|\\s(\\|\\s)\\|\\s\"\\|\000\\|'\\|-\\|\$$" 2 nil) ("\$$" "\\\\([^\000]*?\\\$$" 0 nil) ("\$" "\\\\\\[[^\000]*?\\\\\$" 0 nil) ("$$" "\\\\[^\000]*?\\\\" 0 nil)) diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el index 6d7376a96..2055e3a7b 100644 --- a/testing/lisp/test-org-element.el +++ b/testing/lisp/test-org-element.el @@ -1776,6 +1776,10 @@ e^{i\\pi}+1=0 (eq 'latex-fragment (org-test-with-temp-text "a'" (org-element-type (org-element-context))))) + (should + (eq 'latex-fragment + (org-test-with-temp-text "a-" + (org-element-type (org-element-context))))) ;; Test forbidden characters inside .... (should-not (eq 'latex-fragment -- 2.34.1 ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for … latex fragments followed by a dash 2022-01-24 16:42 [PATCH] Add support for … latex fragments followed by a dash Sébastien Miquel @ 2022-01-25 7:56  Eric S Fraga 2022-01-25 10:32  Sébastien Miquel 2022-01-26 17:15  Rudolf Adamkovič 2022-01-26 6:33  Tom Gillespie 1 sibling, 2 replies; 21+ messages in thread From: Eric S Fraga @ 2022-01-25 7:56 UTC (permalink / raw) To: Sébastien Miquel; +Cc: Rudolf Adamkovič, emacs-orgmode On Monday, 24 Jan 2022 at 16:42, Sébastien Miquel wrote: > The attached patch adds support for … latex fragments followed by a > dash, such as n-th. But is not necessary (and further complicates the issue of support ... in org as recently discussed on this list) as you can simply type $$n$$-th? -- : Eric S Fraga, with org release_9.5.2-312-g5d05f5 in Emacs 29.0.50 ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for … latex fragments followed by a dash 2022-01-25 7:56  Eric S Fraga @ 2022-01-25 10:32  Sébastien Miquel 2022-01-26 17:15  Rudolf Adamkovič 1 sibling, 0 replies; 21+ messages in thread From: Sébastien Miquel @ 2022-01-25 10:32 UTC (permalink / raw) To: Org Mode List, Eric S Fraga Hi, Eric S Fraga writes: > But is not necessary (and further complicates the issue of support ... > in org as recently discussed on this list) as you can simply type > $$n$$-th? What complication are you referring to, precisely ? The patch is fairly trivial, and a similar extension was already implemented by Nicolas in 2017[1]. Yes, the … syntax is redundant, but I do not think it follows that this change is unnecessary. This patch should have no bearing on the possible deprecation of the … syntax. [1]: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c0369a798470763f8f3c69cf2079c3a194635feb Regards, -- Sébastien Miquel ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for … latex fragments followed by a dash 2022-01-24 16:42 [PATCH] Add support for … latex fragments followed by a dash Sébastien Miquel 2022-01-25 7:56  Eric S Fraga @ 2022-01-26 6:33  Tom Gillespie 2022-01-26 17:49  Sébastien Miquel 1 sibling, 1 reply; 21+ messages in thread From: Tom Gillespie @ 2022-01-26 6:33 UTC (permalink / raw) To: emacs-orgmode > The attached patch adds support for … latex fragments followed by a > dash, such as n-th. Unfortunately this falls into the realm of changes to syntax. The current behavior is not a bug and is working as specified because hyphen minus (U+002D) does not count as punctuation for the purposes of org syntax. We should specify which chars count as punctuation in the syntax doc. As noted by Eric  has no such restrictions. From https://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments > POST is any punctuation (including parentheses and quotes) or space character, or the end of line. Best, Tom ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for … latex fragments followed by a dash 2022-01-25 7:56  Eric S Fraga 2022-01-25 10:32  Sébastien Miquel @ 2022-01-26 17:15  Rudolf Adamkovič 2022-01-27 8:28  Ihor Radchenko 1 sibling, 1 reply; 21+ messages in thread From: Rudolf Adamkovič @ 2022-01-26 17:15 UTC (permalink / raw) To: Eric S Fraga, Sébastien Miquel; +Cc: emacs-orgmode Eric S Fraga <e.fraga@ucl.ac.uk> writes: > But is not necessary (and further complicates the issue of support > ... in org as recently discussed on this list) as you can simply > type $$n$$-th? What you call "not necessary", I call a game changer. As of now, one has to mix and match$$ and  based on the context (such as "-th"). It makes mathematical writing in both harder to /read/ and harder to /change/. Consider: Let$r_i$denote the $$i$$-th rotation of$t$with a suffix of$\ell|t|$characters deleted, for […] Me, if I could, I would pay money for this feature, for it would allow me to use $$consistently, focusing on mathematics instead of markup idiosyncrasies of "rotation i" versus "$$i$$-th rotation". Further,  brings 100% more characters than$$, resulting in more noise in the sentence. Rudy -- "Thinking is a momentary dismissal of irrelevancies." -- Richard Buckminster Fuller, 1969 Rudolf Adamkovič <salutis@me.com> [he/him] Studenohorská 25 84103 Bratislava Slovakia ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash 2022-01-26 6:33  Tom Gillespie @ 2022-01-26 17:49  Sébastien Miquel 2022-01-26 21:49  Tom Gillespie 0 siblings, 1 reply; 21+ messages in thread From: Sébastien Miquel @ 2022-01-26 17:49 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 693 bytes --] Hi, Tom Gillespie writes: > Unfortunately this falls into the realm of changes to syntax. The current > behavior is not a bug and is working as specified because hyphen minus > (U+002D) does not count as punctuation for the purposes of org syntax. > We should specify which chars count as punctuation in the syntax doc. > As noted by Eric  has no such restrictions. > > Fromhttps://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments >> POST is any punctuation (including parentheses and quotes) or space character, or the end of line. With this patch, I also propose to change the specification accordingly. The change is local and minor. Regards, -- Sébastien Miquel [-- Attachment #2: Type: text/html, Size: 1536 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash 2022-01-26 17:49  Sébastien Miquel @ 2022-01-26 21:49  Tom Gillespie 2022-01-27 19:11  Sébastien Miquel 0 siblings, 1 reply; 21+ messages in thread From: Tom Gillespie @ 2022-01-26 21:49 UTC (permalink / raw) To: sebastien.miquel; +Cc: emacs-orgmode > The change is local and minor. We can't know that. Consider for example someone that has the following line somewhere in their files. #+begin_src org I spent$20 on food and was paid$-10 dollars by friends so I am down$10.
#+end_src
Yes =paid$-10= is probably a typo that should have a space in between, but it could still be in a file and cause an issue. The more likely case would be of someone that has$ in the
name of a variable that also uses dashes. For example if
I have a list of variable names such as
#+begin_src org
Text a $A_BASH_VAR Text b some-$-lisp-var
#+end_src

The proposed change would break any file with a pattern like
this.

We have no way of seeing every org file that users have
written so we don't know the extent of the impact, and thus
have to assume that there would be some impact. Making
such a change with an unknown blast radius in the midst of
considering removing support for that syntax altogether is
inviting disaster.

Best,
Tom

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
@ 2022-01-27  8:28      Ihor Radchenko
2022-01-27 19:15        Tim Cross
 (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
To: Rudolf Adamkovič; +Cc: Sébastien Miquel, emacs-orgmode, Eric S Fraga

> Let $r_i$ denote the $$i$$-th rotation of $t$ with a suffix of $\ell|t|$
> characters deleted, for […]
>
> Me, if I could, I would pay money for this feature, for it would allow
> me to use $$consistently, focusing on mathematics instead of markup > idiosyncrasies of "rotation i" versus "$$i$$-th rotation". Would it improve things for you if we change how $$...$$ _looks_ in Org buffers? The problem with parsing is more than just supporting i-th and similar. For example, AMS style guide explicitly advises against using i-th in favour of ith [1]: Do not hyphenate “th” expressions: xth, not x-th or xth . We can theoretically make a change to support "-", but then it will be logical to support ith as well. (If we don't some users will still be confused after trying to write ith and then not getting the expected results). In this question, it would make sense to implement all-or-everything approach. Otherwise, confusion (like raised in this thread) will be inevitable. However, from point of view of Org mode parser, supporting ith is a nightmare. Remember that Org mode is _not_ LaTeX and we have to support a lot more frivolous syntax (even in LaTeX, runaway  is often a source of cryptic compilation errors). Currently, we _must_ rely on heuristics to determine$$-style latex fragments. I do not know any way to support
$$syntax without creating deviations from LaTeX. Extending the heuristics will not resolve the underlying ambiguity of$$ syntax, just
hide it within even more obscure cases.

Given the raised concerns, may we solve the issue with too verbose
$$...$$ unambiguous syntax using the following approach:
1. Fontify $$...$$ replacing the brackets with a single character. For
example:

$$...$$ -> ⁅...⁆

2. Provide convenient way to input  brackets through
electric-pair-mode or trough org-cdlatex-mode.

Best,
Ihor

[1] https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-26 21:49      Tom Gillespie
@ 2022-01-27 19:11        Sébastien Miquel
0 siblings, 0 replies; 21+ messages in thread
From: Sébastien Miquel @ 2022-01-27 19:11 UTC (permalink / raw)
To: Tom Gillespie; +Cc: emacs-orgmode

Hi,

Tom Gillespie writes:
>> The change is local and minor.
> We can't know that.
I meant that the change to the syntax would be minor and local, with
respect to the linked syntax document.

> #+begin_src org
> I spent $20 on food and was paid$-10 dollars by friends so
> I am down $10. > #+end_src > [...] > #+begin_src org > Text a$A_BASH_VAR
> Text b some-$-lisp-var > #+end_src > > The proposed change would break any file with a pattern like > this. As you say, your first example is a typo. As for the second example, it's a very uncommon pattern, and if such variable names occur in a document, they should either be inside src blocks, or inside verbatim or code markers. In both case, there's no breakage with respect to parsing, export and tangling. The fontification may fail though. It wont fail if your src blocks are fontified natively, and the fontification of$…$can be globally disabled. > We have no way of seeing every org file that users have > written so we don't know the extent of the impact, and thus > have to assume that there would be some impact. Making > such a change with an unknown blast radius in the midst of > considering removing support for that syntax altogether is > inviting disaster. We can make an educated guess. It is quite likely that this change will fix more documents than it breaks. Hardly a disaster. Regards, -- Sébastien Miquel ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash 2022-01-27 8:28  Ihor Radchenko @ 2022-01-27 19:15  Tim Cross 2022-01-28 14:37  Max Nikulin 2022-01-27 19:34  Sébastien Miquel 2022-02-01 21:00  Rudolf Adamkovič 2 siblings, 1 reply; 21+ messages in thread From: Tim Cross @ 2022-01-27 19:15 UTC (permalink / raw) To: emacs-orgmode Ihor Radchenko <yantar92@gmail.com> writes: > Rudolf Adamkovič <salutis@me.com> writes: > >> Let$r_i$denote the $$i$$-th rotation of$t$with a suffix of$\ell|t|$>> characters deleted, for […] >> >> Me, if I could, I would pay money for this feature, for it would allow >> me to use $$consistently, focusing on mathematics instead of markup >> idiosyncrasies of "rotation i" versus "$$i$$-th rotation". > > Would it improve things for you if we change how $$...$$ _looks_ in Org > buffers? > > The problem with parsing is more than just supporting i-th and > similar. For example, AMS style guide explicitly advises against using > i-th in favour of ith [1]: > > Do not hyphenate “th” expressions: xth, not x-th or xth . > > We can theoretically make a change to support "-", but then it will be > logical to support ith as well. (If we don't some users will still be > confused after trying to write ith and then not getting the expected > results). In this question, it would make sense to implement > all-or-everything approach. Otherwise, confusion (like raised in this > thread) will be inevitable. > > However, from point of view of Org mode parser, supporting ith is a > nightmare. Remember that Org mode is _not_ LaTeX and we have to support > a lot more frivolous syntax (even in LaTeX, runaway is often a source > of cryptic compilation errors). Currently, we _must_ rely on heuristics > to determine$$-style latex fragments. I do not know any way to support > $$syntax without creating deviations from LaTeX. Extending the > heuristics will not resolve the underlying ambiguity of$$ syntax, just > hide it within even more obscure cases. > > Given the raised concerns, may we solve the issue with too verbose > $$...$$ unambiguous syntax using the following approach: > 1. Fontify $$...$$ replacing the brackets with a single character. For > example: > > $$...$$ -> ⁅...⁆ > > 2. Provide convenient way to input  brackets through > electric-pair-mode or trough org-cdlatex-mode. > > Best, > Ihor > > [1] https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf +1. Just my$0.02 worth -

I think this is the right approach. Retaining support for $..$ doesn't
seem feasible given all the complexities it brings with it. The main
objections to the alternative appear to centre around readability and
inconvenience of having to type additional characters or dealing with
muscle memory use to $...$. These are essentially interface issues and I
think we can largely address them using existing Emacs facilities. This
will reduce the change impact to that sub-set of org users accustomed to
$...$ while bringing the benefit of a cleaner and potentially more
efficient parser to all org users.

If we do deprecate support for $...$, it might also be a good idea to
see if we can add a utility function which would make it easier for
people to migrate existing documents to the new/alternative syntax. For
the same reason it is hard to reliably parse $...$ syntax, we probably
can't automate that transition, but we should be able to reduce the effort
required to update existing documents.

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-27  8:28      Ihor Radchenko
2022-01-27 19:15        Tim Cross
@ 2022-01-27 19:34        Sébastien Miquel
2 siblings, 0 replies; 21+ messages in thread
From: Sébastien Miquel @ 2022-01-27 19:34 UTC (permalink / raw)

Hi,

> We can theoretically make a change to support "-", but then it will be
> logical to support $i$th as well. (If we don't some users will still be
> confused after trying to write $i$th and then not getting the expected
> results).

I disagree.
1. The $…$- pattern is also used for other common constructions, such
as $n$-dimensional, $K$-lipschitz, etc. As for $n$−th vs $n$th, both
are commonly used. In french, $n$− is the correct one.
2. It does not logically follow that we should support $i$th as well,
since, as you point out, it'd be impossible. One argument for the
patch is that is it very simple.
3. The $n$th construction failing is not as confusing. One
understands quickly what the limitation is, and several
workarounds are available, whereas there's no good reason for the
$n$− limitation, and it's harder to think of a workaround.

I should mention that the zero-width space character can be used to
work around both limitations.

> Given the raised concerns, may we solve the issue with too verbose
> $$...$$ unambiguous syntax using the following approach:
> 1. Fontify $$...$$ replacing the brackets with a single character. For
>     example:
>
>        $$...$$ -> ⁅...⁆
>
> 2. Provide convenient way to input  brackets through
>     electric-pair-mode or trough org-cdlatex-mode.
If the $…$ syntax were to be deprecated, this would be a nice
addition, indeed. As a user, I find it quite satisfactory (with some
added utility to easily switch between the $$…$$ and $…$ syntax).
Some possible drawbacks :
- are the display hacks scalable in a large document, with many LaTeX
snippets ?
- this feature may still be hard to discover, turn on and use by
users more concerned with mathematical content and less familiar
with emacs features such as fontification, automatic insertion of
complex delimiters and whatnot.
- hiding the syntax feels a bit weird, although it is already
done with emphasis markers.

With respect to the possible deprecation of the $…$ syntax, the
drawbacks and complexity of this alternative should be weighted
against those of the current $…$ syntax, but no one has really spelled
out what the latter are. We're trading complexity here for complexity
there, fixing the false positives (but how common are they ?) and the
false negatives (which can be an annoyance while writing a snippet).

Thank you for bringing this up,

Regards,

--
Sébastien Miquel

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-27 19:15        Tim Cross
@ 2022-01-28 14:37          Max Nikulin
2022-01-28 16:37            Timothy
From: Max Nikulin @ 2022-01-28 14:37 UTC (permalink / raw)
To: emacs-orgmode

On 28/01/2022 02:15, Tim Cross wrote:
>
> If we do deprecate support for $...$, it might also be a good idea to
> see if we can add a utility function which would make it easier for
> people to migrate existing documents to the new/alternative syntax. For
> the same reason it is hard to reliably parse $...$ syntax, we probably
> can't automate that transition, but we should be able to reduce the effort
> required to update existing documents.

There is no point to discuss deprecation of $...$ and $$...$$ while
usage of such constructs is not discouraged by the org manual info
"(org) LaTeX fragmets" https://orgmode.org/manual/LaTeX-fragments.html
and by the compact guide https://orgmode.org/guide/Embedded-LaTeX.html

Even though org syntax says that support of these constructs ought to be
removed, users expect that they should work well.

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-28 14:37          Max Nikulin
@ 2022-01-28 16:37            Timothy
2022-01-30 15:28              Max Nikulin
From: Timothy @ 2022-01-28 16:37 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hi Max,

> There is no point to discuss deprecation of $…$ and ... while usage of
> such constructs is not discouraged by the org manual

Isn’t the point of discussing depreciation now that we’d change the manual etc.
to discourage it? 😛

FWIW, I have an extra 2c to add: I think that there’s a danger in having $…$
/almost/ behave like LaTeX, as the closer it is the more surprising the edge cases
are, and due to the nature of Org there will /always/ be a collection of edge
cases with $…$. By comparison, $$…$$ has much less ’surprising’ behaviour.

>> If we do deprecate support for $…$, it might also be a good idea to
>> see if we can add a utility function which would make it easier for
>> people to migrate existing documents to the new/alternative syntax. For
>> the same reason it is hard to reliably parse $…$ syntax, we probably
>> can’t automate that transition, but we should be able to reduce the effort
>> required to update existing documents.

Tim, as mentioned before I’m strongly in favour of a ~half decade transition
including utility functions to shift existing TeX constructs to LaTeX, and
adding warnings, well before dropping support.

All the best,
Timothy

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-28 16:37            Timothy
@ 2022-01-30 15:28              Max Nikulin
2022-02-01 14:26                Max Nikulin
From: Max Nikulin @ 2022-01-30 15:28 UTC (permalink / raw)
To: emacs-orgmode

On 28/01/2022 23:37, Timothy wrote:
>
>> There is no point to discuss deprecation of $…$ and ... while usage of
>> such constructs is not discouraged by the org manual
>
> Isn’t the point of discussing depreciation now that we’d change the manual etc.
> to discourage it? 😛

It is funny that nobody have checked what the manual actually states:

> Text within the usual LaTeX math delimiters. To avoid conflicts with
> currency specifications, single ‘$’ characters are only recognized as > math delimiters if the enclosed text contains at most two line breaks, > is directly attached to the ‘$’ characters with no whitespace in
> between, and if the closing ‘$’ is followed by whitespace, punctuation > or a dash. For the other delimiters, there is no such restriction, so ^^^^^^ > when in doubt, use ‘$$...$$’ as inline math delimiters. I have no idea whether it ever worked in such way. So either the manual must be updated or a fix must be committed. False positive with the proposed patch: > Balance decreased from$10 to negative value ($-2 approximately) certainly it is more rare than$n$-th valid case. >>> If we do deprecate support for$…$, it might also be a good idea to >>> see if we can add a utility function which would make it easier for >>> people to migrate existing documents to the new/alternative syntax. For >>> the same reason it is hard to reliably parse$…$syntax, we probably >>> can’t automate that transition, but we should be able to reduce the effort >>> required to update existing documents. > > Tim, as mentioned before I’m strongly in favour of a ~half decade transition > including utility functions to shift existing TeX constructs to LaTeX, and > adding warnings, well before dropping support. That period should be started when manual is updated. Functions updating old file to the current syntax is an interesting idea, but it assumes a copy of org-element as it was in that old org version. ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash 2022-01-30 15:28  Max Nikulin @ 2022-02-01 14:26  Max Nikulin 0 siblings, 0 replies; 21+ messages in thread From: Max Nikulin @ 2022-02-01 14:26 UTC (permalink / raw) To: emacs-orgmode manual states: > >> Text within the usual LaTeX math delimiters. To avoid conflicts with >> currency specifications, single ‘$’ characters are only recognized as
>> math delimiters if the enclosed text contains at most two line breaks,
>> is directly attached to the ‘$’ characters with no whitespace in >> between, and if the closing ‘$’ is followed by whitespace, punctuation
>> or a dash. For the other delimiters, there is no such restriction, so
>       ^^^^^^
>> when in doubt, use ‘$$...$$’ as inline math delimiters.

It is even more interesting. Support of dash likely was unintentionally
lost in the following commit:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6779f8f424883ffd202e24cbd8bb4e241db294b0
that generalizes handling of punctuation, unfortunately dash and
apostrophe are not always belong to punctuation symbols in *text* modes.
That commit even updates manual to a less precise phrase, however .texi
file only, so the change was lost. Nicolas later restored apostrophe in
the commit c0369a798470763f8f3c69cf2079c3a194635feb

> False positive with the proposed patch:
>
>  > Balance decreased from $10 to negative value ($-2 approximately)
>
> certainly it is more rare than $n$-th valid case.
>
>> Tim, as mentioned before I’m strongly in favour of a ~half decade
>> transition

broken so maybe it is better to fix current state by updating the manual
(including bugfix branch) and by adding some tests.

P.S. It is deja vu, I almost certainly saw quite recent discussions
whether punctuation may be handled in some regexps in more generic way.
Consequences may be similar in respect to characters that are almost
punctuation...

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-01-27 19:15        Tim Cross
2022-01-27 19:34        Sébastien Miquel
@ 2022-02-01 21:00        Rudolf Adamkovič
2022-02-02  2:48          João Pedro de Amorim Paula
To: Ihor Radchenko; +Cc: Eric S Fraga, Sébastien Miquel, emacs-orgmode

> We can theoretically make a change to support "-", but then it will be
> logical to support $i$th as well. […]

I do not know about others, but supporting the dash alone would mean a
world to me.  In fact, I never use  for anything else in all my Org
documents.  That dash, though, it constantly gets into my way.

> 1. Fontify $$...$$ replacing the brackets with a single character. For
>    example:
>
>       $$...$$ -> ⁅...⁆

Me, I cannot use any of these "pretty" features because, simply put,
they break plain text.  For example, they cause misaligned tables and
make the text overflow the fill column, which I keep at 72 columns.

> 2. Provide convenient way to input  brackets through
>    electric-pair-mode or trough org-cdlatex-mode.

This would help a bit.

Rudy
--
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass, 1871/1872

Studenohorská 25
84103 Bratislava
Slovakia

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-02-01 21:00        Rudolf Adamkovič
@ 2022-02-02  2:48          João Pedro de Amorim Paula
2022-02-06 19:45            Rudolf Adamkovič
From: João Pedro de Amorim Paula @ 2022-02-02  2:48 UTC (permalink / raw)
Cc: Sébastien Miquel, emacs-orgmode, Eric S Fraga

On 01 February 2022 22:00, Rudolf Adamkovič <salutis@me.com> wrote:

> Me, I cannot use any of these "pretty" features because, simply put,
> they break plain text.  For example, they cause misaligned tables and
> make the text overflow the fill column, which I keep at 72 columns.

I know that this is a bit divergent from the original subject -- and
also keep in mind that this shouldn't be considered a solution to the
problem, given that it should be considered for all users with different
fonts --, but there are fonts that enforce Unicode (all characters, from
what I understand, Unicode included) characters to be exactly 1 unit
width, i.e. Unicode characters are the same widths as other characters.
At least I can guarantee that any of the Term (all characters are the
same length, but has ligatures) or Fixed (same as Term but no ligatures)
for Iosekva [1] have this given property.

[1] https://typeof.net/Iosevka/

Best regards,

--
João Pedro de Amorim Paula

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-02-02  2:48          João Pedro de Amorim Paula
@ 2022-02-06 19:45            Rudolf Adamkovič
2022-02-07  0:00              Tim Cross
To: João Pedro de Amorim Paula, Ihor Radchenko
Cc: Eric S Fraga, Sébastien Miquel, emacs-orgmode

João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> writes:

> On 01 February 2022 22:00, Rudolf Adamkovič <salutis@me.com> wrote:
>
>> Me, I cannot use any of these "pretty" features because, simply put,
>> they break plain text.  For example, they cause misaligned tables and
>> make the text overflow the fill column, which I keep at 72 columns.
>
> […] there are fonts that enforce Unicode (all characters, from what I
> understand, Unicode included) characters to be exactly 1 unit width,
> i.e. Unicode characters are the same widths as other characters.  At
> least I can guarantee that any of the Term (all characters are the
> same length, but has ligatures) or Fixed (same as Term but no
> ligatures) for Iosekva [1] have this given property.
>
> [1] https://typeof.net/Iosevka/

Thank you for sharing!  I use the amazing "Hack" typeface [1].  Then, I
fail to understand how the font changes the fact that Org breaks "the
promise of plain text" in this regard.

For example, Org can hide its emphasis markers.  Later, one opens the
file in another editor and sees the truth.  The lines go over the fill
column, the tables have misaligned columns, and so on.

Rudy

[1] https://sourcefoundry.org/hack/
--
"Strange as it may sound, the power of mathematics rests on its evasion
of all unnecessary thought and on its wonderful saving of mental
operations."
-- Ernst Mach, 1838-1916

Studenohorská 25
84103 Bratislava
Slovakia

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

* Re: [PATCH] Add support for $…$ latex fragments followed by a dash
2022-02-06 19:45            Rudolf Adamkovič
@ 2022-02-07  0:00              Tim Cross
0 siblings, 0 replies; 21+ messages in thread
From: Tim Cross @ 2022-02-07  0:00 UTC (permalink / raw)
Cc: João Pedro de Amorim Paula, Sébastien Miquel,
emacs-orgmode, Ihor Radchenko, Eric S Fraga

> João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> writes:
>
>> On 01 February 2022 22:00, Rudolf Adamkovič <salutis@me.com> wrote:
>>
>>> Me, I cannot use any of these "pretty" features because, simply put,
>>> they break plain text.  For example, they cause misaligned tables and
>>> make the text overflow the fill column, which I keep at 72 columns.
>>
>> […] there are fonts that enforce Unicode (all characters, from what I
>> understand, Unicode included) characters to be exactly 1 unit width,
>> i.e. Unicode characters are the same widths as other characters.  At
>> least I can guarantee that any of the Term (all characters are the
>> same length, but has ligatures) or Fixed (same as Term but no
>> ligatures) for Iosekva [1] have this given property.
>>
>> [1] https://typeof.net/Iosevka/
>
> Thank you for sharing!  I use the amazing "Hack" typeface [1].  Then, I
> fail to understand how the font changes the fact that Org breaks "the
> promise of plain text" in this regard.
>
> For example, Org can hide its emphasis markers.  Later, one opens the
> file in another editor and sees the truth.  The lines go over the fill
> column, the tables have misaligned columns, and so on.
>

The promise of plain text has no inherent promise regarding alignment,
line wrapping etc. The promise of plain text is simply that - a promise
that org files will be just plain text rather than some application
specific format like many other systems (MS Word, LibreOffice, etc).
Provided you can still edit the file with a plain text editor, org has
not broken its promise.

Ironically, it is this plain text basis of org files which makes
on-going support of $..$ (and any extension) so problematic. Without
this restriction, org files could have a format where elements were
'tagged' to remove ambiguity and simplify the parsing process. However,
this would of course mean that either you had to edit the file within
org mode or you would have to be intimately familiar with the internal
structure of org mode files and use an editor which made
editing/updating the internal structure possible. To be very clear, I am
NOT advocating that org should adopt some form of internal tagging or
structure. I'm only attempting to highlight that having a system which
aims to maintain the data source in plain text comes at a cost.

In LaTex et. al. $..$ works well because $is a special character. If you want a literal$, you have to escape it. In org, $is not a special character. This means we need complex regular expressions in order to identify when$ is being used for LaTex specific markup and when it is
being used in other contexts (e.g. literal $sign, variable name). These regular expressions are difficult to get right, error prone and above all, incur a significant performance hit. Extending the syntax further to support$..$- simply makes the situation worse by adding further complexity. So far, all the arguments against removal of support for$..$are based on inconvenience and reduced readability associated with the alternatives. Both legitimate concerns. For many, the proposed change may seem to be just inconvenient change for no real purpose because they don't deal with the complexities inherent in making$..$work and for others, change is something they would always prefer to avoid. In this instance, I feel we really need to listen to those who put in such a dedicated effort in maintaining org mode and accept their position that sustaining$..$syntax going forward is problematic and focus on what can be done to mitigate the impact from this change, make the alternative syntax more convenient and address the readability issues. ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash @ 2022-01-27 18:54 autofrettage 0 siblings, 0 replies; 21+ messages in thread From: autofrettage @ 2022-01-27 18:54 UTC (permalink / raw) To: emacs-orgmode Rudolf wrote: > Further,  brings 100% more characters than$$, resulting in more noise in the sentence. Now where did I put my APL keyboard... Cheers Rasmus ^ permalink raw reply [flat|nested] 21+ messages in thread * Re: [PATCH] Add support for$…$latex fragments followed by a dash @ 2022-01-25 18:09 Goran Zuzic 0 siblings, 0 replies; 21+ messages in thread From: Goran Zuzic @ 2022-01-25 18:09 UTC (permalink / raw) To: sebastien.miquel; +Cc: emacs-orgmode, e.fraga [-- Attachment #1: Type: text/plain, Size: 242 bytes --] On a personal note, I would be very happy to see this patch merged. It has been annoying me for years, see for instance this thread: https://emacs.stackexchange.com/questions/37207/org-latex-fragment-succeeded-by-a-dash-is-not-showing Goran [-- Attachment #2: Type: text/html, Size: 406 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread end of thread, other threads:[~2022-02-07 1:03 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-24 16:42 [PATCH] Add support for$…\$ latex fragments followed by a dash Sébastien Miquel
2022-01-25  7:56  Eric S Fraga
2022-01-25 10:32    Sébastien Miquel
2022-01-26 17:15    Rudolf Adamkovič
2022-01-27 19:15        Tim Cross
2022-01-28 14:37          Max Nikulin
2022-01-28 16:37            Timothy
2022-01-30 15:28              Max Nikulin
2022-02-01 14:26                Max Nikulin
2022-01-27 19:34        Sébastien Miquel
2022-02-01 21:00        Rudolf Adamkovič
2022-02-02  2:48          João Pedro de Amorim Paula
2022-02-06 19:45            Rudolf Adamkovič
2022-02-07  0:00              Tim Cross
2022-01-26  6:33  Tom Gillespie
2022-01-26 17:49    Sébastien Miquel
2022-01-26 21:49      Tom Gillespie
2022-01-27 19:11        Sébastien Miquel
2022-01-25 18:09 Goran Zuzic
2022-01-27 18:54 autofrettage


Code repositories for project(s) associated with this 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).`