I will play around with it. I didn't try to do a ECM. Playing around with it tonight starting with
open /Applications/Emacs.app --new --args -Q So using 8.2.10. Sometimes I can get a slow down when calling `next-line' repeatedly. I will play around with it and report if I get something reproducible and an ECM. Grant Rettke -- g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates “All creativity is an extended form of a joke.” --Kay ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson On Wed, Jul 22, 2015 at 7:41 AM, Nick Dokos <ndo...@gmail.com> wrote: > Angus M <anguscmelvi...@gmail.com> writes: > >>> When I have the cursor inside of the code block for the code, moving >>> up or done one line or one page takes 2-3 seconds. >>> Grant Rettke >>> -- >> >> Thanks for confirming that you also experience the slow-down. >> >> I think that the only way to remedy this is to modify the >> 'org-src-font-lock-fontify-block' function in org-src.el to allow >> just-in-time fontification, (rather than the current complete >> re-fontification of the whole code block upon any changes). >> > > I'm not convinced that this is the reason. I tried with a simple file > (a headline, some text, a source code block with 7K lines of python - > the decimal.py file from the standard python library - and some more > text). > > I set org-src-fontify-natively to nil (through a local variable in > the file). Adding text after the code block was OK but adding text > before the code block was very slow. If fontification were the problem, > I'd expect both to be fast. > > I did a profile with elp and it seems to me that the problem is footnote > detection: > > --8<---------------cut here---------------start------------->8--- > org-activate-footnote-links 7 > 13.397064245 1.9138663207 > org-footnote-next-reference-or-definition 7 > 13.396982566 1.9138546524 > org-footnote-in-valid-context-p 378 > 13.384084804 0.0354076317 > org-in-block-p 322 > 13.146482877 0.0408275865 > org-between-regexps-p 2576 > 12.544080215 0.0048695963 > org-footnote-at-reference-p 189 > 6.7601071689 0.0357677627 > org-footnote-at-definition-p 189 > 6.6263815400 0.0350602197 > org-element--parse-to 15 > 0.41858634 0.027905756 > org-element--cache-sync 18 > 0.3965463360 0.0220303520 > org-fontify-meta-lines-and-blocks 14 > 0.3946110120 0.0281865008 > org-fontify-meta-lines-and-blocks-1 14 > 0.3944775729 0.0281769695 > org-element--current-element 7 > 0.3642047120 0.0520292445 > ... > --8<---------------cut here---------------end--------------->8--- > > I didn't check how org-between-regexps-p and org-footnote-at-*-p are > related, but those three seem to account for the lion's share of the > time. > > BTW, org-src-font-lock-fontify-block calls font-lock-fontify-buffer > which is not supposed to be called from lisp programs: the doc string > suggests using font-lock-ensure or font-lock-flush. I tried the first > but it did not make any difference in the speed. But I guess it should > be changed. > > -- > Nick > >
