Re: [RFC] Fix pager bugs with style output

[Tom Tromey <tom@tromey.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> One thought, perhaps: Would it make sense to call can_emit_style_escape
Joel> inside emit_style_escape? I'm not entirely sure whether this would
Joel> always work or not. On the one hand, the issue with relying on callers
Joel> of emit_style_escape to verify that it makes sense is that we're bound
Joel> to forget again in the future. On the other hand, I'm trying to think
Joel> what would happen is a user changed XTERM from xterm to dump, for
Joel> instance. Normally, we should always be in the normal style when the
Joel> user has the prompt, so there would be no need to reset it back to
Joel> the default style. One thing I did notice is that a couple of calls
Joel> to emit_style_escape are unprotected in prompt_for_continue: From
Joel> what I can tell, it seems like we'd be emitting ansi sequences when
Joel> in fact we shouldn't?

This is all more subtle than I would like :(

The call to emit_style_escape in set_output_style deliberately does not
pass the stream argument.  But, it does test can_emit_style_escape on
the stream.  Changing this causes regressions because now the output
won't end up in the wrap buffer.  I added a comment to set_output_style.

The calls to in prompt_for_continue do indeed need protection now that
the caching is gone.  I've fixed these.  Also they were emitting to the
wrap buffer, which seems wrong (at least for the first one), because the
wrap buffer isn't flushed here.

There are still mysteries in here to me, too, like why one call to
prompt_for_continue checks "filter" but the other does not.

Tom