Code Monkey home page Code Monkey logo

Comments (11)

willmcgugan avatar willmcgugan commented on May 21, 2024

You can prevent markup being applied by setting markup=False on the print() function, or disable it everywhere by setting markup=False on the Console constructor.

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

You can prevent markup being applied by setting markup=False on the print() function, or disable it everywhere by setting markup=False on the Console constructor.

That would disable all markup, not just markdown, correct? That doesn't seem right, since the different markups are quite distinct. The non-markdown markup isn't really an issue. And the rest of markdown requires you to instantiate a Markdown object. I don't think these specific items are special enough to be treated differently.

I think the desired behavior would not require users who will need to print filenames to find this behavior for the first time and then disable it every time.

Moreover, rich.print does not have a markup parameter like Console.print.

from rich.

willmcgugan avatar willmcgugan commented on May 21, 2024

The markup switch purely effects console markup, and only the automatic styling when you pass a string. It won't effect how the Markdown class is rendered.

I think the desired behavior would not require users who will need to print filenames to find this behavior for the first time and then disable it every time.

I would think being able to disable it everywhere, or a line-at-a-time would cover most use cases. What else would you suggest?

Moreover, rich.print does not have a markup parameter like Console.print.

That's intentional, the rich.print function has the same signature as the builtin print. I don't want to change that because the two functions should be interchangeable.

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

The markup switch purely effects console markup, and only the automatic styling when you pass a string. It won't effect how the Markdown class is rendered.

I was asking if it disabled the bbcode-style markup, which apparently it doesn't. Which seems even stranger to me when the docs seem clear that it is also considered markup (and it is technically markup). At least if it were named markdown, it'd properly describe what it does, unless it's supposed to disable it all but doesn't.

Moreover, bbcode has all the markdown formatting covered in its syntax. Wouldn't it make more sense to just use all bbcode-style markup by default and leave markdown to markdown. Especially since it conflicts with at least somewhat common use cases.

I would think being able to disable it everywhere, or a line-at-a-time would cover most use cases. What else would you suggest?

This is less of a problem if the markup option doesn't apply to the bbcode-style. If the markup option applied to all markup, then this would be a serious problem. But I think the solution is to not have markdown syntax by default. Require a Markdown instance for it, just use bbcode markup by default.

That's intentional, the rich.print function has the same signature as the builtin print. I don't want to change that because the two functions should be interchangeable.

Would a keyword argument that people would only have to know if they're using rich.print actually be an issue? I understand and use a Console for the most part, but anyone testing this out may run into this kind of issue and not be able to do anything about it.

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

I was asking if it disabled the bbcode-style markup, which apparently it doesn't. Which seems even stranger to me when the docs seem clear that it is also considered markup (and it is technically markup). At least if it were named markdown, it'd properly describe what it does, unless it's supposed to disable it all but doesn't.

Correction, apparently that's only when used on Console.print. Console(markup=False) works and disables all markup.

So, I will say, that means that if I want to correctly render filenames while using a style somewhere else in the line, on the filename itself, or in another part of a table, I simply can't?

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

With Console.print(markup=False): https://waa.ai/TUqt.png
With Console(markup=False).print it doesn't appear to be overridable per Console.print`` call either, maybe related: https://waa.ai/TUqm.png

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

or in another part of a table

and only the automatic styling when you pass a string

Just remembered you said this. So, you're also saying that the options don't work with some inputs? That's an odd inconsistency. And an undocumented one if that's true.

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

or in another part of a table

and only the automatic styling when you pass a string

Just remembered you said this. So, you're also saying that the options don't work with some inputs? That's an odd inconsistency. And an undocumented one if that's true.

https://waa.ai/TUqF.png

Guess I'm not exactly sure what that means then.

from rich.

willmcgugan avatar willmcgugan commented on May 21, 2024

There was a bug with passing through the markup flag. Should be fixed in master.

Let me just clarify a few things, so we're on the same page... The console markup is neither valid bbcode nor markdown, I've just borrowed the syntax. I may end up dropping the "markdown style" syntax, because it does mean there are two ways of doing the same thing.

Neither the "markdown style" or the "bbcode style" markup can be used for filenames (even square brackets are valid in filenames). So you will have to disable markup for that.

If you aren't using console markup, you can construct a Text object and print it. The Text interface gives you a number of ways to add styles to text: you can append styles, or apply styles that match a regex for example. See Rich Text.

Would a keyword argument that people would only have to know if they're using rich.print actually be an issue?

But then if you decided not to use Rich, your prints would break wherever the keyword is used. rich.print is convenient, but constructing a Console object is necessary if you need more control.

This conversation will help me when I flesh out the docs, as I'll know where to focus.

from rich.

thebigmunch avatar thebigmunch commented on May 21, 2024

The console markup is neither valid bbcode nor markdown

This isn't strictly true. Some of it certainly is taken straight from bbcode and markdown.

Neither the "markdown style" or the "bbcode style" markup can be used for filenames (even square brackets are valid in filenames). So you will have to disable markup for that.

The point was precisely that the markdown syntax contains character patterns that can be (and are) used in filenames while the bbcode style does not. And that caused a problem. Not that I want to use them in filenames specifically. Underscores, specifically, are a common replacement for spaces in filenames and certain sources of text.

But then if you decided not to use Rich, your prints would break wherever the keyword is used. rich.print

Maybe this stems from the fact that I would never actually use or promote it as just print but rich.print. If they were using any features from rich in these print calls, they would break anyway, just more subtly, and require changes. But I brought it up more for documentation purposes than anything.

I may end up dropping the "markdown style" syntax, because it does mean there are two ways of doing the same thing.

I'm really going to push for this. Its functionality is already covered, it breaks somewhat common use cases, and it can even prevent using some basic rich functionality. I don't see any reason for hesitation here.

from rich.

willmcgugan avatar willmcgugan commented on May 21, 2024

This isn't strictly true. Some of it certainly is taken straight from bbcode and markdown.

It is true in the strictest sense. Let's agree to differ.

The point was precisely that the markdown syntax contains character patterns that can be (and are) used in filenames while the bbcode style does not.

"[bold]foo.txt" is an entirely valid filename in Windows / Linux / OSX.

I'm really going to push for this. Its functionality is already covered, it breaks somewhat common use cases, and it can even prevent using some basic rich functionality. I don't see any reason for hesitation here.

You may get your wish, but the bbcode suffers from the same problem -- it's just somewhat less likely to clash that the "markdown" like syntax.

from rich.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.