Closed
Conversation
998739c to
007a4ac
Compare
35468e2 to
c42a7b6
Compare
Collaborator
Author
|
After some offline discussion previously with @Julow, we agreed to drop the concept of adding back ticks to everything that appears as OCaml code as that would cause cluttering of the markdown output, thus making it unreadable and leading to unexpected poor rendering. In that case, we decided to let OCaml code be formatted using the h6 level. For example; would be formatted as (without backpacks) — whereas, it would be formatted as (with back ticks) — |
Signed-off-by: lubegasimon <lubegasimon73@gmail.com>
Signed-off-by: lubegasimon <lubegasimon73@gmail.com>
Signed-off-by: lubegasimon <lubegasimon73@gmail.com>
Signed-off-by: lubegasimon <lubegasimon73@gmail.com>
c42a7b6 to
1a934c6
Compare
Signed-off-by: lubegasimon <lubegasimon73@gmail.com>
Collaborator
Author
|
‘ocam-ci' is failing because of |
This changed upstream and is broken since a rebase.
- Use an incrementing integer for better control - Avoid putting a normal space between each nbsps
Avoid adding headings for bits of code like '}' or 'end'.
We keep the inlining code for now, as it is partially used for other purposes (variants, records) and in case we'd want to add it back.
16c0b28 to
0c45ebb
Compare
Handle the InternalLink case correctly.
Noops shouldn't be present in the tree to respect the contract:
noop ++ x = x ++ noop = x
Remove the special handling of Text nodes that was a work around this.
This is not a requirement but helps when inspecting the document.
Also: - Make sure to terminate the last line of the document. - Avoid using 'String.split_on_char' for compat
4f9a548 to
0b10e6f
Compare
- Remove custom string functions - Ensure compatibility
The document contains HTML entities that we can match specifically. For future proofing, any other entity can use the HTML syntax.
Closed
Collaborator
|
This looks like a big PR, and should probably not be part of 2.4 |
Closed
Member
|
Superseded by #1341 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Todo:
h6level after the last variant of a constructor. Also thespacing between
h6and items is not neat.EntityandRawmarkupbranches forInline.tare not yet handled ininlinefunction.Help needed!
Reasonably use a single back tick and double back ticks for code spanning.
In cases where source code contains ‘`’, we want to wrap the content in double back ticks,
other wise, wrap the content in single back ticks.
at-tag keys and definitions should not be rendered on separate lines (This is one one the properties of
blocks,that is,
blocksmust be separated by an empty line). That is,should be rendered as
@author : John Doe.The unwanted behaviour is because the definition of the
at-tagis type blocks—
John Doe, where as@author :is inlines, as a consequence, if anythingis to be combined to the
definition, it must beblocks.(I don’t think there is a workaround for this, but I will be happy to see how it can be improved)
There are unwanted spaces rendered between some
inlines. For examplemodule Bar : sig ... endshould instead bemodule Bar : sig … end.For clarity, in the output, there are two spaces between
moduleandBar, two spacesbetween
Barand:, and three spaces afterend. I think I’m wrongly treating the outputof the document library.
If someone is ready to take on this, I will be happy to see it improved. However, I advise to do
this after the next list item.
The use of join and item_prop isn't nice
, it should perhaps be heading insteadEntirely get rid of join (iff there is a better alternative to combine inlines).