-
-
Notifications
You must be signed in to change notification settings - Fork 21.2k
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
Add [note]
, [warning]
, [important]
and [tip]
blocks to the editor help
#63079
base: master
Are you sure you want to change the base?
Add [note]
, [warning]
, [important]
and [tip]
blocks to the editor help
#63079
Conversation
a3033b6
to
f828b66
Compare
Oh, nice idea. Though the yellow for the light theme can probably be more saturated (and darker?). |
It might be worth tweaking the general |
f828b66
to
91749b3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Besides the notes that I've left, there is an issue with the fact that it's a block now. In blocks we allow new lines, and the built-in docs handle this fine
But the RST generation does not, as the new lines are not indented appropriately.
We should either strip the new lines, or support it correctly.
doc/tools/make_rst.py
Outdated
@@ -1016,6 +1016,7 @@ def rstize_text(text, state): # type: (str, State) -> str | |||
|
|||
# Handle [tags] | |||
inside_code = False | |||
inside_note_warning = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not used in any way. Should it? There is a bunch of logic attached to inside_code
, but I guess there is no special parsing for these tags. So, no reason to add this?
doc/tools/make_rst.py
Outdated
tag_text = "" | ||
tag_depth -= 1 | ||
inside_note_warning = False | ||
# Strip newline if the tag was alone on one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that it's copied from the above sample, but I don't get that comment. It feels like it's cut off, or it's a typo. Do you know what it actually supposed to mean and can you fix it (here and above too)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied that part without understanding what it was really useful for.
editor/editor_help.cpp
Outdated
|
||
} else if (tag == "warning") { | ||
// Warning block. | ||
p_rt->push_color(warning_color); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why it works correctly, but we should probably add a special case for note/warning blocks, like we do for code blocks, and set a flag. So when we pop the tag from the stack (around line 1768 as of your PR), we properly pop the color.
I think it currently works without visible issues because a new color is pushed somewhere, but I don't think that we correctly handle the extra color here.
I'm all for better styling things which should be emphasized, but I wonder if the way we currently use Having a level of emphasis similar to the reST one seems useful but then we might want to review all our existing |
I've also looked into other existing line prefixes that we have.
|
I think reST has |
Would be nice to revisit this. I still have the concern from #63079 (comment), but I think we could start by adding support for admonitions like on the online docs (e.g. for top-level stuff like #79206), and evaluate in a follow-up how we want to make use of them for existing class ref descriptions. In particular, we'd have to see how the online docs would look like if we were to convert all |
[note]
and [warning]
blocks to the editor help[note]
, [warning]
, [important]
and [tip]
blocks to the editor help
91749b3
to
ec8e78b
Compare
I've rewritten the implementation from scratch, with new I've marked the PR as draft as there are 2 outstanding issues:
|
ec8e78b
to
c88eeb0
Compare
Is there still interest for this PR? I would absolutely love this, for one. |
I don't know how to address the remaining issue, so feel free to salvage this if you'd like. It would be hugely appreciated 🙂 |
Follow-up to #62710.
Benefits include:
Preview