GNU bug report logs - #41559
texmathp reports false negatives

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41559 in the body.
You can then email your comments to 41559 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: TEC <tec <at> tecosaur.com>
To: bug-auctex <at> gnu.org
Subject: texmathp reports false negatives
Date: Wed, 27 May 2020 13:25:09 +0800

Hello!

Org-mode recently added support for editing LaTeX fragments in the 
minibuffer (https://code.orgmode.org/bzg/org-mode/commit/f5c47d8). 
While I have previously noticed occasions where (texmathp) has 
failed to pick up math mode from LaTeX inline deliminators (by 
which I mean \(\) and \[\]), with this it's become increacingly 
apparent to me. Perhaps there are issues caused by not having a 
full LaTeX file with \begin{document} etc., but this doesn't seem 
to be an issue with 'old' TeX deliminators ($…$ and $$…$$).

Consider the following examples

#+BEGIN_EXPORT latex \(a\) #+END_EXPORT

and

#+BEGIN_EXPORT latex \[
   a
\] #+END_EXPORT

In both cases (texmathp) returns nil. However if I replace these 
LaTeX deliminators with their TeX counterparts, (texmathp) rteurns 
t, correctly.

When using say CDLaTeX it automatically inserts deliminators if 
(texmathp) returns nil, this is obviously problematic, as it 
causes 'nesting' of deliminators, I.e. \(\(\alpha\)\).

Interestingly, once a level of nesting has been performed, 
(texmathp) returns t.

I hope that someone may be willing to tweak texmathp and have it 
produce correct results in these cases.

Regards,

Timothy.

Message #8 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: TEC <tec <at> tecosaur.com>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 12:02:44 +0900

Hi,

>>>>> TEC <tec <at> tecosaur.com> writes:
> Consider the following examples

> #+BEGIN_EXPORT latex \(a\) #+END_EXPORT

> and

> #+BEGIN_EXPORT latex \[
>    a
> \] #+END_EXPORT

> In both cases (texmathp) returns nil. However if I replace these LaTeX
> deliminators with their TeX counterparts, (texmathp) rteurns t,
> correctly.

It doesn't reproduce on my side. I saved a file with the contents
----------------------------------------------------------------------
#+BEGIN_EXPORT latex \(a\) #+END_EXPORT

#+BEGIN_EXPORT latex \[
   a
\] #+END_EXPORT
----------------------------------------------------------------------
and evaluated (texmathp) by M-: at each position before "a". Both
returned t for me.

Regards,
Ikumi Keita

Message #11 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: TEC <tec <at> tecosaur.com>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 13:32:25 +0900

Hi Timothy,

>>>>> TEC <tec <at> tecosaur.com> writes:
> I'm on
> - AucTeX 12.2.0 (fafa28d)
> - Emacs 26.3
> - Linux 5.6.13

It doesn't seem that there is significant difference. I'm on
GNU Emacs 26.3 (build 1, x86_64-unknown-freebsd12.0, GTK+ Version 3.24.9)
AUCTeX-date "2020-05-17"

> Whether I put mu cursor before or after a latex-mode buffer simply
> containing
> \(a\) I find (texmathp) returns nil.

I'd like to ask the precise position of the cursor. Does "before or
after" means "just before" and "just after"? In other words, was the
blinking rectangle of the cursor just on the first backslash and just
after the closing paren, respectively, of "\(a\)"? If so, `texmathp'
does return nil, and that's the expected way in which that function
operates.

Regards,
Ikumi Keita

Message #14 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: TEC <tec <at> tecosaur.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 11:23:57 +0800

Ikumi Keita <ikumi <at> ikumi.que.jp> writes: 

> It doesn't reproduce on my side. I saved a file with the 
> contents 
> ---------------------------------------------------------------------- 
> #+BEGIN_EXPORT latex \(a\) #+END_EXPORT 
> 
> #+BEGIN_EXPORT latex \[ 
>    a 
> \] #+END_EXPORT 
> ---------------------------------------------------------------------- 

It may be worth clarifying that in those examples I created two 
blank buffers
with the given text as the only contents.

> and evaluated (texmathp) by M-: at each position before "a". 
> Both returned t for me. 

Interesting though. Assuming you did the same as me, this directly 
contradicts
with my results. I'm on
- AucTeX 12.2.0 (fafa28d)
- Emacs 26.3
- Linux 5.6.13

Whether I put mu cursor before or after a latex-mode buffer simply 
containing
\(a\) I find (texmathp) returns nil.

> Regards, Ikumi Keita 

Thanks for testing, hopefully the extra details may help better 
identify the issue.

Timothy.

Message #17 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: TEC <tec <at> tecosaur.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 12:33:29 +0800

Ikumi Keita <ikumi <at> ikumi.que.jp> writes: 

>> Whether I put mu cursor before or after a latex-mode buffer 
>> simply containing \(a\) I find (texmathp) returns nil. 
> 
> I'd like to ask the precise position of the cursor. Does "before 
> or after" means "just before" and "just after"? In other words, 
> was the blinking rectangle of the cursor just on the first 
> backslash and just after the closing paren, respectively, of 
> "\(a\)"? If so, `texmathp' does return nil, and that's the 
> expected way in which that function operates. 

