Tinylog entry separator #15

Open
opened 6 months ago by bacardi55 · 1 comments
Owner

As Hedy incidated in #14:

One tiny problem - I often write more than "just a few lines" of things for each entry, but the RFC says:

format: Any text without 2 new lines.

Maybe this needs to change to remove the 2 new lines so tools can only look for lines starting with "## date" ?

My main concern with this is date it is a backward compatibility break and lace (and gtl and others) would need an update to be compatible.

As a reminder, that's the format describe by lace originally:

Then entries must consist of a date in a format that date -d can understand as input as a level 2 heading and then a single newline and then text with no double newlines (i.e. no paragraph breaks. Single line breaks are fine) and no links. I’m not happy about there being no links and intend to fix that later.

As Hedy incidated in #14: > One tiny problem - I often write more than "just a few lines" of things for each entry, but the RFC says: > > <Content> format: Any text without 2 new lines. Maybe this needs to change to remove the 2 new lines so tools can only look for lines starting with "## date" ? My main concern with this is date it is a backward compatibility break and lace (and gtl and others) would need an update to be compatible. As a reminder, that's the format describe by lace originally: > Then entries must consist of a date in a format that date -d can understand as input as a level 2 heading and then a single newline and then text with no double newlines (i.e. no paragraph breaks. Single line breaks are fine) and no links. I’m not happy about there being no links and intend to fix that later.

Maybe this needs to change to remove the 2 new lines so tools can only look for lines starting with "## date" ?

I think this should be the format. Authors can put anything they like in the content section apart from ## headers, and parsers would only look for lines that starts with ## to separate entries.

As a reminder, that's the format describe by lace originally:

Then entries must consist of a date in a format that date -d can understand as input as a level 2 heading and then a single newline and then text with no double newlines (i.e. no paragraph breaks. Single line breaks are fine) and no links. I’m not happy about there being no links and intend to fix that later.

I understand we should avoid breaking compatibility, but firstly, I don't even think the "a level 2 heading and then a single newline" should be required. Especially since different people have different opinions in how to format gemtext -- newline under each heading, paragraph breaks like markdown, etc. And secondly, by "no double newlines" does that mean that an empty line are acceptable, but two empty lines are not within each entry?

> Maybe this needs to change to remove the 2 new lines so tools can only look for lines starting with "## date" ? I think this should be the format. Authors can put anything they like in the content section apart from `##` headers, and parsers would only look for lines that starts with `##` to separate entries. > As a reminder, that's the format describe by lace originally: > > Then entries must consist of a date in a format that date -d can understand as input as a level 2 heading and then a single newline and then text with no double newlines (i.e. no paragraph breaks. Single line breaks are fine) and no links. I’m not happy about there being no links and intend to fix that later. I understand we should avoid breaking compatibility, but firstly, I don't even think the "a level 2 heading and then a single newline" should be required. Especially since different people have different opinions in how to format gemtext -- newline under each heading, paragraph breaks like markdown, etc. And secondly, by "no double newlines" does that mean that an empty line are acceptable, but two empty lines are not within each entry?
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.