Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding multiple entries not working, dates changed #1494

Open
thmsklngr opened this issue Jun 3, 2022 · 2 comments
Open

Adding multiple entries not working, dates changed #1494

thmsklngr opened this issue Jun 3, 2022 · 2 comments
Labels
bug Something isn't working 📌 This can't go stale
Milestone

Comments

@thmsklngr
Copy link

thmsklngr commented Jun 3, 2022

Bug Report

Environment

jrnl: v2.8.4
Python: 3.10.4 (main, Mar 23 2022, 20:25:24) [GCC 5.4.0 20160609]
OS: Linux 5.13.0-44-generic

Installation method: Homebrew (on Linux)

Current Behavior

I simply start jrnl without any option and enter following text in vim:

[2022-06-01 10:00] JFX

[2022-06-02 09:15] JFX

[2022-06-03 09:00] JFX

The information stored looks different:

 ~  jrnl -to today 
2022-06-01 10:00 JFX

2022-06-03 09:15 JFX

2022-06-03 12:04 [2022-06-02 09:00] JFX

This may vary. I also once got the same entries with this output:

2022-06-02 10:00 JFX

2022-06-03 09:00 DWH JFX

2022-06-03 12:00 [2022-06-02 09:00] DWH JFX

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

~ jrnl --debug                                                                                                                                                                                     ✔ │ 12:12:35 
DEBUG    root         Parsed args: Namespace(debug=True, preconfig_cmd=None, postconfig_cmd=None, filename=None, on_date=None, today_in_history=False, month=None, day=None, year=None, start_date=None, end_date=None, contains=None, strict=False, starred=False, limit=None, excluded=[], edit=False, delete=False, export=False, tags=False, short=False, config_override=[], config_file_path='', text=[])
DEBUG    root         Reading configuration from file /home/myuser/.config/jrnl/jrnl.yaml
DEBUG    root         Using configuration "{'colors': {'body': 'none', 'date': 'none', 'tags': 'none', 'title': 'none'}, 'default_hour': 9, 'default_minute': 0, 'editor': 'vim', 'encrypt': False, 'highlight': True, 'indent_character': '|', 'journals': {'default': '/home/myuser/.local/share/jrnl/'}, 'linewrap': 79, 'tagsymbols': '#@', 'template': False, 'timeformat': '%Y-%m-%d %H:%M', 'version': 'v2.8.4'}"
DEBUG    root         Using journal name: default
DEBUG    root         Write mode: starting
DEBUG    root         Write mode: opening editor
DEBUG    root         Write mode: loading template for entry
DEBUG    root         Write mode: no template configured
DEBUG    root         Write mode: appending raw text to journal "default": [2022-06-01 10:00] JFX

[2022-06-02 09:15] JFX

[2022-06-03 09:00] JFX



[Entry added to default journal]
--- Logging error ---
Traceback (most recent call last):
  File "/home/linuxbrew/.linuxbrew/opt/python@3.10/lib/python3.10/logging/__init__.py", line 1100, in emit
    msg = self.format(record)
  File "/home/linuxbrew/.linuxbrew/opt/python@3.10/lib/python3.10/logging/__init__.py", line 943, in format
    return fmt.format(record)
  File "/home/linuxbrew/.linuxbrew/opt/python@3.10/lib/python3.10/logging/__init__.py", line 678, in format
    record.message = record.getMessage()
  File "/home/linuxbrew/.linuxbrew/opt/python@3.10/lib/python3.10/logging/__init__.py", line 368, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting
Call stack:
  File "/home/linuxbrew/.linuxbrew/bin/jrnl", line 8, in <module>
    sys.exit(cli())
  File "/home/linuxbrew/.linuxbrew/Cellar/jrnl/2.8.4_2/libexec/lib/python3.10/site-packages/jrnl/cli.py", line 34, in cli
    return run(args)
  File "/home/linuxbrew/.linuxbrew/Cellar/jrnl/2.8.4_2/libexec/lib/python3.10/site-packages/jrnl/jrnl.py", line 69, in run
    write_mode(**kwargs)
  File "/home/linuxbrew/.linuxbrew/Cellar/jrnl/2.8.4_2/libexec/lib/python3.10/site-packages/jrnl/jrnl.py", line 149, in write_mode
    logging.debug("Write mode: completed journal.write()", args.journal_name, raw)
Message: 'Write mode: completed journal.write()'
Arguments: ('default', '[2022-06-01 10:00] JFX\n\n[2022-06-02 09:15] JFX\n\n[2022-06-03 09:00] JFX\n\n\n')

Other Information

n/a

Regards, Thomas

@thmsklngr thmsklngr added 🆕 New! bug Something isn't working labels Jun 3, 2022
@apainintheneck
Copy link
Contributor

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.

  1. 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)
  2. The rest of the entry is stored as raw text in the body so jrnl only thinks it is storing one entry.
  3. 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.

@micahellison
Copy link
Member

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.

@wren wren removed the 🆕 New! label Jun 4, 2022
@micahellison micahellison added this to the Backlog milestone Jun 18, 2022
@micahellison micahellison added the 📌 This can't go stale label Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working 📌 This can't go stale
Projects
None yet
Development

No branches or pull requests

4 participants