Hi Léo,

I think I can actually speak a bit on this. As it stands, babel fontification operates by:

In essence, every keystroke in a babel block causes font-lock lag equal to opening the file for the first time. As you can imagine, this adds up.

I think ideally Org would monitor which block you’re executing keystrokes in, and if there are a few in a row in the same org-src block keep the font-lock buffer alive and incrementally update the content and intelligently copy back font-lock changes. This has the potential to be much lower latency, but is also going to be hard to get right.

In the meantime, you could try executing something like this in your Org buffer (source):

(setq-local jit-lock-defer-time 0.05
            jit-lock-stealth-time 1)

This sacrifices immediate font-lock accuracy for responsiveness.

All the best,
Timothy

From: Léo Ackermann
Subject: Large source block causes org-mode to be unusable
To: emacs-orgmode@gnu.org
Date: Tue, 22 Jun 2021 02:27:52 +0800

Dear all,

I am working in an org-file of reasonable size (<2000 lines): my first paper written in org-mode. Everything fine (and fast) until I started to add `#+BEGIN_proof / #+END_proof` within my .org to make my .pdf export prettier. This caused the editing of the proofs to be very slow: navigation within the proof is fast but adding/removing any char takes around 4s per char.
It seems that the fontify function is responsible for that (see screenshot). As far as I understand, this function tries to fontify the whole block as soon as a single char is modified. In my case, it then tries to fontify a whole proof (~4 pages in my .pdf, with many LaTeX formulas) several times per second...

Is there a way to make this fontify function to act "around my cursor" ? 

Best,
Leo

--
Here the profiler's report when adding a single char
image.png
 Spec.
- Emacs 27.2 (doom emacs 2.0.9) (I just updated them)