GNU bug report logs -
#48365
13.0.11; Dollars in distinct comments trigger math mode highlighting in text in-between
Previous Next
Reported by: jfbu <jfbu <at> free.fr>
Date: Tue, 11 May 2021 19:18:01 UTC
Severity: normal
Found in version 13.0.11
Done: Ikumi Keita <ikumi <at> ikumi.que.jp>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48365 in the body.
You can then email your comments to 48365 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 19:18:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jfbu <jfbu <at> free.fr>
:
New bug report received and forwarded. Copy sent to
bug-auctex <at> gnu.org
.
(Tue, 11 May 2021 19:18:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Consider the following file:
% -*- coding: utf-8; mode: latex; -*-
% $
\def\foo_with_underscore{}
%
%
\def\foo_bar_foo_bar{}
% $
%
The presence of the $ sign in comments trigger math mode highlighting in between, as demonstrated in the attached screenshot
This happens in 13.0.11 (installed via Elpa) but did not happen at 12.2.0 and in fact I sticked with 12.2.0 for a long period because I had it still by accident on another computer where I had started lots of tex coding using very often $ in comments for some special reasons (it had another catcode) and when on my laptop which was with auctex from git I realized I could not work at all anymore because of this highlighting problem I simply rsync'ed from my other computer to my laptop as I had no time to devote to this issue. I thought perhaps the problem was with doctex-mode but today I see I can trigger it in latex-mode.
git bisect indicates first bad commit is
commit 6654955216a42936b87f76dc346aad829b1d52fb
Date: Wed Jun 3 01:44:32 2020 +0900
Use search-based fontification for $...$ (bug#33139)
Reading the commit message, I see there was extensive discussion and the change seems to have been discussed in depth and well-motivated. I wonder if you can confirm that you see the same at your locale as me.
Possibly relevant to this in my config are (but I did not try to change them)
'(font-latex-fontify-script (quote multi-level))
'(texmathp-search-n-paragraphs 0)
For the latter I dimly recall it was an old issue I had in doctex with highlighting too but I don't recall the details and it might be something else whatsoever. (I think last week I did try removing this to see if it affected the present issue but it did not).
[Message part 2 (text/html, inline)]
[Capture d’écran 2021-05-11 à 20.40.27.png (image/png, inline)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 19:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Jean-Francois,
> git bisect indicates first bad commit is
>
> commit 6654955216a42936b87f76dc346aad829b1d52fb
> Date: Wed Jun 3 01:44:32 2020 +0900
>
> Use search-based fontification for $...$ (bug#33139)
>
> Reading the commit message, I see there was extensive discussion and
> the change seems to have been discussed in depth and well-motivated. I
> wonder if you can confirm that you see the same at your locale as me.
Yes, I see the problem. I've pushed a fix which ignores $ in comments
just as it already ignored $ in verbatim contexts.
Could you please test and report back?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 19:46:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:07:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Tassilo,
Le 11/05/2021 à 21:26, Tassilo Horn a écrit :
> Hi Jean-Francois,
>
>> git bisect indicates first bad commit is
>>
>> commit 6654955216a42936b87f76dc346aad829b1d52fb
>> Date: Wed Jun 3 01:44:32 2020 +0900
>>
>> Use search-based fontification for $...$ (bug#33139)
>>
>> Reading the commit message, I see there was extensive discussion and
>> the change seems to have been discussed in depth and well-motivated. I
>> wonder if you can confirm that you see the same at your locale as me.
>
> Yes, I see the problem. I've pushed a fix which ignores $ in comments
> just as it already ignored $ in verbatim contexts.
>
> Could you please test and report back?
>
Yes, it works also in original context, not only in the short test file.
I realize now that after all I did work for a while with this problem
and I see one file where I have lots of extra $'s added in comments
to create pairs of $'s and avoid the propagation, I removed them
and no ill effect arose, the math highlighting was not applied.
But... wait...
Sadly, I now have another problem. Consider this:
\def\XINT:NE:f:noeval:from:braced:u:p #1#2%
{\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%
There is $ in there, and it triggers math mode highlighting which is a priori fine,
I can live with that *if I can constrain it to not extend beyond that line*
In the past I would control it this way:
\def\XINT:NE:f:noeval:from:braced:u:p #1#2%
{\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$
(observe the added $ at end of second line after the % comment character)
With your patch the %$ does not stop the math highlighting !
This is very problematic to me because that problem can't be solved (as I
could solve earlier one, especially now that I understand better what causes it,
via locating extra $'s inside comments)
by adding a commented out $.
It basically means I have not way to stop the highlighting from propagating...
Jean-François
> Bye,
> Tassilo
>
>
>
> _______________________________________________
> bug-auctex mailing list
> bug-auctex <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-auctex
>
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:22:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Le 11/05/2021 à 22:06, jfbu a écrit :
>
> Hi Tassilo,
>
> Le 11/05/2021 à 21:26, Tassilo Horn a écrit :
>> Hi Jean-Francois,
>>
>>> git bisect indicates first bad commit is
>>>
>>> commit 6654955216a42936b87f76dc346aad829b1d52fb
>>> Date:Â Â Wed Jun 3 01:44:32 2020 +0900
>>>
>>> Â Â Â Â Use search-based fontification for $...$ (bug#33139)
>>>
>>> Reading the commit message, I see there was extensive discussion and
>>> the change seems to have been discussed in depth and well-motivated. I
>>> wonder if you can confirm that you see the same at your locale as me.
>>
>> Yes, I see the problem. I've pushed a fix which ignores $ in comments
>> just as it already ignored $ in verbatim contexts.
>>
>> Could you please test and report back?
>>
>
> Yes, it works also in original context, not only in the short test file.
> I realize now that after all I did work for a while with this problem
> and I see one file where I have lots of extra $'s added in comments
> to create pairs of $'s and avoid the propagation, I removed them
> and no ill effect arose, the math highlighting was not applied.
>
> But... wait...
>
> Sadly, I now have another problem. Consider this:
>
> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
> Â Â Â {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%
>
> There is $ in there, and it triggers math mode highlighting which is a priori fine,
> I can live with that *if I can constrain it to not extend beyond that line*
>
> In the past I would control it this way:
>
> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
> Â Â Â {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$
>
> (observe the added $ at end of second line after the % comment character)
>
> With your patch the %$ does not stop the math highlighting !
>
> This is very problematic to me because that problem can't be solved (as I
> could solve earlier one, especially now that I understand better what causes it,
> via locating extra $'s inside comments)
> by adding a commented out $.
>
> It basically means I have not way to stop the highlighting from propagating...
>
not true. I could use another character than % and assign it catcode comment and
use it at end of line
but not that if I am "aguerri" enough for such manoeuvers this might not
be the case of all auctex users and they might do something like
\newcommand\foo{$} and then perhaps they have the same problem as me ?
% -*- coding: utf-8; mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}% $ does not help here
%
\def\foo_with_underscore{$}% <-- but math highlight will stop here
%
\def\foo_bar_foo_bar{}
%
%
> Jean-François
>
>
>
>> Bye,
>> Tassilo
>>
>>
>>
>> _______________________________________________
>> bug-auctex mailing list
>> bug-auctex <at> gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-auctex
>>
>
>
>
>
>
> _______________________________________________
> bug-auctex mailing list
> bug-auctex <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-auctex
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:43:02 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
> Sadly, I now have another problem. Consider this:
>
> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
> {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%
>
> There is $ in there, and it triggers math mode highlighting which is a
> priori fine, I can live with that *if I can constrain it to not extend
> beyond that line*
>
> In the past I would control it this way:
>
> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
> {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$
>
> (observe the added $ at end of second line after the % comment character)
>
> With your patch the %$ does not stop the math highlighting !
Now that you've mentioned it, I remember I wanted to do that change also
in the past and Keita-san stopped me from doing so for exactly this
reason.
I've pushed another commit which ignores $ in comments with the single
exception of the "% $ \n" workaround, i.e., a comment with just a $,
arbitrary spaces/tabs before or after the $, and then the end of the
line.
I'm not sure what is worse. The restriction to have at least balanced $
also in comments, or the now very restrictive workaround form. We'll
see if someone complains because that breaks his
% Workaround fix $.
comment fixes.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Le 11 mai 2021 à 22:33, Tassilo Horn <tsdh <at> gnu.org> a écrit :
>
>> Sadly, I now have another problem. Consider this:
>>
>> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
>> {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%
>>
>> There is $ in there, and it triggers math mode highlighting which is a
>> priori fine, I can live with that *if I can constrain it to not extend
>> beyond that line*
>>
>> In the past I would control it this way:
>>
>> \def\XINT:NE:f:noeval:from:braced:u:p #1#2%
>> {\detokenize{\romannumeral`$XINT_expr_null\expandafter#1}~expanded{{#2}}}%$
>>
>> (observe the added $ at end of second line after the % comment character)
>>
>> With your patch the %$ does not stop the math highlighting !
>
> Now that you've mentioned it, I remember I wanted to do that change also
> in the past and Keita-san stopped me from doing so for exactly this
> reason.
>
> I've pushed another commit which ignores $ in comments with the single
> exception of the "% $ \n" workaround, i.e., a comment with just a $,
> arbitrary spaces/tabs before or after the $, and then the end of the
> line.
>
> I'm not sure what is worse. The restriction to have at least balanced $
> also in comments, or the now very restrictive workaround form. We'll
> see if someone complains because that breaks his
>
> % Workaround fix $.
>
> comment fixes.
>
Hi Tassilo, sorry for causing all the trouble.
I pulled your commit and it works. For me that's working solution.
Would it make sense to apply these rules:
1. a $ in comments can never start math mode
2. but it can and will always stop math mode
Cheers,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Tue, 11 May 2021 20:52:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 06:17:01 GMT)
Full text and
rfc822 format available.
Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Jean-François,
>> I'm not sure what is worse. The restriction to have at least
>> balanced $ also in comments, or the now very restrictive workaround
>> form. We'll see if someone complains because that breaks his
>>
>> % Workaround fix $.
>>
>> comment fixes.
>
> Hi Tassilo, sorry for causing all the trouble.
Ah, always these users with their strange requirements and bogus
documents! ;-)
> I pulled your commit and it works. For me that's working solution.
>
> Would it make sense to apply these rules:
>
> 1. a $ in comments can never start math mode
> 2. but it can and will always stop math mode
Hm, at first I've thought that would be annoying but it seems to work
quite well. So I've pushed another commit implementing that. Please
report if that fits the bill.
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 06:17:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 06:40:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 48365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Jean and Tassilo,
>>>>> jfbu <jfbu <at> free.fr> writes:
>> Now that you've mentioned it, I remember I wanted to do that change also
>> in the past and Keita-san stopped me from doing so for exactly this
>> reason.
Yes, I did. ;-)
> Would it make sense to apply these rules:
> 1. a $ in comments can never start math mode
> 2. but it can and will always stop math mode
That is a clean idea and, fortunately, easy to implment. Could you test
the attached patch?
One remark: This patch does not follow rigorously your proposition. A $
in comments does not stop math mode if it is preceded by odd numbers of
$'s like this:
foo bar blah % \$
Regards,
Ikumi Keita
[patch (text/x-diff, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 06:43:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Oups, sorry, I sent my previous email just before I saw this message!
>>>>> Tassilo Horn <tsdh <at> gnu.org> writes:
> Hi Jean-François,
>>> I'm not sure what is worse. The restriction to have at least
>>> balanced $ also in comments, or the now very restrictive workaround
>>> form. We'll see if someone complains because that breaks his
>>>
>>> % Workaround fix $.
>>>
>>> comment fixes.
>>
>> Hi Tassilo, sorry for causing all the trouble.
> Ah, always these users with their strange requirements and bogus
> documents! ;-)
>> I pulled your commit and it works. For me that's working solution.
>>
>> Would it make sense to apply these rules:
>>
>> 1. a $ in comments can never start math mode
>> 2. but it can and will always stop math mode
> Hm, at first I've thought that would be annoying but it seems to work
> quite well. So I've pushed another commit implementing that. Please
> report if that fits the bill.
> Bye,
> Tassilo
> _______________________________________________
> bug-auctex mailing list
> bug-auctex <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-auctex
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 06:52:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
Hi Ikumi,
>> Would it make sense to apply these rules:
>
>> 1. a $ in comments can never start math mode
>> 2. but it can and will always stop math mode
>
> That is a clean idea and, fortunately, easy to implment. Could you test
> the attached patch?
I've committed a completely identical patch an hour ago with a diff just
in the comment explaining what we are doing. It's very encouraging when
we both have the very same idea, so I think, it cannot be too wrong. :-)
Thanks,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 07:23:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 48365 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Tassilo=Keita-san
Le 12 mai 2021 à 08:49, Tassilo Horn <tsdh <at> gnu.org> a écrit :
> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
>
> Hi Ikumi,
>
>>> Would it make sense to apply these rules:
>>
>>> 1. a $ in comments can never start math mode
>>> 2. but it can and will always stop math mode
>>
>> That is a clean idea and, fortunately, easy to implment. Could you test
>> the attached patch?
>
> I've committed a completely identical patch an hour ago with a diff just
> in the comment explaining what we are doing. It's very encouraging when
> we both have the very same idea, so I think, it cannot be too wrong. :-)
>
> Thanks,
> Tassilo
It is now revealed you are only one entity (perhaps an A.I. based
on quantum computing) pretending to be two humans only to
justify coverage of all time zones !
I have pulled the commit and it appears to work fine in my real-life
files (using doctex mode)
But I notice something weird when comparing effect on those two files
File A behaves as expected
% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%
File B seems to have a problem
% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%$
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%
In case of file B, which differs only by an added %$ at end of the \newcommand line,
the \newcommand for example is not highlighted
and the B line changes colors without applying script style,
see screenshot
In case of file B I was expecting the B line to be styled in math mode,
it only has its color it seems,
and I was not expecting \newcommand\foo to lose its highlighting,
Perhaps this is a symptom of something else?
Best,
Jean-François
[Message part 2 (text/html, inline)]
[Capture d’écran 2021-05-12 à 09.13.51.png (image/png, inline)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 07:59:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 48365 <at> debbugs.gnu.org (full text, mbox):
jfbu <jfbu <at> free.fr> writes:
> It is now revealed you are only one entity (perhaps an A.I. based on
> quantum computing) pretending to be two humans only to justify
> coverage of all time zones !
Gosh, we're uncovered!
> But I notice something weird when comparing effect on those two files
>
> File A behaves as expected
> % -*- mode: latex; -*-
> %
> \def\foo_with_underscore{}
> \newcommand\foo{$}%
> % a comment
> A foo_bar^bar{$}
> % a comment
> B foo_bar^bar{$}
> % a comment
> C foo_bar^bar
> $
> %
> %
>
> File B seems to have a problem
> % -*- mode: latex; -*-
> %
> \def\foo_with_underscore{}
> \newcommand\foo{$}%$
> % a comment
> A foo_bar^bar{$}
> % a comment
> B foo_bar^bar{$}
> % a comment
> C foo_bar^bar
> $
> %
> %
>
> In case of file B, which differs only by an added %$ at end of the
> \newcommand line, the \newcommand for example is not highlighted and
> the B line changes colors without applying script style, see
> screenshot
Yeah, it appears that if math mode goes out of hands, it may also have
effects on the fontification before. That has been the case already
before the latest commits.
But if you just add a space before the \newcommand and delete it again
to trigger re-fontification, it becomes fontified correctly. Not sure
why that is. I'll have a look when I find some spare time...
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 08:05:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Hi Tassilo
Le 12/05/2021 à 09:44, Tassilo Horn a écrit :
>> File B seems to have a problem
>> % -*- mode: latex; -*-
>> %
>> \def\foo_with_underscore{}
>> \newcommand\foo{$}%$
>> % a comment
>> A foo_bar^bar{$}
>> % a comment
>> B foo_bar^bar{$}
>> % a comment
>> C foo_bar^bar
>> $
>> %
>> %
>>
>> In case of file B, which differs only by an added %$ at end of the
>> \newcommand line, the \newcommand for example is not highlighted and
>> the B line changes colors without applying script style, see
>> screenshot
> Yeah, it appears that if math mode goes out of hands, it may also have
> effects on the fontification before. That has been the case already
> before the latest commits.
>
> But if you just add a space before the \newcommand and delete it again
> to trigger re-fontification, it becomes fontified correctly.
Yes, confirmed regarding \newcommand, however
- C-cC-n loses againt the fontification
- the B line still does not behave as expected, it should apply math styling,
but the subscripts are still on the baseline
> Not sure
> why that is. I'll have a look when I find some spare time...
No urgency here... I got the feeling my real-life files are ok so, from my
egotistical point of view the matter reached a satisfactory state for me,
the fate of the rest of the world does not interest me extraordinarily,
especially in those days where one has trashed with the approval
of the majority all basic principles
of defence and preservation of liberties, paving the road for very
grave evolutions awaiting us.
Best,
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 08:17:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 48365 <at> debbugs.gnu.org (full text, mbox):
> Yes, confirmed regarding \newcommand, however
>
> - C-cC-n loses againt the fontification
Right.
> - the B line still does not behave as expected, it should apply math
> styling, but the subscripts are still on the baseline
Ah, indeed. I've just seen that it was fontified as math but missed
that the scripts where not raised/lowered...
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 17:05:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Hi Jean,
>>>>> JF <jfbu <at> free.fr> writes:
>>> File B seems to have a problem
>>> % -*- mode: latex; -*-
>>> %
>>> \def\foo_with_underscore{}
>>> \newcommand\foo{$}%$
>>> % a comment
>>> A foo_bar^bar{$}
>>> % a comment
>>> B foo_bar^bar{$}
>>> % a comment
>>> C foo_bar^bar
>>> $
>>> %
>>> %
>>>
>>> In case of file B, which differs only by an added %$ at end of the
>>> \newcommand line, the \newcommand for example is not highlighted and
>>> the B line changes colors without applying script style, see
>>> screenshot
Fixed in the git repo. Please try.
Regards,
Ikumi Keita
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 19:07:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
>>>> In case of file B, which differs only by an added %$ at end of the
>>>> \newcommand line, the \newcommand for example is not highlighted and
>>>> the B line changes colors without applying script style, see
>>>> screenshot
>
> Fixed in the git repo. Please try.
Works like a charm, and good catch! How did you find the culprit?
With `jit-lock-debug-mode' I get as far as getting a message
Error running timer âjit-lock--debug-fontifyâ: (end-of-buffer)
which clearly tells we're trying to moe farther than end of buffer but
still there is no indication where we're doing that. Do you have some
trick I'm not aware of yet?
Bye,
Tassilo
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Wed, 12 May 2021 21:09:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 48365 <at> debbugs.gnu.org (full text, mbox):
Hi Keita-san
Le 12 mai 2021 à 19:04, Ikumi Keita <ikumi <at> ikumi.que.jp> a écrit :
>>>> % -*- mode: latex; -*-
>>>> %
>>>> \def\foo_with_underscore{}
>>>> \newcommand\foo{$}%$
>>>> % a comment
>>>> A foo_bar^bar{$}
>>>> % a comment
>>>> B foo_bar^bar{$}
>>>> % a comment
>>>> C foo_bar^bar
>>>> $
>>>> %
>>>> %
>>>>
>>>> In case of file B, which differs only by an added %$ at end of the
>>>> \newcommand line, the \newcommand for example is not highlighted and
>>>> the B line changes colors without applying script style, see
>>>> screenshot
>
> Fixed in the git repo. Please try.
Seems to work indeed
Somehow I have to hit C-cC-n to get fontification inclusive of subscripts getting lowered
to work after adding a $ at the end of \newcommand\foo{$}%
% -*- mode: latex; -*-
%
\def\foo_with_underscore{}
\newcommand\foo{$}%
% a comment
A foo_bar^bar{$}
% a comment
B foo_bar^bar{$}
% a comment
C foo_bar^bar
$
%
%
but all looks fine to me. Thanks!
Jean-François
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#48365
; Package
auctex
.
(Thu, 13 May 2021 06:01:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 48365 <at> debbugs.gnu.org (full text, mbox):
>>>>> Tassilo Horn <tsdh <at> gnu.org> writes:
> Works like a charm, and good catch! How did you find the culprit?
> With `jit-lock-debug-mode' I get as far as getting a message
> Error running timer âjit-lock--debug-fontifyâ: (end-of-buffer)
> which clearly tells we're trying to moe farther than end of buffer but
> still there is no indication where we're doing that. Do you have some
> trick I'm not aware of yet?
No, just ordinary hand debug with edebug as an auxiliary tool. :-)
A possible advantage for me is that I encountered a similar example
before and saved it for future debug:
----------------------------------------------------------------------
\documentclass{article}
\begin{document}
\verb|^=}{\|
\verb$'&\$
$aaa$
\verb|a$bc$d|
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:
----------------------------------------------------------------------
From Jean's example, I learned that unclosed dollar sign is involved in
this symptom. So I suspected that dollar fontification causes some error
to interrupt font lock, ending up with partial fontification.
(1) After some unsuccessful tries&errors, I put the point just before
the last $ in the Jean's example and did
M-: (font-latex-match-dollar-math (point-max)) RET
(2) Emacs signaled end-of-buffer error. So I could be confident that the
problem hides in `font-latex-match-dollar-math' or the vicinity of
it.
(3) I enabled edebug for `font-latex-match-dollar-math' and tried
M-: (font-latex-match-dollar-math (point-max)) RET
after putting the point before the last $ again.
(4) Then I noticed that the second call to
`font-latex-find-dollar-math' returns t, which should be nil because
this last $ is unclosed in the buffer.
(5) I looked at `font-latex-find-dollar-math' carefully and noticed that
it returns false t if LIMIT argument exceeds end of buffer.
Regards,
Ikumi Keita
bug closed, send any further explanations to
48365 <at> debbugs.gnu.org and jfbu <jfbu <at> free.fr>
Request was from
Ikumi Keita <ikumi <at> ikumi.que.jp>
to
control <at> debbugs.gnu.org
.
(Thu, 27 May 2021 13:17:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Jun 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 73 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.