Re: Bug: LaTeX inline maths expression \(+\) wrongly toggles strike-through face

Re: Bug: LaTeX inline maths expression \(+\) wrongly toggles strike-through face

[Firmin Martin]

Thank you Tomas, it works like a charm! Hope that it will be patched.

Best,

Firmin Martin

Bug: LaTeX inline maths expression \(+\) wrongly toggles strike-through face

[Firmin Martin]

Consider the following lines: 
- $+$ foobar $+$
- \[+\] foobar \[+\]
- $$+$$ foobar $$+$$
- \(+\) foobar \(+\)
Each of them is correct LaTeX inline/display maths expressions, but only the
  last one toggles strike-through face when it shouldn't. 

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2020-10-16
Package: Org mode version 9.4 (9.4-53-gc97446-elpa)

Best,

Firmin Martin

Re: Bug: LaTeX inline maths expression \(+\) wrongly toggles strike-through face

[tomas]

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

On Wed, Dec 02, 2020 at 03:19:27AM +0100, Firmin Martin wrote:
> 
> Consider the following lines: 
> - $+$ foobar $+$
> - \[+\] foobar \[+\]
> - $$+$$ foobar $$+$$
> - \(+\) foobar \(+\)
> Each of them is correct LaTeX inline/display maths expressions, but only the
>   last one toggles strike-through face when it shouldn't. 
> 
> Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
>  of 2020-10-16
> Package: Org mode version 9.4 (9.4-53-gc97446-elpa)

That's interesting. Happens to me too -- but I don't understand why
the first thre are /not/ rendered as strike-through. The relevant
variables are

 - org-emphasis-regexp-components

in my installation:

   org-emphasis-regexp-components is a variable defined in ‘org.el’.
   Its value is
   ("-[:space:]('\"{" "-[:space:].,:!?;'\")}\\[" "[:space:]" "." 5)
   
   Documentation:
   Components used to build the regular expression for emphasis.
   This is a list with five entries.  Terminology:  In an emphasis string
   like " *strong word* ", we call the initial space PREMATCH, the final
   space POSTMATCH, the stars MARKERS, "s" and "d" are BORDER characters
   and "trong wor" is the body.  The different components in this variable
   specify what is allowed/forbidden in each part:
   
   pre          Chars allowed as prematch.  Beginning of line will be allowed too.
   post         Chars allowed as postmatch.  End of line will be allowed too.
   border       The chars *forbidden* as border characters.
   body-regexp  A regexp like "." to match a body character.  Don’t use
                non-shy groups here, and don’t allow newline here.
   newline      The maximum number of newlines allowed in an emphasis exp.

(I changed the value of newline to 5). Note `border' is just "[[:space:]]",
so I'd expect '$', '\' and '$' (for the first three examples) to be "allowed"
borders, and

 - org-emph-re

which is calculated from the above, and in my box, not suprprisingly,
is

     "\\([-[:space:]('\"{]\\|^\\)\\(\\([*/_+]\\)\\([^[:space:]]\\|[^[:space:]].*?\\(?:
   .*?\\)\\{0,5\\}[^[:space:]]\\)\\3\\)\\([-[:space:].,:!?;'\")}\\[]\\|$\\)"

...which would confirm my expectation above. So why are the three
examples not rendered as overstrike? There seems to be more magic
involved.

This happens for other emph markers, too.

To work around in your case, Martin, you could try to add a backslash
to your `org-emphasis-regexp-component's third element, like so:

  (setf (nth 3 org-emphasis-regexp-components) "\\\\[:space:]")

and reload Org to give it the chance to rebuild org-emph-re.

(Caveat: I didn't try it).

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]