[DOC] document how this is different to sphinxcontrib-proof

[mmcky]

@najuzilu beyond the obvious styling improvements would you be able to put a list together of the differences between this project and sphinxcontrib-prettyproof. It would be helpful in the docs when people are trying to decide which to use etc.

From memory you had lots of issues with sphinxcontrib-proof

[najuzilu]

Let me explain very briefly some of the reasoning behind the implementation and syntax.

During the first two iterations of this extension, I followed the instructions under Developing a “recipe” extension to create the different directives. The main reason I chose to use a domain is because I wanted the numbering of the directives to depend on the previous directive regardless of its name. If I had placed the directives under their respective domains, then the numbering would depend only on the previous directive of the same name (example: theorem 1, theorem 2, corollary 1, conjecture 1, conjecture 2, ...).

Unlike sphinxcontrib-proof, I wasn't using enumerable_node but was instead generating the number myself. I realized, after I had finished the first iteration that the numbering wasn't working as I had hoped. The order in which the documents are processed cannot be controlled/reordered according to the toctree because the reading phase is designed to run independently of other documents (in case it's invoked in parallel). So, I had to find a way through Sphinx to number each node which is where enumerable_node came in handy.

The syntax is similar to sphinxcontrib-proof primarily because both implementations use domains, but also because I wasn't sure what to call the domain so I ended up using the same name (hoping we'd change it to something more inclusive).

However, unlike sphinxcontrib-proof, this extension supports the following options for most directives:

• label - allows users to reference the directive
  sphinxcontrib-proof supports this through targets:

  .. _righttriangle:
  
  .. proof:definition:: Right triangle
  
  A *right triangle* is a triangle in which one angle is a right angle.

  The equivalent in this extension would be:

  ```{proof:definition} Right triangle
  :label: righttriangle
  
  A *right triangle* is a triangle in which one angle is a right angle.
  ```

  I included these options keeping in mind that other directives such as math and figure use a similar approach; I was going for consistency.
  proof:proof is the only directive which does not support a label option. I made this decision after realizing that proofs aren't generally referenced as much.
• class - to allow users to customize directives
• nonumber - to allow users to remove the number

The biggest headache I had with sphinxcontrib-proof was the actual referencing throughout the text. In order to reference a directive, you have to remember its target name and type (theorem, definition, corollary, etc.). Here's an example:

You can label and reference definition and theorems (e.g. :numref:`theorem {number} <pythagorean>`). 
You can also reference proofs (see the :ref:`proof of the Pythagorean theorem <proof>`).

I found this to be too cumbersome (or maybe I'm just that lazy haha). I didn't want to have to remember the type in addition to the target. So, I decided that the labels will by default incorporate the type when referenced. This is what the equivalent of the references above would look like in this extension:

You can label and reference definition and theorems (e.g. :proof:ref:`pythagorean`). 
You can also reference proofs (see the :proof:ref:`proof of the Pythagorean theorem <proof>`).

[mmcky]

Thanks @najuzilu we should copy this to the docs :-).

[mmcky]

Do we use any code from sphinxcontrib-proof?

[najuzilu]

Thanks @najuzilu we should copy this to the docs :-).

Working on it... :-)

Do we use any code from sphinxcontrib-proof?

We don't use any code from sphinxcontrib-proof.

[choldgraf]

Can I ask for one extra piece of information here? I think we should also document why this package is a different package from sphinxcontrib-proof, and not a set of improvements that we upstreamed to that package. In general we should try to upstream improvements to other tools as much as possible, and only build our own tools if there's an incompatible difference between what we're doing and what is out there. Did we make this assessment before creating prettyproof?