I would like to understand the internal architecture and strategy used by org-mode.
how does org-mode avoid re-parsing the document after every change?
For example, let's say I have a 2 meg org-mode file/buffer.
There is a TODO in the middle of the file.
I accidentally put a space in the middle of "TODO", so it becomes "TO DO".
After that insert, org-mode needs to remove that TODO (and possibly its children) from its internal data structures. However, from what I can tell, org wouldn't know what the change was. It would have to reparse the whole buffer and then compare the old tree with the new tree. Any agenda views would also have to update after this single keystroke.
How does org-avoid having to perform such an expensive computation for every key stroke?
org-mode
updates withfont-lock-mode
, whereas the*Org Agenda*
buffer is created manually each time a user creates a search or regenerates manually via a specific operation ... If are interested, you can grep the source code for the termfont-lock
and you'll see how the definitions are set out ... The functionorg-set-font-lock-defaults
(which gets called whenorg-mode
is activated) has a lot of stuff that you may find interesting ...*Org Agenda*
buffer uses text-properties (instead offont-lock
) for colors and lots of hidden information about each item. The text-properties consist of what what may have existed when the data was gathered from theorg-mode
buffer, and additionaltext-properties
are added while the data is being gathered following a search; e.g.,org-search-view
,org-tags-view
,org-agenda-list
. To see more about the hidden text-properties, place your cursor on a an entry in theorg-agenda
buffer and type:M-x eval-expression RET (text-properties-at (point)) RET
.font-lock
mode, which is used byorg-mode
(but notorg-agenda-mode
), refreshes whatever has changed and initially processes the buffer by hunks. Thejit-lock
library works in conjunction withfont-lock
and there are customizations to control when certain things are processed, and there is also a timer function. As tofont-lock
/jit-lock
, Emacs makes decisions every command loop regarding what to do, and there are probably some org-specific triggers. The*Org Agenda*
buffer is fairly static/non-changing, except as to mouse-overs.