GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Incorrect syntax highlighting for rf strings · Issue #186 · MagicStack/MagicPython

Incorrect syntax highlighting for rf strings #186

New issue
Copy link
New issue
Copy link
Closed
Closed
Incorrect syntax highlighting for rf strings#186
Copy link

Description

@janosh
janosh
opened on Jul 15, 2019
Issue body actions

Environment data

  • VS Code version: 1.36.0
  • MagicPython version: 1.1.1
  • OS: macOS 10.14.5
  • Color scheme: Dark+ (default dark)
  • Python version: 3.6.7 (miniconda)

Expected behavior

Combining raw strings and f-strings, I'd expect syntax highlighting inside curly brackets.

f-string

Actual behavior

But what I get is the uniform dark red color of raw strings.

rf-string

Related

Issue was originally raised in microsoft/vscode-python#6572.

Reacted by Stuart McCroden, Leonardo Carreiro, sergei, B. Willems, memeplex and DetachHead
Reacted by Toldry

Activity

  1. lmcarreiro commented on Oct 23, 2019

    @lmcarreiro
    lmcarreiro
    on Oct 23, 2019
    More actions

    Another related problem: microsoft/vscode-python#2445

    image

    Update: the lower case r is not wrong, it is a feature to use for regex: #114 (comment)

    Reacted by Victor Petrovykh, Tim Hartman and Gabriel Bider
  2. vpetrovykh commented on Oct 23, 2019

    @vpetrovykh
    vpetrovykh
    on Oct 23, 2019
    Contributor
    More actions

    To reiterate: there's a feature highlighting lower-case r strings as regexp, while upper-case R as simply raw. Using upper-case R should get you the result you want. Compare:

    plt.title(
        (f"{label}: " if label else "") + r"$y_\mathrm{true}$ vs $y_\mathrm{pred}$"
    )
    
    plt.title(
        (f"{label}: " if label else "") + R"$y_\mathrm{true}$ vs $y_\mathrm{pred}$"
    )
    
    plt.title(
        (Rf"{label}: " if label else "") + R"$y_\mathrm{true}$ vs $y_\mathrm{pred}$"
    )

    The lower-case r was chosen for the special treatment largely due to a precedent that some existing highlighters offered this convenience already.

    Reacted by Janosh Riebesell and SyzenEinca
  3. vors commented on Dec 4, 2019

    @vors
    vors
    on Dec 4, 2019 · Hidden as off-topic
    show commentMore actions
  4. kelvinwop commented on Jan 23, 2020

    @kelvinwop
    kelvinwop
    on Jan 23, 2020
    More actions

    image

    capital R makes it do the fstring highlighting

  5. janosh commented on Jan 23, 2020

    @janosh
    janosh
    on Jan 23, 2020
    Author
    More actions

    @vpetrovykh Thanks for this advice. Unfortunately, it's not currently usable with black formatting since black automatically lower cases r-string prefixes. I opened black#1244 to discuss this.

  6. elprans commented on Jan 23, 2020

    @elprans
    elprans
    on Jan 23, 2020
    Member
    More actions

    @janosh Use --skip-string-normalization for black to disable the lowercasing behavior.

  7. janosh commented on Jan 23, 2020

    @janosh
    janosh
    on Jan 23, 2020
    Author
    More actions

    @elprans IIUC, this has other effects besides preventing r-string prefixes from being lower cased (such as not converting single to double quotes).

    Btw, just tested it and it works with auto-format on save by adding skip-string-normalization = true under [tool.black] to pyproject.toml.

  8. gazzar commented on Feb 2, 2020

    @gazzar
    gazzar
    on Feb 2, 2020
    More actions

    I think this decision by the MagicPython devs to apply additional special meaning to a part of the Python language definition is a mistake. I've been wondering for a while why all my raw strings (which are almost never regex's) are highlighted weirdly by VSCode. It's nice to finally understand what's going on but it imposes mysterious behaviour on downstream projects. The simple question is, can this behaviour be disabled by downstream projects by some configuration option?

  9. Mjb141 commented on Feb 3, 2020

    @Mjb141
    Mjb141
    on Feb 3, 2020
    More actions

    I have struggled with this issue constantly. Sometimes disable -> enable works and gets the f-strings highlighting back, but when using WSL this is no longer possible. With MagicPython installed I still don't have f-string highlighting:

    image

    How do I consistently, without needing to install and reinstall, get the f-string highlight?

  10. 1st1 commented on Feb 11, 2020

    @1st1
    1st1
    on Feb 11, 2020
    Member
    More actions

    I think this decision by the MagicPython devs to apply additional special meaning to a part of the Python language definition is a mistake.

    FWIW I agree, that probably was my mistake. The problem is that reverting this isn't an option now -- as magicpython is used by GH to highlight Python code and by multiple IDEs. Millions of people use it daily. To be fair, millions of people used TextMate & SublimeText before that also highlighted r'strings' as regexps.

    @vpetrovykh @elprans That said I think that fr'strings' shouldn't be highlighted as regexps, so perhaps we should revert that change.

    I have struggled with this issue constantly. Sometimes disable -> enable works and gets the f-strings highlighting back, but when using WSL this is no longer possible. With MagicPython installed I still don't have f-string highlighting:

    That seems like a not relevant issue. Perhaps your editor has some plugin that interferes with MagicPython.

    Reacted by Janosh Riebesell and Gary Ruben
  11. vpetrovykh commented on Feb 12, 2020

    @vpetrovykh
    vpetrovykh
    on Feb 12, 2020
    Contributor
    More actions

    Yes, looks like f-strings should be format strings first and foremost, regardless of what other flavor they have.

    Reacted by Janosh Riebesell
  12. elprans commented on Feb 12, 2020

    @elprans
    elprans
    on Feb 12, 2020
    Member
    More actions

    +1 for handling fr'foo' as f-strings. As for the r-strings, we can probably ship an alternative grammar file and have downstream make their choice.

    Reacted by Janosh Riebesell, Gary Ruben and Steven Tondeur
  13. gazzar commented on Feb 12, 2020

    @gazzar
    gazzar
    on Feb 12, 2020
    More actions

    I think this decision by the MagicPython devs to apply additional special meaning to a part of the Python language definition is a mistake.

    FWIW I agree, that probably was my mistake. The problem is that reverting this isn't an option now -- as magicpython is used by GH to highlight Python code and by multiple IDEs. Millions of people use it daily. To be fair, millions of people used TextMate & SublimeText before that also highlighted r'strings' as regexps.

    I think that, at least in the case of VSCODE, they might be happy if this behaviour was reverted. I'm not sure about GH or the other IDE devs' opinions; you would know better than me. Would it be possible to overload the parser to provide an alternative API that the IDEs could swap to or expose to their end users to select whether to use the regex-highlighted version or a plain-string version?

  14. vpetrovykh
    added a commit that references this issue on Jul 31, 2020

    Make raw f-strings consistent.

    This issue will close once commit 507e769 is merged into the 'master' branch.
    507e769
  15. adamkeinan commented on May 17, 2021

    @adamkeinan
    adamkeinan
    on May 17, 2021
    More actions

    I've had the same problem lately. Drove me crazy.
    1.checked all my setting to verify there's no overlap
    2.check the extensions folder to verify i don't have inconsistent versions
    3.simply re-selected my Interperter+path, and that did the job

  16. justanotheranonymoususer commented on Aug 9, 2021

    @justanotheranonymoususer
    justanotheranonymoususer
    on Aug 9, 2021
    More actions

    capital R makes it do the fstring highlighting

    Stumbled upon this today, too. Doesn't make sense and confusing. Would be great to get this fixed.

  17. silkfire commented on Apr 7, 2022

    @silkfire
    silkfire
    on Apr 7, 2022
    More actions

    Why hasn't this been fixed yet? Shouldn't be that hard to add r to the same highlighting category as R.

  18. QuentiumYT
    added a commit that references this issue on May 16, 2022

    Make raw f-strings consistent.

    This issue will close once commit 34f93dc is merged into the 'main' branch.
    34f93dc
  19. vpetrovykh
    added a commit that references this issue on Oct 14, 2022

    Make raw f-strings consistent.

    This issue will close once commit fbc65da is merged into the 'master' branch.
    fbc65da
  20. vpetrovykh
    closed this as completedin 5b5f388on Oct 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.