merge file structure with overview section #739
Conversation
Pull Request Test Coverage Report for Build 11668697245Details
💛 - Coveralls |
| Each content line defines a property that has 3 parts (name, parameters, | ||
| values). Parameters are optional. | ||
| It consists of **content lines**, | ||
| with each content line defining a property that has 3 parts: name, parameters and value. Parameters are optional. |
There was a problem hiding this comment.
| with each content line defining a property that has 3 parts: name, parameters and value. Parameters are optional. | |
| with each content line defining a property that has 3 parts: name, parameters, and values. Parameters are optional. |
|
|
||
| A simple content line with only name and value could look like this:: | ||
| Example 1: a simple content line (with only name and value):: | ||
|
|
||
| BEGIN:VCALENDAR |
There was a problem hiding this comment.
For each example, the default lexer is Python by virtue of the preceding line's ::, but should be text. Would you please update each example with this pattern, replacing :: with ., inserting the code-block directive, and indenting by four spaces the code example?
| BEGIN:VCALENDAR | |
| .. code-block:: text | |
| BEGIN:VCALENDAR |
|
|
||
| On a higher level, you can think of iCalendar files structured as having components and sub components. |
There was a problem hiding this comment.
| On a higher level, you can think of iCalendar files structured as having components and sub components. | |
| On a higher level, you can think of iCalendar files' structure as having components and subcomponents. |
| -------- | ||
| A component will have properties with values. The values | ||
| have special types, like integer, text, and datetime. These values are | ||
| encoded in a special text format in an iCalendar file. This package contains methods for converting to and from these encodings. |
There was a problem hiding this comment.
I've never been a fan of arbitrary line wrapping in narrative documentation, but if we're going to do that, then we should be consistent.
Narrative documentation is not code, and we're no longer constrained by 80-character terminal sessions over dial-up modems when editing. To me, it makes more sense to have one sentence per line, eliminating the need for line wrapping and making for easier review of diffs, but I won't push for it.
Co-authored-by: Steve Piercy <[email protected]>
natashamm
force-pushed
the
file_stucture_overview
branch
from
2aaf054
to
8a4923a
Compare
Co-authored-by: Steve Piercy <[email protected]>
Co-authored-by: Steve Piercy <[email protected]>
|
I think, the docs pass the build. @natashamm , could you add a changelog entry? Let me know when you are done improving the docs! Thanks :) |
|
Also, you can look here to see if it is how you like it: https://icalendar--739.org.readthedocs.build/en/739/usage.html |
From #626
I didn't change much of the content for now.
📚 Documentation preview 📚: https://icalendar--739.org.readthedocs.build/