Skip to content

Requested changes for arduino/reference-en#750 #1

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

Merged
merged 3 commits into from
Jul 15, 2020
Merged

Requested changes for arduino/reference-en#750 #1

merged 3 commits into from
Jul 15, 2020

Conversation

per1234
Copy link

@per1234 per1234 commented Jul 15, 2020

Hi @AshutoshPandey123456. I have some changes to propose to your pull request arduino#750. Unfortunately, GitHub's review system isn't powerful enough to support this particular case, so I'm just submitting them as a PR to the branch of your fork. If you merge this, it will automatically update the PR.

Please see the commit messages of the individual commits for explanation of the requested changes.

I'm happy to discuss my proposed modifications, but it is definitely going to be necessary to modify your PR before it can be merged because it would break the documentation generation system in its current state.

per1234 added 3 commits July 15, 2020 05:53
The newly added content was placed inside the "See Also" section, which caused the generation process to fail:

ERROR 2020/07/15 05:00:40 Language/Functions/Bits and Bytes/bitClear.adoc: asciidoctor: WARNING: <stdin>: line 69: section title out of sequence: expected level 1, got level 2
ERROR 2020/07/15 05:00:40 Language/Functions/Bits and Bytes/bitClear.adoc: asciidoctor: WARNING: <stdin>: line 71: unterminated open block
- Use the standard "Arduino sketch style" formatting.
- Move the print to setup(), so it only happens once.
The zero-indexed nature of the macro is already documented in the parameters section.

The handling of zeroed bits is already clear from the description.

The requirement for the parameters to be integers seems fairly obvious to me, but I'm open to being convinced otherwise. However, if it is necessary to document the supported parameter types, that should be done in the parameters section, following the convention that has been established through the rest of the language reference content, so this part needs to be removed either way.
@ashpande
Copy link
Owner

@per1234

I agree with your reasoning on the modifications. I'll be more wary of these shortcomings in the future, thanks for the suggestions.

@ashpande ashpande closed this Jul 15, 2020
@ashpande ashpande reopened this Jul 15, 2020
@ashpande ashpande merged commit 6fc04ce into ashpande:patch-2 Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants