🐛 Fix markdown formatting #815
Conversation
Includes fix to typo in function name. Ref: fastapi#447
There was a problem hiding this comment.
Thanks for the PR!
Before I review the actual code edits, I want to take a step back and better understand what the desired output would be. In the linked issue #447, the author uses this example:
@app.command(name="tester-cmd", help="""
Header
Line 1
Line 2
Line 3
""")
which they want to get parsed (expected output) as
Header
Line 1
Line 2
Line 3
However, with this PR, the output would actually be
Header
Line 1 Line 2 Line 3
(at least on my Windows system)
While currently on master it's
Header
Line 1 Line 2 Line 3
With mode rich, the output on master is
Header
Line 1
Line 2
Line 3
and this PR changes that to
Header
Line 1
Line 2
Line 3
Is that what we want?
Basically, I suggest that we first extend the test suite to cover various versions of the test (different number of newlines and different modes) and record which is the expected output for each. Then, we can look into how to get that fixed for all cases.
|
The source: I think ought to have a space after E.g. while this is just one HTML formatter, it renders space between I suspect it will be very hard to find any Markdown-to-HTML formatter that doesn't do this. I'd be curious to see it! On this basis, I don't think the PR is controversial. I would re-engage the OP for #447 and get his or her thoughts. |
Can you elaborate? With this PR, that input gives me There's a space after Header, but the lines still aren't separated. Is that what you'd expect? I'm asking because the current unit test doesn't cover this case. |
|
I agree, whatever the agreed upon formatting behavior, the test case should include that source to put the matter to rest per the OP issue. I should correct my comment above: not all markdown-to-html formatters treat text blocks the same. There are two ways to treat text block that I'm seeing:
The GitHub formatter, e.g. uses method 1. You can try this by pasting the source and previewing it. The lines appear on separate lines. This f 8000 ormatter uses method 2. If you paste the source in you'll see the text block is treated as one block. The lines don't appear separately. The same is true for Python's I would still argue that typer should implement method 2. I think this is typical for tools and source code (where editors help enforce max line lengths with formatting), whereas the GitHub formatter is suited for human editing in simple text areas (like this one!) I'm happy to add that test case. |
That would be great, yes! Looking at some detailed unit tests will help us decide what the final behaviour is we want/need. Update: we could potentially also included the cases reported in #449. |
|
Update: I've solicited feedback from Tiangolo on PR #964 to first establish what the ideal output is for a variety of use-cases. This will help us better understand the changes proposed in this PR as well. I know that some of these edits may seem straightforward, but as I was writing the additional unit tests it became clear to me that there are a lot of different edge cases and interdependencies of the code paths, so I think it's important to get this all straight first. I will get back to this PR once we've decided on the other one. Thanks for your patience! 🙏 |
|
Hello, I am writing a Typer based application for which i need fairly elaborated command help messages. I am impacted by the problem described at #447 and i am looking for a solution. I don't mean to be pushy, but i am looking for the best thing to do and i wonder if i shall simply go through the monkey patch suggested on the issue or if i should wait for this to be merged. Is there any plan to incorporate the new code any time soon? Thank you Regards |
Includes fix to typo in function name.
Ref: #447