As you noticed, this basically happens when the redisplay is too slow for some reason. There's not much we can do in the general case (when it's "much too slow") but when it's "just a tad bit too slow" you can try one of those (or both, tho it probably doesn't do anything more than only one of the two):
(setq jit-lock-defer-time 0)
You can use (sit-for 0) or (redisplay t).
The help for redisplay:
Optional arg FORCE, if non-nil, prevents redisplay from being
preempted by arriving input, even if ‘redisplay-dont-pause’ is nil.
If ‘redisplay-dont-pause’ is non-nil (the default), redisplay is never
preempted by arriving input, so FORCE does nothing.
You can use font-lock-studio to debug this. It's a debugger for font-lock keywords that let you single-step each step in the font-lock engine, run to breakpoints etc. Unlike the real font-lock, it enters the elisp debugger when an error occurs (if debug-on-error is non-nil).
You should use the command toggle-truncate-lines rather than changing directly the value of variabletruncate-lines. This command does ensure the display is updated (apparently through force-mode-line-update although nor its name neither its docstring does suggest that).
It is described in emacs manual but unfortunately not mentionned in truncate-lines ...
One thing you can do is to pass a numeric prefix argument to the scroll command, instead of just pressing and holding down its key to invoke it repeatedly.
For example, if you are using the <next> key (aka PageDown) then the command it invokes is scroll-up-command. And C-h f scroll-up-command tells you that a numeric prefix arg says to scroll that ...
See also Emacs bug tracker feature request #22404 (which has not yet been implemented, but the mailing archive contains a rough draft rudimentary patch that creates a new hook for this specific issue): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22404
Whenever point moves outside of the visible window, the window-scroll-functions hook is triggered -- at ...
I have a growing org file of 5000 lines, 200 headings and 150 noweb references.
I tangle a 3000 lines file.
Using the built-in org-babel-tangle takes over 10 minutes.
I wrote ob-tangle.pl to do - quickly, under a second - the limited feature tangle I need:
# ob-tangle.pl -- simplified noweb tangle of a named org-mode SRC block
Partial answer: this does it and reduces tangling time by about 40% (subjective). But I'm looking for more ways to speed it up. Compared to eg the C preprocessor cpp, org-tangle is very slow.
(defadvice org-babel-tangle-single-block (around inhibit-redisplay activate protect compile)
"inhibit-redisplay and inhibit-message to avoid flicker."
As Stefan says, this sounds like a bug. (I certainly can't replicate it.)
In the meantime you could use this as a very manual workaround:
(defun my-toggle-redisplay (arg)
Force redisplay ON with a positive numeric prefix arg.
Force redisplay OFF with a zero or negative numeric prefix arg."
Posting this since its a weak solution but better than nothing.
Instead of changing all of emacs behavior its possible to write functions that force-redraw after every operation, which avoids hanging and makes scrolling more responsive for page up/down and mouse wheel.
(lambda () (interactive)
(condition-case nil (scroll-up)
(force-mode-line-update) or all with the optional t: "Force redisplay of the current buffer’s mode line and header line. With optional non-nil ALL, force redisplay of all mode lines and header lines. This function also forces recomputation of the menu bar menus and the frame title." Here is a link to the manual entry: https://www.gnu.org/software/emacs/...