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
Slashes disappear in docstrings #10624
Comments
comment:1
Still present in Sage-5.1.beta0... |
comment:2
In Sage 5.4.beta1, g3 doesn't look as described here: a and b are on different lines, and the same for c and d. I'm not sure how the triple back slashes are supposed to end up anyway. For g1 vs. g2: in the case of g2, the docstring appears to be Sphinx markup (because of the backquotes — see the function We could try to treat all docstrings as Sphinx markup instead. I can't think of another good global solution. For any particular docstring, you can force it to be processed by sphinxify by adding |
comment:3
That's nice that there is an improvement: Sage 5.4.beta0 still shows a and b on the same line while c and d are shown on different as if there was a double slash between them. For g1 and g2 I want the same formatting, so I think that all docstrings should be treated as if they were in Sphinx markup. And the major point is that slashes are treated in a wild unclear way - I understand that they are special characters and something happens to them, but the usual way is to replace double slashes with single ones and non-recursively, i.e. 4 slashes should become 2 and so on. Otherwise it is impossible to produce multiline math. |
comment:4
I've just installed beta1: for me g3? still shows a and b on the same line and if I click to the left of the documentation, I get
so the double slash got replaced with a single one and the triple one with double one. |
comment:5
OK, I think this is what has to be done.
There should be no
Get rid of this - it interferes with multiline math, there is no explanation why this is needed and it seems to work just fine without. I also suspect this
These are in the end and I think these parentheses have to go or the parsing should not refer to them at all. Otherwise math is wrapped twice: once in span/div with I am not sure where this change has to happen and whether it is a bug in Sphinx or Sage. If someone puts these ideas to actual patches or explains how to do it, I will greatly appreciate it. |
comment:6
Re your third suggestion: I would be concerned that this would break regular documentation building. Have you tested it (say with I'll try to look into this and related tickets (like #13455) soon. By the way, another possible change: in sage/sage/misc/latex_macros.py, there is the line
I wonder if the |
comment:7
See sagemath/sagenb#97 for the Sagenb pull request. I think we need to keep the Instead of your item 3, I added a few Should we close this ticket and move discussion to Sagenb at github? |
comment:8
It seems silly to have a test which is always true, why can't we remove Just deleting wrappers feels wrong as it is likely to become a bug once "the real bug" is fixed... But I have no better solution and documentation has to look good now. Will try to figure out reviewing on github! |
comment:10
The latest version on github now just deletes the function |
Reviewer: John Palmieri |
comment:12
I don't think that our proposed changes to sagenb are a good idea anymore. Problems arise when looking at docstrings from other components of Sage; for example, if you do So we should keep working on this (at the sagenb github site, not here), but we need to have a better solution about when to use Sphinx and when not to. |
Consider functions
i.e. they have the same docstrings but the second one has a code block (the same happens with math blocks).
When I type g1? in the notebook, I get pretty much the docstring as it is written, except for a couple of extra blank lines on top. When I type g2?, I get
on a single line. I don't think that the treatment of slashes should depend on the presence of extra blocks in the docstring.
While removing slashes may be done for "deLaTeXifying" purposes, it is actually done (at least partially) before LaTeX processing. The docstring of
in the notebook shows a and b on the same line while c and d on different. For HTML documentation the first block works as it should - a and b are on different lines.
This problem came up on #10479 in the math block of
NefPartition?
.Component: documentation
Keywords: notebook help docstring
Reviewer: John Palmieri
Issue created by migration from https://trac.sagemath.org/ticket/10624
The text was updated successfully, but these errors were encountered: