py3status doesn't parse separator

[lasers]

Describe the bug

py3status doesn't parse separator. When you add a separator string config inside general config section, it doesn't use it.

See @oaken-source's comment no2 too... #2104 (comment)

2.) i3status uses the separator config setting in the general section to set the separator string between module outputs. Setting this in py3status causes an issue because the config expects separator to be a boolean when looking transitively through the configure options for the modules. Apparently, there is a difference here between the way py3status and i3status handle the configuration files. Note the HACK comment in py3status/module.py.

Also, #2104 (comment)

Your py3status version

git

To Reproduce
Steps to reproduce the behavior along with your py3status configuration (filter out any private values):

1. Add this config

general {
    separator = " OK "
{

Expected behavior

Expecting OK separators. Printing | separators instead.

[lasers]

(FWIW) This issue exists in tag 3.15 before I added more module/global options in working 3.16.

[oaken-source]

as far as I can tell, the i3bar output format, which in the main branch is the only supported output format of py3status, doesn't support custom separators. i3status parses this field to concatenate the other non-json based output formats it supports, which are added in PR #2104

The issue I was running into while working on that PR was that setting this value to a non-boolean value will crash py3status when applying the general config options to the modules, where the separator config option has different semantics than on the global level.

[lasers]

I think you're right. The problem is that I was looking at different/default output between i3status and py3status in the terminal by swapping between i3status and py3status on a same config.

When I make separate configs, add output_format = ... to both config, the comparison looks more consistent.

[lasers]

I think you're right. The problem is that I was looking at...

Solved by #2202.... Probably.