Carry over the carryover items only once

[turkja]

I just found out that the carryover items are processed on every new item, which is sometimes a bit annoying. I'm using encrypted journals, and it is pretty handy to have daily journal buffer open all day, because the buffer stays in memory and is encrypted on disk when saving it. So it doesn't need the secret key for the operation. Unless it just happens that the previous day's journal is not in Emacs buffer, because in that case org-journal want's to open it, and apparently parse the possible carryover items.

I don't know if this is a feature or not. Of course it might be a valid use case to go to previous day (or week, or month) journal and add carryover item there, but I don't really see the point since it will be carried over to current journal anyway.

So would it make sense to do it only once? What kind of logic would be necessary to ensure the carryover has been done already? Maybe that's not possible without some header on the file itself.

[casch-at]

1. Do you use this feature? If not, you can set (setq org-journal-carryover-items "") to an empty string.

2. We would need to store some information that the carryover has already been done Probably the best place for it is in today's entry property drawer. But unfortunately it is not that simple, when to user has set org-journal-date-prefix to something other than "* ". The main heading isn't a default org-heading. Which means, we can't add a property drawer.

3. Adding a header property

   Maybe that's not possible without some header on the file itself.

   We could add some header property saving some information whether the carryover has already been done for the today's entry.

[Andsbf]

I have the same problem, I'm not deleting the carried over elements, just "flagging" with :carried:. but that leads to the elements being carried multiple times, every time I call org-journal-new-entry

the solution proposed here, https://github.com/june3474/org-journal/commit/6ab9c38efa6f0fcd4b3eec60daf37a59584d3a1e seems interesting, but I would rather have an "official" solution.