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

Why require so many timestamps? #103

Open
xeruf opened this issue Oct 11, 2023 · 6 comments
Open

Why require so many timestamps? #103

xeruf opened this issue Oct 11, 2023 · 6 comments
Assignees

Comments

@xeruf
Copy link
Contributor

xeruf commented Oct 11, 2023

Why does a lazyblorg post require a CREATED and a MODIFIED property, if we can already deduce these from the logbook?
This feels annoyingly redundant.
Would be good to document these requirements as well in the steps of the readme, and which timestamp is used for which purpose.

@novoid
Copy link
Owner

novoid commented Oct 14, 2023

Good point. Somewhere I think I summarized the reasoning but that can be made more accessible.

In short: CREATED is created automatically in my setup so it's no effort on my side.

I don't think that MODIFIED is part of lazyblorg.

@novoid novoid self-assigned this Oct 14, 2023
@xeruf
Copy link
Contributor Author

xeruf commented Feb 24, 2024

true, it requires CREATED and a logbook - my setup unfortunately depends on the used file at the moment so I often have to edit post properties
anyways, still don't see the use of this redunancy

@novoid
Copy link
Owner

novoid commented Feb 25, 2024

What do you mean "on the used file"?

@xeruf
Copy link
Contributor Author

xeruf commented Nov 26, 2024

I have different org defaults for different org files.

@xeruf
Copy link
Contributor Author

xeruf commented Nov 26, 2024

So the logbook timestamp is used for dating the post and the published footer, I am struggling to find out what created is used for after all?

@novoid
Copy link
Owner

novoid commented Nov 26, 2024

The parser parses it and stores it under entry_data['created'].

lib/htmlizer.py doesn't seem to use it for anything at the moment.

It looks to me that the parser is expecting it (and reports an error if missing) but it is not used. As a test, you could remove the corresponding check in __check_if_entry_is_OK() (orgparser.py, 4 lines) and do a test-run if everything is working. If so, report back and I'll think about removing it upstream as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants