Updated poutput to use new style_output definition.

[anselor]

Closes #1268

[codecov]

Codecov Report

Patch coverage: 84.84% and project coverage change: -0.04% ⚠️

Comparison is base (adc5a71) 97.96% compared to head (7785320) 97.93%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1269      +/-   ##
==========================================
- Coverage   97.96%   97.93%   -0.04%     
==========================================
  Files          22       22              
  Lines        5700     5705       +5     
==========================================
+ Hits         5584     5587       +3     
- Misses        116      118       +2     

Files Changed	Coverage Δ
cmd2/cmd2.py	97.55% <81.48%> (-0.09%)	⬇️
cmd2/ansi.py	100.00% <100.00%> (ø)
cmd2/argparse_custom.py	95.33% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kmvanbrunt]

I like the idea of adding a psuccess() method. However, I have reservations about applying style in poutput() for the following reasons.

1. The docstring for ansi.style_output says it "colors text for normal output." That implies all output will have this style. However, async alerts, tab completions, prompts, and argparse help text aren't printed with poutput(). A developer would need to edit other functions to acheive a matching style.

2. Adding apply_style to ppaged() and pfeedback() is confusing since style is only applied when the msg text is sent by these functions to poutput().

3. Adding the apply_style argument to poutput() breaks any existing code which prints already styled text since it defaults to True. In practice developers won't notice a visible change since style_output defaults to nothing. However, their code is still wrong since they aren't setting apply_style to False when they call poutput.

@tleonhardt What are your thoughts?

[anselor]

I feel part of the issue is our current print methods conflate where to send output with how to send output. I've made some adjustments that move in the direction of keeping things separate.

[anselor]

@tleonhardt @kmvanbrunt ?

[kmvanbrunt]

Should the signature for pwarning() match that of pfailure() (i.e. remove apply_style).
This seems appropriate since we now have two wrappers for perror(). They should work the same way.

[anselor]

I was reluctant to make an API breaking change to pwarning(). I don't know if it's possible to mark a single argument deprecated.

[anselor]

I added a deprecation to the parameter documentation. We can remove it in the major version revision.