Ooops, that's poor wording on my part. Should have been:
 Whether I put my cursor before or after "a" in a latex-mode 
 buffer
 simply containing \(a\) I find (texmathp) returns nil.

I.e. With "|" representing the cursor, I've tried \(|a\) and 
\(a|\)

Hope that clarifies,

Timothy.

Message #20 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: TEC <tec <at> tecosaur.com>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 13:55:23 +0900

>>>>> TEC <tec <at> tecosaur.com> writes:
> Ooops, that's poor wording on my part. Should have been:
>  Whether I put my cursor before or after "a" in a latex-mode buffer
>  simply containing \(a\) I find (texmathp) returns nil.

> I.e. With "|" representing the cursor, I've tried \(|a\) and \(a|\)

> Hope that clarifies,

Thanks, it does reproduce. It seems that `texmathp' returns nil if
"\(a\)" is at the beginning of the buffer. I'll see if I can fix it.

Regards,
Ikumi Keita

Message #23 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: TEC <tec <at> tecosaur.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 12:56:15 +0800

Ikumi Keita <ikumi <at> ikumi.que.jp> writes: 

> Thanks, it does reproduce. It seems that `texmathp' returns nil 
> if "\(a\)" is at the beginning of the buffer. I'll see if I can 
> fix it. 

That's great to hear. Thank you very much for taking a look at 
this.
With the new org-edit-special for inline LaTeX fragments, having 
this
work smoothly would be marvelous :)

If you'd also be willing to check out the
\[
   a
\]
case as well, that would be similarly appriciated.

Thanks,

Timothy.

Message #26 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: TEC <tec <at> tecosaur.com>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 15:28:50 +0900

Hi Timothy,

>>>>> TEC <tec <at> tecosaur.com> writes:
> That's great to hear. Thank you very much for taking a look at this.
> With the new org-edit-special for inline LaTeX fragments, having this
> work smoothly would be marvelous :)

> If you'd also be willing to check out the
> \[
>    a
> \]
> case as well, that would be similarly appriciated.

I installed a fix in the git repo. You can try it out with the following
patch.

Regards,
Ikumi Keita

diff --git a/texmathp.el b/texmathp.el
index ba5aba39..723623bc 100644
--- a/texmathp.el
+++ b/texmathp.el
@@ -185,13 +185,11 @@ customize (customize calls it when setting the variable)."
 		      ((memq type '(sw-toggle))      'togglers)))
       (set var (cons (car entry) (symbol-value var))))
     (setq texmathp-onoff-regexp
-	  (concat "[^\\\\]\\("
-		  (mapconcat 'regexp-quote switches "\\|")
-		  "\\)")
+	  (concat "\\(?:[^\\\\]\\|\\`\\)"
+		  (regexp-opt switches t))
 	  texmathp-toggle-regexp
-	  (concat "\\([^\\\\\\$]\\|\\`\\)\\("
-		  (mapconcat 'regexp-quote togglers "\\|")
-		  "\\)"))))
+	  (concat "\\([^\\\\\\$]\\|\\`\\)"
+		  (regexp-opt togglers t)))))
 
 (defcustom texmathp-tex-commands nil
   "List of environments and macros influencing (La)TeX math mode.
@@ -287,14 +285,17 @@ See the variable `texmathp-tex-commands' about which commands are checked."
 
     ;; Select the nearer match
     (and env-match (setq match env-match))
-    (and mac-match (> (cdr mac-match) (cdr match)) (setq match mac-match))
+    ;; Use `>=' instead of `>' in case called inside \ensuremath{..}
+    ;; beginning just at (point-min).
+    (and mac-match (>= (cdr mac-match) (cdr match)) (setq match mac-match))
     (setq math-on (memq (nth 1 (assoc (car match) texmathp-tex-commands1))
 			'(env-on arg-on)))
 
     ;; Check for switches
     (and (not math-on)
 	 (setq sw-match (texmathp-match-switch bound))
-	 (> (cdr sw-match) (cdr match))
+	 ;; Use `>=' instead of `>' by similar reason as above. (bug#41559)
+	 (>= (cdr sw-match) (cdr match))
 	 (eq (nth 1 (assoc (car sw-match) texmathp-tex-commands1)) 'sw-on)
 	 (setq match sw-match math-on t))
 

Message #29 received at 41559 <at> debbugs.gnu.org (full text, mbox):

From: TEC <tec <at> tecosaur.com>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 41559 <at> debbugs.gnu.org
Subject: Re: bug#41559: texmathp reports false negatives
Date: Thu, 28 May 2020 14:43:15 +0800

Ikumi Keita <ikumi <at> ikumi.que.jp> writes: 

> I installed a fix in the git repo. You can try it out with the 
> following patch. 

Thank you very much for doing this. I'll take a look :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.