You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I took a look at this and while I was not able to reproduce the TypeError debug message everything else seems to work the same way on macOS. I'm not sure if submitting multiple entries at once is a supported behavior either.
I think a few things are happening here.
The first thing jrnl tries to do after a new entry is submitted is parse the timestamp and the title. In this case, the format you used is not a valid timestamp so it's creating its own. (Note: It looks like timestamps need to be followed by a colon and be in one of the formats discussed here: https://jrnl.sh/en/stable/usage/#composing-entries)
The rest of the entry is stored as raw text in the body so jrnl only thinks it is storing one entry.
When you go to search the journal it parses what was originally stored as one post as multiple because they match the expected entry format.
Thanks for the report @mosesontheweb, and thanks for investigating this @apainintheneck. I can repro these issues also.
The multiple entries issue is a problem with "compose" versus "edit" mode: when creating a new entry, such as when you run jrnl with no arguments, you can only create one entry at a time. However, when running with --edit, you can create multiple entries at once using that bracketed format. We'd like to make this more consistent at some point, though we haven't yet decided how exactly.
As for the traceback, that looks like a problem with the --debug output failing to render some run-time arguments to a string. Not sure what the problem is exactly, but I'll spin that off to another issue.
Bug Report
Environment
Installation method: Homebrew (on Linux)
Current Behavior
I simply start jrnl without any option and enter following text in vim:
The information stored looks different:
This may vary. I also once got the same entries with this output:
So, the handling of multiple entries is somehow buggy, but, to be honest, I do not know if this is even supported.
Expected Behavior
The entries are stored as written in the text.
Repro Steps
Other Information
n/a
Regards, Thomas
The text was updated successfully, but these errors were encountered: