Andreas Grapentin

yeah, I collected whatever I could find on the subject.

apologies, it seems I completely misunderstood what you were asking on IRC. I agree that adapting the output_format parameter in the config file makes a lot more sense.

rebased to master and applied requested changes. this feature probably also needs a documentation change, but I'm unsure where the right spot would be to add it

> please check CI results, mostly black formatting I fixed the issues reported by tox in 7702cf1 -- thanks for pointing that out.

I took a step back, and started looking into i3status first. I created a PR for tmux output in i3status here: https://github.com/i3/i3status/pull/484

Independently of the PR on i3status, it seems to me like the most reasonable way forward would be for py3status to *require* the value of output_format in general to be...

this PR now enables full support for the all output_format values supported by i3status (plus tmux) in py3status. py3status now carries an array of output_format values for which a join...

I agree with the point that these output formatters should probably be object oriented. this was just a quick way to write them very similarly to what is included in...

the latest commit introduces an object oriented approach to the output formatting. it's a lot more code than the if cascades, but probably better decoupled.

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...