Nicholas Savage writes: > I realize now that I messed up sending this patch yesterday so it > didn't show up on updates.orgmode.org. I just wanted to repost it with > a correct subject to make sure it didn't get lost. My original message > follows.
This topic is now split across three separate threads: https://orgmode.org/list/d4e1e166-8da2-4c1f-8d90-1671a6541...@www.fastmail.com https://orgmode.org/list/54ebdcc2-c17a-445a-9599-2bfc90e64...@www.fastmail.com https://orgmode.org/list/b204da05-85f3-43af-bbf0-ed7149b30...@www.fastmail.com Please avoid doing that in the future. It invites confusion and redundant responses. > I posted earlier about why org-remove-occur-highlights ignored it's > options of beg and end. I'm fairly sure it was so they could be > implemented later. At least one reason that those parameters exist is to allow org-remove-occur-highlights to be used as a member of before-change-functions. I suspect it's _the_ reason. > I wanted to use this functionality, so I've > implemented it. This should not change any current behaviour. If beg > and end are nil, it will run the same way as before. This is called as > part of org-sparse-tree, and my changes do not affect that. When beg > and end are non-nil, it checks which overlays are between those two > points and deletes them. I've ensured that 'make test' still passes > and believe I've formatted my changelog entry as required. > > If I'm missing something about how this should be working, please let > me know. Thanks for sending the patch. Unfortunately, it breaks the org-remove-highlights-with-change functionality, which depends on org-remove-occur-highlights not paying attention to the BEG and END arguments. Take this Org file: --8<---------------cut here---------------start------------->8--- * a | target --8<---------------cut here---------------end--------------->8--- Call org-sparse-tree and enter "target" as the regular expression. Then, with point at "|", hit, say, C-o. When org-remove-highlights-with-change is non-nil, the highlighting should go away. With your patch, it doesn't. It might be worth stepping back and describing what your use case for this change is, and considering other ways to address it (not necessarily as a change to Org itself).