Fix stale clocked header references when making edits to headers

[ReeceStevens]

Hi all! Thanks for the development of such a useful tool! I've been a happy user of nvim-orgmode for quite some time now.

I use the clocking functionality frequently in nvim-orgmode, as I've written a custom plugin for exporting the clock reports as timesheets for my work. I noticed that after a substantial refactor change for nvim-orgmode got merged into master, I would frequently experience file corruption when trying to clock in a new header. I figured out after some experimentation that this was happening whenever I was editing a file such that the currently clocked in header moved positions in the buffer. It looks like the currently clocked-in header is stored in memory, but for certain conditions the actual position of the header would get out of sync (e.g., if I moved another header above the currently clocked-in one).

This was a pretty significant issue for my workflow, so I went ahead and patched it locally and put together a unit test case which exercises the issue. My fix for this issue was to force a reload of the relevant files when performing clock-in or clock-out to ensure the right header position was used.

You can apply just the first commit of the test case and see the test fail against master, then apply the fix and see the test pass.

I'm happy to follow up with requests for changes or feedback if necessary. Thanks!

[kristijanhusak]

The solution looks ok, but I think there might be a simpler and less "heavy" solution.
Would it work if there would be a BufWritePost *.org autocmd that would reload the clocked headline? Basically, after every write it would do the check. In your example, once you move the headline to another place and write the file, it would automatically update.
There was also a plan to run a 1 minute timer to do this automatically, but I think the BufWritePost should cover most of the issues.