bastibe / org-journal

A simple org-mode based journaling mode
BSD 3-Clause "New" or "Revised" License
1.24k stars 123 forks source link

CREATED property at top level of journal file can cause add-entry to fail #383

Closed jmay closed 1 year ago

jmay commented 2 years ago

Describe the bug If there is a top-level properties drawer in the journal file (outside any headings), and that drawer contains a CREATED property, then many journaling actions will abort with "Before first headline at position ... in buffer ...".

This is because org-journal--created-re seeks forward for the first CREATED entry, then seeks back with (org-back-to-heading) which fails because it is at top of file.

Quick easy workaround: Don't put a CREATED property at the top level of an org-journal file, because it is meaningless, those properties are only useful in the context of specific journal entries.

But journaling shouldn't break just because there's a useless property there.

To Reproduce Go to the top of any journal file. Insert a properties drawer like

:PROPERTIES:
:ID: something
:CREATED: something
:END:

Then invoke (org-journal-new-entry) or (org-journal-after-save-hook).

Expected behavior Saving an org-journal buffer should ignore any top-level properties drawer contents.

Desktop (please complete the following information):

bastibe commented 2 years ago

Thank you for the bug report.

Would you like to contribute a pull request to fix this?

pnathan commented 2 years ago

I also observe this specific bug.

emacs 27.2

xeruf commented 2 years ago

Probably related:

user-error: Created property timestamp format "[%Y-%m-%d]" doesn’t match CREATED property value ([2022-08-04 Thu 15:56]) from entry at line: Line 208

I get this if a subheading has a CREATED property (in my case created by Orgzly) - but weirdly enough only when the headline is folded.

xeruf commented 1 year ago

This not only causes add-entry to fail, it causes creation of org timestamps to fail, everywhere! Highly annoying!

bastibe commented 1 year ago

Very annoying indeed. These formatting differences can arise when more than one Emacs/computer add data to an org file with more than one locale setting.

If you know of a good way to fix this, I'd appreciate a pull request.