Fix some multiline platonic solids plot documentation

[kcrisman]

Some platonic solids in plot/plot3d/platonic.py do not evaluate correctly in the live documentation in the notebook, because they are spread over multiple lines. Things like

sage: dodecahedron(color='orange', opacity=0.8) + \
      sphere(size=0.5, color='black')

become split into the input cell and output cell.

I'm not sure if this is really a notebook bug or a parsing bug when the live documentation is made. An easy way to fix it is to change the line breaks but that would likely lead to less readability.

CC: @robertwb @sagetrac-mvngu

Component: documentation

Author: Frédéric Chapoton

Branch/Commit: c8ebabb

Reviewer: Nathann Cohen

Issue created by migration from https://trac.sagemath.org/ticket/10922

[a-andre]

comment:1

Could you improve the problem description. The problem is not clear to me.

[kcrisman]

Description changed:

--- 
+++ 
@@ -1,8 +1,9 @@
-Some platonic solids in plot/plot3d/platonic.py are not correct, because they are spread over multiple lines.  Fix this.  
-
-Things like 
+Some platonic solids in plot/plot3d/platonic.py do not evaluate correctly in the live documentation in the notebook, because they are spread over multiple lines.  Things like 
 
 ```
 sage: dodecahedron(color='orange', opacity=0.8) + \
       sphere(size=0.5, color='black')
 ```
+become split into the input cell and output cell.
+
+I'm not sure if this is really a notebook bug or a parsing bug when the live documentation is made.  An easy way to fix it is to change the line breaks but that would likely lead to less readability.

[kcrisman]

comment:2

It took me a while to reconstruct this! Thanks for the reminder.

[kcrisman]

Attachment: Screen Shot 2014-08-22 at 1.58.14 PM.png

Picture of problem

[fchapoton]

Author: Frédéric Chapoton

[fchapoton]

Branch: u/chapoton/10922

[fchapoton]

Commit: c8ebabb

[fchapoton]

New commits:

c8ebabb

trac #10922 clean-up of doc of platonic solids

[nathanncohen]

comment:4

Good to go!

About RR(1)->RR.one(). I assume that you do this because it is how it is 'advised' as it is apparently faster (I have no first-hand experience on these matters), but I still find RR(1) better for the doc since it is more user-friendly.

Well. Matters of taste.

Thanks for this branch,

Nathann

[nathanncohen]

Reviewer: Nathann Cohen