Docs: Simplify hierarchy of headings in rule pages

[pedrottimark]

As another step toward a recommended structure for rules pages, reduce the number of depth distinctions in headings to eliminate inconsistencies in depth h2 versus h3.

Because these changes prefer less depth, they also lean toward a potential goal that each page displays a table of contents, suggested by @IanVS in eslint/archive-website#186 (comment)

86 files changed:

• h3 from 145 occurrences in 93 files to 150 occurrences in 55 files
• h4 from 104 occurrences in 39 files to 13 occurrences in 7 files
• h5 from 12 occurrences in 6 files to 0 occurrences
• h3 + h4 + h5 from 261 occurrences in 93 files to 163 occurrences in 55 files

For comparison, no h5 and the only h4 outside rules are 27 occurrences in user-guide/command-line-interface.md

Changes to anchors:

• deleted h4 Usage
  • accessor-pairs.md
  • consistent-this.md
• deleted h3 Nomenclature
  • no-mixed-requires.md (moved content to Rule Details)
• added h2 Options in several files which I forgot to keep a list of ;)
• replaced h2 Rule Options with Options
  • no-warning-comments.md
  • sort-vars.md

The next goal is consistent punctuation of options in h3 elements.

[mention-bot]

By analyzing the blame information on this pull request, we identified @gyandeeps, @IanVS and @mathieumg to be potential reviewers

[ilyavolodin]

This is probably for the next pass, but it looks like in most place we use code brackets for options as in all and not double quotes.

[nzakas]

We should try to format options the way they actually are in the config file, so strings should be in quotes, and nonstrings should be in code font.

[ilyavolodin]

This is so awesome! Can't thank you enough for this work!
Build is failing because of 2 commits, they need to be squashed. We are trying to stabilize version 2.0 release right now, so I'll wait till around Friday before merging this in.

[pedrottimark]

Thank you for the tip how to move forward. The green check looks so much better than the red x.

Still early in moving from closed to open source, each step stretches me in some way. Starting the journey with rackt and eslint have both been supportive community and worthwhile purpose.

[ilyavolodin]

@pedrottimark It looks like something caused a merge conflict with this PR. Could you rebase please? I was about to merge it, but can't do that without rebase...

[pedrottimark]

@ilyavolodin Sure, I need to learn how to rebase because of changes. Starting right now. Will let you know if I get stuck ;)

[ilyavolodin]

Awesome, thanks! Let me know if you need any help, I'll be happy to walk you through rebasing process.

[pedrottimark]

@ilyavolodin A bit of help.

git rebase found one conflict because Options had been deleted from no-empty.md which I had not edited. I edited to delete the conflict-marked area, git add, and git rebase --continue which succeeded.

git log for the branch now shows 3 commits: from me, mysticatea, and nzakas. So I am not sure whether I can now git push, or do I need to squash them?

[ilyavolodin]

That shouldn't happen with rebase. Did you run git pull --rebase or just git pull? What you are describing sounds more like merge not rebase.
Also instead of manually editing conflicts by hand you can use git mergetool which will open whatever is the tool that you have registered as a default merge tool (by default vi, I think). Let me try to do a quick rebase and then I can submit PR over to your branch.

[pedrottimark]

@ilyavolodin Thank you. My bad, here is what I did 😳
git fetch upstream
git rebase upstream/master

[ilyavolodin]

Sorry, I got a bit destructed here. Can you try the following in your local branch:

git reset --hard origin simplify-hierarchy-in-rules
git remote add upstream git@github.com:eslint/eslint.git (might need to change this to https if you are not using ssh)
git remote -v (should display two origin and two upstream urls)
git pull --rebase upstream master
git mergetool (will open vi most likely for you to edit merge conflicts, save and close once you are done)
git rebase --continue
git push -f origin simplify-hierarchy-in-rules

I think that should do it. I can do a full merge myself, but I haven't done that in Github before and I'm not sure how it's going to end up in the logs.

[pedrottimark]

@ilyavolodin Thank you for investing the time to give me that lesson. Except for adding a slash origin/simplify-hierarchy-in-rules and I will need to configure my git mergetool, it went well. Hard for me to see from the Details why the AppVeyor build failed.

I have been planning the remaining changes for low-frequency headings. Because that will affect 15 to 20 files, I am thinking better to wait until next week.

[ilyavolodin]

AppVeyor is having an issue downloading PhantomJS, so not related to your changes at all. Travis had the same issue on the master build earlier.

Thanks a lot of doing this work!

[IanVS]

Yay for consistency. Thanks, @pedrottimark!

[pedrottimark]

@IanVS You’re welcome. If “a foolish consistency is the hobgoblin of little minds” mine is foolish and little enough. If you can’t fix it, feature it, eh?