Allow terminal escapes in LogSender messages.

[remexre]

Is this possible? \x01 and \x02 don't work.

[murarth]

I'm hesitant to add anything more to the LogSender API. The real problem, I think, is that one is not able to access functions of a Reader concurrently and I think that's a problem better solved in a different way.

I had been working on project to rewrite the linefeed internals, which could enable concurrent operation. When I have the time, I'd like to finish that up. Until then, I don't know if I'll be making any feature additions.

[remexre]

I wasn't really envisioning API changes here; I was thinking more that when Reader sees a message it should allow ANSI escapes (though this would probably be nontrivial).

Is there anything that wouldn't work with just passing a &Mutex<Reader> or Arc<Mutex<Reader>> around?

[murarth]

Having LogSender print escape sequences as-is would be a breaking change. There would have to be a new method for sending text that is not to be escaped.

Sorry, I was unclear. What I meant by "concurrent operation" was any operation running concurrent to Reader::read_line. This method takes a &mut self reference, so even a Mutex<Reader> would not be able to provide another reference until the method returns and the lock is released. In order to allow other functions to be called concurrent with read_line, the method must be changed to take &self. Reader would then likely use Mutex internally to manage concurrent mutation of its operational data.

[remexre]

Are there any workarounds for this right now though?

Something that might work would be to change the sender to either send an enum like below, or a Box<FnOnce(&mut Reader)>.

enum Command {
  SendPlain(String),
  SendStyled(String),
  SetBuffer(String),
  SetCursor(usize),
  // ...
}

[murarth]

The changes described in my previous comment have been implemented: The LogSender API has been removed. Writing concurrent with a read_line call is possible without channels, using the Writer type. It doesn't have a method to write unescaped data to the terminal, but you could just write directly to stdout (while holding the write lock).