ultrabug / py3status

py3status is an extensible i3status wrapper written in python

Home Page:https://ultrabug.github.io/py3status/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Pango markup for modules nested inside groups broken in version 3.43

diabonas opened this issue · comments

Describe the bug
In py3status version 3.43, modules inside groups that have Pango markup enabled are not rendered correctly: the markup is shown verbatim instead of getting turned into a styled text. This is a regression from version 3.42.

Note that only modules inside groups appear to be affected, modules placed at the top level have their markup rendered correctly.

Your py3status version
py3status version 3.43 (python 3.10.4) on sway

To Reproduce
Consider the following minimal configuration:

order += "group test"

group test {
    static_string {
        format = "<b>test</b>"
        markup = "pango"
    }
}

When run with py3status 3.43, it produces the following output:

{"version": 1, "click_events": true, "stop_signal": 20}
[[]
,[]
,[{"full_text": "&lt;b&gt;test&lt;/b&gt;", "markup": "pango", "instance": "_anon_module_0 0", "name": "static_string"}]

Note that the markup characters are escaped, meaning that the module will be rendered verbatim as <b>test</b>.

Expected behavior
When running the above configuration with py3status 3.42, the output is as follows:

{"version": 1, "click_events": true, "stop_signal": 20}
[[]
,[]
,[{"full_text": "<b>test</b>", "markup": "pango", "instance": "_anon_module_0 0", "name": "static_string"}]

Since the characters are not escaped, the module renders as test as expected.

Additional context
A bisect shows that this issue was introduced by commit cf98b89.

What's the real config that broke this?

My actual configuration looks similar to the minimal example, but with multiple group members that are external_scripts instead of static_strings: I am using some custom scripts that produce multi-coloured output using Pango markup. Several of these scripts are grouped together so that I can cycle through them by clicking on the group.

So something like

order += "group test"

group test {
    button_next = 1

    external_script {
        script_path = "myscript1.sh"
        markup = "pango"
    }

    external_script {
        script_path = "myscript2.sh"
        markup = "pango"
    }

    external_script {
        script_path = "myscript3.sh"
        markup = "pango"
    }
}

where the output of the custom scripts looks like

a: <span color="red">1</span>, b: <span color="yellow">2</span>, c: <span color="green">3</span>

(Opinion) I think py3status should stop trying to escape pango markups for the users. Let users do it themselves in the format and/or in the scripts too... is which why I want to see what the real config looks like... then that would be all. Also, we might have to escape markups only for the placeholders someday if necessary.

Seeing your example, you don't have to change anything because you already did this for your output. It's just that py3status changed replacing from single & to &amp;... to multiple html entitles now.

Also, IIRC when I looked at this last time, there were other issues too... First, it was basically hard to make pango markup working nicely with py3status formatter... and secondly, having pango markup on ought to break interactive modules on purpose too.

https://github.com/lasers/py3status/tree/no-more-html

I agree that escaping Pango markup would never be useful for me since I do all the formatting myself anyway. I am not sure whether there are other use cases where this is necessary, but I would argue that when users explicitly enable Pango markup, they should be aware of having to do HTML escaping themselves if necessary.

I guess the origin of this code path, commit fe027c0, intended to make it a bit easier to use ampersands, but even that seems (slightly) wrong because Pango markup could theoretically contain XML entities.

I would therefore support removing the escaping altogether as proposed by lasers@57a4f84.

I agree culprit modules should be fixed and it's not the job of the formatter to try to be smarter