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

Clarify difference between editor and cli entries in docs #1072

Closed
mandarvaze opened this issue Nov 6, 2020 · 7 comments · Fixed by #1657
Closed

Clarify difference between editor and cli entries in docs #1072

mandarvaze opened this issue Nov 6, 2020 · 7 comments · Fixed by #1657
Labels
documentation Improvements or additions to documentation 📌 This can't go stale
Milestone

Comments

@mandarvaze
Copy link
Contributor

Bug Report

Environment

  • Jrnl --diagnostic output:
➜ jrnl --diagnostic
jrnl: v2.4.5
Python: 3.8.6 (default, Oct  8 2020, 14:06:32)
[Clang 12.0.0 (clang-1200.0.32.2)]
OS: Darwin 19.5.0
  • Install method: brew install jrnl

Current Behavior

I have multiple journals configured, like work and diary.

I've defined a template in my ~/.config/jrnl/jrnl.yaml for diary
work does not use template.

Whenever I create an entry like jrnl diary the template is copied just fine, as expected.
But when I create a backdated entry like jrnl diary yesterday at 10pm: backdated entry here the entry starts out blank i.e. without the contents of the template.

Expected Behavior

Template should be used for normal entry as well as for backdated entry.

Repro Steps

  1. define multiple journals
  2. define template for one of the journal
  3. Create "normal" entry (works fine, uses template)
  4. Create backdated entry - the entry starts out blank, without the content of the template

Other Information

None.

@mandarvaze mandarvaze added 🆕 New! bug Something isn't working labels Nov 6, 2020
@wren
Copy link
Member

wren commented Nov 6, 2020

Hi! Thanks for filing an issue.

From what you're describing, it sounds to me like this is what templates are supposed to do.

If you write an entry, then the template is ignored in favor of that entry.

Maybe they could work a bit differently, but I'm unclear what a template would be expected to do is there's already an entry.

Can you please explain in more detail where you expect a template to go if you've already entered jrnl diary yesterday at 10pm: backdated entry in the terminal? Currently, that means your entry is "backdated entry" and we don't know where the template would go.

@mandarvaze
Copy link
Contributor Author

When you put it like that, it makes sense 😄

So is there a way to add older timestamp and add the entry via an editor ?
e.g. When I just enter jrnl diary - an editor is launched and I start typing. The editor already contains the text from the template. The current timestamp is then added when saving the file. (I assume)

I want similar behavior except I specify older timestamp

Is that possible ?

My current workaround :

  • open the diary.txt directly in an editor
  • go to the end
  • type the title and the timestamp
  • copy the template text from previous day's entry
  • Add/Modify as required

But this kinda defeats the purpose of using jrnl altogether.

@wren
Copy link
Member

wren commented Nov 7, 2020

Ah, I think I see what you're saying.

So, adding new entries in an editor works the same way as adding entries via the command line (only without your shell getting in the way). So, on new entries, jrnl looks for a timestamp as the very first part of the entry for a timestamp.

How this would work in your example is this:

  • enter jrnl diary
  • your editor will open with a new entry pre-populated by your template
  • add a timestamp to the first line followed by a colon
  • edit the rest of your template as necessary
  • save and close your editor

That's it! jrnl will look for a timestamp as the first part of your entry the same way it does on the command line. There are some examples in the documentation, but the gist of it is that you if you add a timestamp on the first line followed by a colon (e.g. yesterday: rest of first line), jrnl will find it and use that (if it doesn't find one, then it defaults to now, which is the behavior you are describing in your comment).

@wren
Copy link
Member

wren commented Nov 7, 2020

To clarify, this is what if would look like after editing your entry:

timestamp goes here: Template Title

Some text here or anything else in your template.

So, the timestamp should be the very first thing in your entry.

@mandarvaze
Copy link
Contributor Author

@wren The documentation always refers to the timestamp only when the entry is entered on the command line.

It did not occur to me that in editor, I can use timestamp on the first line (I understand that the first line is title. But I never used timestamp: title format. Just title

My workaround was similar but when I manually edit diary.txt - I use to copy the timestamp from previous entry and make changes (So that timestamp format is not broken)

Using timestamp format like yesterday at 10pm in an editor is going to make my life easier.

@wren wren added support End user support and removed 🆕 New! bug Something isn't working labels Nov 7, 2020
@micahellison micahellison added the documentation Improvements or additions to documentation label Nov 7, 2020
@wren wren reopened this Nov 7, 2020
@wren
Copy link
Member

wren commented Nov 7, 2020

@mandarvaze You're absolutely right.

To resolve this ticket, we'll need to update the docs to clarify how new entries in an editor are or aren't different from cli entries.

Thank you for pointing this out!

@wren wren removed the support End user support label Nov 7, 2020
@wren wren changed the title Templates do not work with backdated entries Clarify difference between editor and cli entries in documentation Nov 7, 2020
@wren wren changed the title Clarify difference between editor and cli entries in documentation Clarify difference between editor and cli entries in docs Nov 7, 2020
@stale
Copy link

stale bot commented Jan 9, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Inactive issue: will be closed soon if no activity label Jan 9, 2021
@wren wren added the 📌 This can't go stale label Jan 9, 2021
@stale stale bot removed the stale Inactive issue: will be closed soon if no activity label Jan 9, 2021
@micahellison micahellison added this to the Backlog milestone Sep 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation 📌 This can't go stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants