GNU bug report logs -
#42267
Fontification takes a long time when an equation contains a double prime
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 42267 in the body.
You can then email your comments to 42267 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#42267
; Package
auctex
.
(Wed, 08 Jul 2020 14:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Najib Idrissi-Kaïtouni <najib.idrissi.kaitouni <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-auctex <at> gnu.org
.
(Wed, 08 Jul 2020 14:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Dear Auctex developers,
Whenever an equation contains a "double prime" '', and if the equation
is very far down in a long document, it appears that fontification takes
a very long time. This is not very apparent for short documents, but I
am currently editing a 6000 lines / 360k character long document. Any
keystroke resulting in a change in the affected equation, or even just
displaying that part of the buffer, makes Emacs grind to a halt (on my
machine, it can take 10-15 seconds to process, during which Emacs is
completely unresponsive, including not responding to C-g).
I would guess that Auctex thinks '' is the end of a quote and is looking
for the (nonexistent) double backtick `` that would be the beginning of
it. I tried to get a backtrace with gdb and it's not exactly clear which
precise function is to blame, but it was always as part of the
fontification. As a test, I filled a buffer with some lipsum and put an
equation at the bottom. Without '' everything is fine, as soon as there
is a '' in the equation things start to noticeably slow down.
I am currently using the latest version, 12.2.4, and Emacs 27.0.91. The
behavior is fairly recent, although I couldn't say if it started with
this release precisely, it may have started more than a week ago.
Thanks.
Najib Idrissi
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Wed, 08 Jul 2020 20:33:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 42267 <at> debbugs.gnu.org (full text, mbox):
Hi Najib,
Najib Idrissi-Kaïtouni <najib.idrissi.kaitouni <at> gmail.com> writes:
> I would guess that Auctex thinks '' is the end of a quote and is
> looking for the (nonexistent) double backtick `` that would be the
> beginning of it. I tried to get a backtrace with gdb and it's not
> exactly clear which precise function is to blame, but it was always as
> part of the fontification. As a test, I filled a buffer with some
> lipsum and put an equation at the bottom. Without '' everything is
> fine, as soon as there is a '' in the equation things start to
> noticeably slow down.
Can you please share this test file so others can load it and see if the
behavior is reproducible?
> I am currently using the latest version, 12.2.4, and Emacs
> 27.0.91. The behavior is fairly recent, although I couldn't say if it
> started with this release precisely, it may have started more than a
> week ago.
AUCTeX's fontification for math went through a bigger overhaul. Please
share the file and a recipe (preferably starting with `emacs -Q') how to
trigger your obeservation, that would help a lot.
Thanks in advance, Arash
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Thu, 09 Jul 2020 15:27:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 42267 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
> Can you please share this test file so others can load it and see if the
> behavior is reproducible?
>
Sure, see the attached file. As I said, it's a file filled with lipsum
with a single equation at the bottom.
> AUCTeX's fontification for math went through a bigger overhaul. Please
> share the file and a recipe (preferably starting with `emacs -Q') how to
> trigger your obeservation, that would help a lot.
1. Open the file and go to the equation at the bottom
2. Notice that editing speed inside the equation is normal (e.g. hold
the space bar inside the equation and notice that it goes at a
normal speed)
3. Add a double prime somewhere in the equation, e.g. after the 2 so
that it becomes 1+1=2''
4. Notice that now editing speed is degraded, for example hold the
space bar at the end of the equation and notice that there is now a
stutter. If your CPU is too fast and you don't notice the stutter,
you can just copy more paragraphs of lipsum, I guess.
In my real life example (that I cannot share because the article in
question is not public yet) the slowdown is so bad that a single
keystroke inside an affected equation can take several seconds.
Best regards,
Najib Idrissi
Le 08/07/2020 à 22:22, Arash Esbati a écrit :
> Hi Najib,
>
> Najib Idrissi-Kaïtouni <najib.idrissi.kaitouni <at> gmail.com> writes:
>
>> I would guess that Auctex thinks '' is the end of a quote and is
>> looking for the (nonexistent) double backtick `` that would be the
>> beginning of it. I tried to get a backtrace with gdb and it's not
>> exactly clear which precise function is to blame, but it was always as
>> part of the fontification. As a test, I filled a buffer with some
>> lipsum and put an equation at the bottom. Without '' everything is
>> fine, as soon as there is a '' in the equation things start to
>> noticeably slow down.
> Can you please share this test file so others can load it and see if the
> behavior is reproducible?
>
>> I am currently using the latest version, 12.2.4, and Emacs
>> 27.0.91. The behavior is fairly recent, although I couldn't say if it
>> started with this release precisely, it may have started more than a
>> week ago.
> AUCTeX's fontification for math went through a bigger overhaul. Please
> share the file and a recipe (preferably starting with `emacs -Q') how to
> trigger your obeservation, that would help a lot.
>
> Thanks in advance, Arash
[Message part 2 (text/html, inline)]
[foo.tex (text/x-tex, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Thu, 09 Jul 2020 16:38:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 42267 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Najib,
>>>>> Najib Idrissi <najib.idrissi.kaitouni <at> gmail.com> writes:
> Sure, see the attached file. As I said, it's a file filled with lipsum
> with a single equation at the bottom.
>> AUCTeX's fontification for math went through a bigger overhaul. Please
>> share the file and a recipe (preferably starting with `emacs -Q') how to
>> trigger your obeservation, that would help a lot.
> 1. Open the file and go to the equation at the bottom
> 2. Notice that editing speed inside the equation is normal (e.g. hold
> the space bar inside the equation and notice that it goes at a
> normal speed)
> 3. Add a double prime somewhere in the equation, e.g. after the 2 so
> that it becomes 1+1=2''
> 4. Notice that now editing speed is degraded, for example hold the
> space bar at the end of the equation and notice that there is now a
> stutter. If your CPU is too fast and you don't notice the stutter,
> you can just copy more paragraphs of lipsum, I guess.
> In my real life example (that I cannot share because the article in
> question is not public yet) the slowdown is so bad that a single
> keystroke inside an affected equation can take several seconds.
Thank you for providing concrete example and procedure to reproduce. I
experience the slowdown you described.
The attached patch fixes, or at least reduces, the slowdown on my side.
Could you check whether it works for you or not?
Best Regards,
Ikumi Keita
[patch (text/x-diff, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Thu, 09 Jul 2020 23:27:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 42267 <at> debbugs.gnu.org (full text, mbox):
Hi,
Yes, this is much, much better with this patch. I don't experience any
noticeable slowdown anymore, whether in the test file or in my "real
world" file. Thanks!
Best regards,
Najib Idrissi
Le 09/07/2020 à 18:37, Ikumi Keita a écrit :
> Hi Najib,
>
>>>>>> Najib Idrissi <najib.idrissi.kaitouni <at> gmail.com> writes:
>> Sure, see the attached file. As I said, it's a file filled with lipsum
>> with a single equation at the bottom.
>>> AUCTeX's fontification for math went through a bigger overhaul. Please
>>> share the file and a recipe (preferably starting with `emacs -Q') how to
>>> trigger your obeservation, that would help a lot.
>> 1. Open the file and go to the equation at the bottom
>> 2. Notice that editing speed inside the equation is normal (e.g. hold
>> the space bar inside the equation and notice that it goes at a
>> normal speed)
>> 3. Add a double prime somewhere in the equation, e.g. after the 2 so
>> that it becomes 1+1=2''
>> 4. Notice that now editing speed is degraded, for example hold the
>> space bar at the end of the equation and notice that there is now a
>> stutter. If your CPU is too fast and you don't notice the stutter,
>> you can just copy more paragraphs of lipsum, I guess.
>> In my real life example (that I cannot share because the article in
>> question is not public yet) the slowdown is so bad that a single
>> keystroke inside an affected equation can take several seconds.
> Thank you for providing concrete example and procedure to reproduce. I
> experience the slowdown you described.
>
> The attached patch fixes, or at least reduces, the slowdown on my side.
> Could you check whether it works for you or not?
>
> Best Regards,
> Ikumi Keita
>
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Fri, 10 Jul 2020 07:54:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 42267 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Najib and all,
>>>>> Najib Idrissi-Kaïtouni <najib.idrissi.kaitouni <at> gmail.com> writes:
> Yes, this is much, much better with this patch. I don't experience any
> noticeable slowdown anymore, whether in the test file or in my "real
> world" file. Thanks!
Thanks for confirmation. We'll fix the problem soon.
To AUCTeX developers:
I propose to install the attached fix. Any comments and suggestions are
welcome.
[Analysis]
The backgrounds of the problem are the following two:
1. When there is a closing quote (or double prime) '' without matching
opening quote `` before it, current
`font-latex-extend-region-backwards-quotation' ends up to decrease
`font-lock-beg' by 5000 (=default value of
`font-latex-multiline-boundary') and returns t.
2. Previously, font-latex-extend-region-backwards-* functions were
stored in `font-latex-extend-region-functions' and called just once
per fontify operation. However, now they are in
`font-lock-extend-region-functions' and can be called repeatedly in
`font-lock-default-fontify-region', until all of them return nil.
Therefore, when there is math expression like $f''(x)=x^{3}$, current
f-l-e-r-b-q repeatedly decreases `font-lock-beg' so that the font lock
region begins with BOB eventually. Thus every key stroke forces to
re-fontify all the region from top of the buffer. This is the reason of
the apparent slowdown in a large buffer.
I think the behavior of the above item 1 is a bug. When f-l-e-r-b-q
cannot find a matching opening quote, it should just give up to extend
the region anymore.
Regards,
Ikumi Keita
[0001-Don-t-extend-font-lock-region-too-much-bug-42267.patch (text/x-diff, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Sat, 11 Jul 2020 05:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 42267 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
> I think the behavior of the above item 1 is a bug. When f-l-e-r-b-q
> cannot find a matching opening quote, it should just give up to extend
> the region anymore.
After reconsideration, I realized that such giving up is not appropriate
when that unmatched close quote has, in front of it, other open-close
quote pairs. Examples:
abc ``def ghi'' jkl $y''=x^{2}$
abc <<def ghi>> jkl $y''=x^{2}$
So the correct way is to continue searching backwards another close
quote, I think. The revised patch is attached. I'll install it soon.
Regards,
Ikumi Keita
[0001-Don-t-extend-font-lock-region-too-eagerly-bug-42267.patch (text/x-diff, attachment)]
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Sat, 11 Jul 2020 06:39:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 42267 <at> debbugs.gnu.org (full text, mbox):
Hi Ikumi, thank you for taking care of this.
I wonder what other people's opinions would be about turning *off* raw-quotes highlighting by default (is it on by default?) – or maybe eliminating it altogether. There would be several reason for this:
– Quirks with apostrophes used in math mode, as the present bug showed; and also the complexity of distinguishing a genitive apostrophe ("the students' books") from a closing quote mark in a single-quote style, which often occurs in British writings for example.
– Quirks with multi-paragraph quotes, when one uses the quotation style that repeats the opening quotes (but not the closing quotes) at each paragraph.
– Syntactically it's best to introduce quotations with an appropriate macro, eg \enquote{} from the csquotes package, which also automatically takes care of quotation styles like the ones mentioned above.
Just some thoughts.
Cheers,
Luca
On 2020-07-11 07:55, Ikumi Keita wrote:
>>>>>> Ikumi Keita <ikumi <at> ikumi.que.jp> writes:
>> I think the behavior of the above item 1 is a bug. When f-l-e-r-b-q
>> cannot find a matching opening quote, it should just give up to extend
>> the region anymore.
>
> After reconsideration, I realized that such giving up is not appropriate
> when that unmatched close quote has, in front of it, other open-close
> quote pairs. Examples:
> abc ``def ghi'' jkl $y''=x^{2}$
> abc <<def ghi>> jkl $y''=x^{2}$
>
> So the correct way is to continue searching backwards another close
> quote, I think. The revised patch is attached. I'll install it soon.
>
> Regards,
> Ikumi Keita
>
>
> _______________________________________________
> 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#42267
; Package
auctex
.
(Sat, 11 Jul 2020 09:49:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 42267 <at> debbugs.gnu.org (full text, mbox):
Hi PierGianLuca,
>>>>> PierGianLuca Porta Mana <pglpm0 <at> gmail.com> writes:
> I wonder what other people's opinions would be about turning *off*
> raw-quotes highlighting by default (is it on by default?)
Yes, it's on by default, and can be turned off by setting the customize
option `font-latex-quotes' to nil.
> – or maybe eliminating it altogether.
> There would be several reason for this:
> - Quirks with apostrophes used in math mode, as the present bug
> showed; and also the complexity of distinguishing a genitive
> apostrophe ("the students' books") from a closing quote mark in a
> single-quote style, which often occurs in British writings for
> example.
I think those cases don't matter. The default settings of font-latex.el
don't interact with such single apostrophe, and only respond to doubled
apostrophe '' and doubled backquote ``, possibly along with French or
German style quotes. (See the doc string of `font-latex-quote-list'.)
> - Quirks with multi-paragraph quotes, when one uses the quotation
> style that repeats the opening quotes (but not the closing quotes) at
> each paragraph.
If there are many ``s without matching ''s, they are displayed with
warning color. I agree that that warning color would be annoying for
users who have such style of writing. (However, it seems that no users
of AUCTeX complain about it currently. Do you think that there are
potentially many such users actually?)
> - Syntactically it's best to introduce quotations with an appropriate
> macro, eg \enquote{} from the csquotes package, which also
> automatically takes care of quotation styles like the ones mentioned
> above.
Well, I suppose that many users still prefer casual style ``...'' over
\enquote{} etc. because the former is easier to type.
To be honestly :-), the highlighting of ``...'' is not an important
feature for me because most LaTeX documents I encounter are oriented for
math and physics, and have very few ``...''s. So I don't object to
eliminate that feature if a lot of people have opinions to do so.
Regards,
Ikumi Keita
Information forwarded
to
bug-auctex <at> gnu.org
:
bug#42267
; Package
auctex
.
(Sat, 11 Jul 2020 10:49:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 42267 <at> debbugs.gnu.org (full text, mbox):
Hi Ikumi,
I'm actually guilty of both quotation-style sins I mentioned :) But AUCTeX works well for me: as in your case I have turned off fontification for quotes, and have instead activated fontification for the package csquotes (which is also taken care of in preview).
I wanted to put those thoughts out there just in case.
Wish you all a pleasant weekend,
Luca
On 2020-07-11 11:48, Ikumi Keita wrote:
> To be honestly :-), the highlighting of ``...'' is not an important
> feature for me because most LaTeX documents I encounter are oriented for
> math and physics, and have very few ``...''s. So I don't object to
> eliminate that feature if a lot of people have opinions to do so.
>
> Regards,
> Ikumi Keita
>
Added tag(s) fixed.
Request was from
Ikumi Keita <ikumi <at> ikumi.que.jp>
to
control <at> debbugs.gnu.org
.
(Sat, 11 Jul 2020 17:10:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
42267 <at> debbugs.gnu.org and Najib Idrissi-Kaïtouni <najib.idrissi.kaitouni <at> gmail.com>
Request was from
Ikumi Keita <ikumi <at> ikumi.que.jp>
to
control <at> debbugs.gnu.org
.
(Sat, 11 Jul 2020 17:10:02 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
.
(Sun, 09 Aug 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 253 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.