Fix multiple grammar and spelling issues in docs #1212
Conversation
|
Oh, that's huge 😅 it will take me a while to review. I guess splitting it in multiple PRs per doc isn't an option, is it? |
|
It would certainly be possible, but I'm not sure if it would be worth it. In general, take as much time as you want reviewing this. You can also review each page seperately if you want that 😄 Also funny how codecov is failing, quota reached |
| I'm also pretty sure that more and more utilities will be added over time as | ||
| needs become apparent.<br/> | ||
| I am also pretty sure that more and more utilities will be added over time as | ||
| needs to become apparent.<br/> |
There was a problem hiding this comment.
Nit: needs to feels wrong here. Why that?
| @@ -873,7 +873,7 @@ where constant expressions are required. | |||
|
|
|||
| As long as the list remains unchanged, identifiers are also guaranteed to be | |||
| stable across different runs. In case they have been used in a production | |||
| environment and a type has to be removed, one can just use a placeholder to | |||
| environment, and a type has to be removed; one can just use a placeholder to | |||
| @@ -74,7 +74,7 @@ used mostly in game development. | |||
|
|
|||
| ## Type-less and bitset-free | |||
|
|
|||
| The library implements a sparse set based model that doesn't require users to | |||
| The library implements a sparse set-based model that does not require users to | |||
There was a problem hiding this comment.
Is sparse-set-based better suited maybe? Although I don't like it. Like, at all.
| such as the connection objects or the possibility to attach listeners with a | ||
| list of parameters that is shorter than that of the signal itself. | ||
| list of parameters that are shorter than that of the signal itself. |
There was a problem hiding this comment.
The list is shorter. I think this fix is wrong actually, isn't it?
| reduce the boilerplate in the most complex cases. | ||
|
|
||
| ### Handle | ||
|
|
||
| A handle is a thin wrapper around an entity and a registry. It _replicates_ the | ||
| API of a registry by offering functions such as `get` or `emplace`. The | ||
| difference being that the entity is implicitly passed to the registry.<br/> | ||
| It's default constructible as an invalid handle that contains a null registry | ||
| It is default-constructible as an invalid handle that contains a null registry |
There was a problem hiding this comment.
Uhm, default constructible is quite common in C++ actually. I don't think this one is correct in this sense.
docs/md/entity.md
Outdated
| @@ -2324,7 +2324,7 @@ expedients. | |||
|
|
|||
| Finally, `EnTT` is configured via a few compile-time definitions to make some of | |||
| its parts implicitly thread-safe, roughly speaking only the ones that really | |||
| make sense and can't be turned around.<br/> | |||
| make sense and can not be turned around.<br/> | |||
|
Thank you very much for the review! |
This PR fixes A LOT of general grammar issues, spelling mistakes and converts the prior mix of formal and informal worlds into a coherent mess.
Also, entt is pretty cool and I enjoyed reading all the docs :)