Use buffer-chars-modified-tick instead of buffer-modified-tick

[yantar92]

buffer-modified-tick invalidates buffer cache even when changes to text properties are made (i.e. each time agenda view is refreshed). buffer-chars-modified-tick reacts only to actual canges in buffer text. AFAIK there is no reason to invalidate change when text in org buffer is not changed.

[alphapapa]

Thanks, this may be a good change to make. You may be right that property changes don't matter, but ISTR that some Org code does put text properties on headings (tags or properties, something like that). Or maybe I'm thinking of the Agenda code you mentioned. Could you elaborate a little on what you may know about this?

Also, it might be good for this to be tested in a branch for a little while before being merged.

What do you think? Thanks.

[yantar92]

Could you elaborate a little on what you may know about this?

There is a caching mechanism involving text properties. It used by org-agenda and mapping API. The central functions are org-refresh-property and org-refresh-properties. These functions basically store some data in text properties of headings - a kind of cache. AFAIK, efforts, categories, clocksums, and stats cookies are using this mechanism. Agenda updates the property cache every single time it is built or updated. See org-agenda-prepare-buffers.

In general, changes made in property cache always reflect changes in the text. However, changes in text do not guarantee that property cache is updated. It must be done manually, according to my understanding of the code. So, for the purpose of org-ql, there is no need to worry that org-ql's own cache can become wrong as the text in file is not changed, but text properties are changed.

I personally use Org's property cache to speed up queries of properties that are not very frequently used. Property cache does a single pass across the org file updating properties incrementally. See [1] and first src block in [2] for example usage.

Also, it might be good for this to be tested in a branch for a little while before being merged.

So far it is working fine for me. It has been one week from the time I added this commit to my fork.

[1] https://github.com/yantar92/emacs-config/blob/master/config.org#speed-up-agenda-generation-via-org-refresh-properties

[2] https://github.com/yantar92/emacs-config/blob/master/config.org#archiving

[yantar92]

Also, it might be good for this to be tested in a branch for a little while before being merged.

Still no issues :)

[alphapapa]

Thanks. I haven't had time to work on these packages lately, but I'll plan to make this change in 0.6.

[alphapapa]

I'm going to defer this to 0.7 so I can release 0.6 sooner. As soon as I do that, I'll merge this to master.