Comments (9)
What is your suggestion for changing the current behaviour? That newlines should be collapsed but double-newlines should be kept as double-newlines?
For me the main point is that a single line break in the docstring is simply a way to keep to code tidy (and not having a 500-characters long line), so it makes sense that rich_click
removes them to fit the terminal windows, because that's the whole point of using rich, letting it handle layout stuff. A new line doesn't really influence how the text reads.
OTOH, a double line is something the person writing the docstring does to better structure the help text. There is a reason why it's put in a certain place. And as you said, click also respects these, so also from a technical standpoint, if rich_click
aims to almost be a drop-in replacement for the click
import, then this behavior should be replicated.
Honestly, for the markdown case, I think it's enough to simply split summary and verbose help text, but without touching the verbose text, as that should be fully interpreted as a markdown document.
from rich-click.
Hi @ewels, that works great as a workaround, thanks!
from rich-click.
I will not be touching the default behavior of rich-click. But, I think it is reasonable to include a formatting feature such as COLLAPSE_DOUBLE_NEWLINES
(name is tentative) which is by default set to False
, so users have more control over this behavior. I will look into this.
from rich-click.
This behaviour is kind of intentional. Because we can have quite wide terminal rendering with rich, it makes sense that we want to render paragraphs in a justified manner. If you're writing your docstrings with PEP 8 with 79 character line lengths and only 60 chars to play with you're going to have a tonne of whitespace off to the right.
Collapsing single line breaks and replacing double line breaks with single was my response to this, and whilst it's crude I'm not sure that I can really think of a better way to do it:
rich-click/src/rich_click/rich_click.py
Lines 167 to 174 in cb612ff
With the markdown rendering I basically don't do anything and it should render in the same way as any other markdown text.
Currently there are two ways around this - double the number of newlines you have in your docstrings or use the \b
click modifier.
What is your suggestion for changing the current behaviour? That newlines should be collapsed but double-newlines should be kept as double-newlines?
from rich-click.
That newlines should be collapsed but double-newlines should be kept as double-newlines?
Re-reading those click rewrapping docs (which I don't think I had seen at the time that I wrote this code) I'm thinking that you're probably right. As click was already doing the newlines thing then maybe we should mimic the same behaviour.
For default text handling anyway, I'm not super keen on changing how Markdown parsing works.
from rich-click.
There is a reason why it's put in a certain place.
Sure, I think we're agreeing on the intent and overall behaviour. That's why rich-click
already keeps them - just with a single newline instead of the original double. It's the same behaviour as the rich markdown rendering.
I think you're probably right that most people will expect the blank spacing newline though. It means less compact output but we can probably add a configuration variable to maintain the current behaviour for people who prefer it (like me 😅, at least with long help texts). It's the only way I can think of to make single newlines without the blank possible.
from rich-click.
Is there any progress on this issue? I'm quoting an example input file like this:
For example, the following is a valid group list file:
\b
# Physics 101
## Group A
Drew Ferrell (800057) [second year]
Amanda James (379044)
Antonio Morris (804407) [skips thursdays]
but because rich-click is eating newlines, it turns into:
For example, the following is a valid group list file:
# Physics 101
## Group A
Drew Ferrell (800057) [second year]
Amanda James (379044)
Antonio Morris (804407) [skips thursdays]
so the example input file does not stand out from the main help text (there are more paragraphs of text leading up to this example).
from rich-click.
Not really sorry @davidfokkema. However in your case it's fairly easy to solve - it's not eating all newlines, just collapsing double to single. So if you double up then it works as expected:
For example, the following is a valid group list file:
\b
# Physics 101
## Group A
Drew Ferrell (800057) [second year]
Amanda James (379044)
Antonio Morris (804407) [skips thursdays]
Renders as:
For example, the following is a valid group list file:
# Physics 101
## Group A
Drew Ferrell (800057) [second year]
Amanda James (379044)
Antonio Morris (804407) [skips thursdays]
from rich-click.
Sounds like a good compromise 👍🏻
from rich-click.
Related Issues (20)
- Test help output in `rich-click` CLI is robust to lazy loading of modules. HOT 3
- Add `pytest-snapshot` or `syrupy` or similar HOT 1
- Expose a way to send usage information to stderr HOT 9
- Rich-Click does not translate the ascii codes into colors on windows 64 cmd.exe anymore HOT 3
- support providing a default/global `option_groups` config to apply to all commands HOT 7
- Unit tests should assert output to stderr on errors
- Either update or deprecate MacPorts install HOT 5
- `text_markup: Literal["rich", "markdown", "rst", None]` config option HOT 1
- Additional style options HOT 1
- `rich-click` CLI for version `1.8.0dev1` breaks backwards compatibility in edge case
- 1.9 wishlist
- 2.0 roadmap
- 'RichGroup' object has no attribute 'isolation' HOT 2
- Bugs (a) generating svg/html with decorator. (b) with root directory scripts HOT 1
- Interim blog post - "5 cool pre-made styles for your CLI" (title tentative)
- Color part of the help massage HOT 8
- OptionHighlighter is deprecated and will be removed in a future version. HOT 6
- Invalid MRO when importing rich_click HOT 4
- Continuting to receive "DeprecationWarning: OptionHighlighter is deprecated" as of 1.8.1 HOT 2
- Fix warning (again)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rich-click.