Skip to content

Refactor internal message structure? #32

Description

@killercup

Right now, we use locking and a mutable reference to the target to output stuff. This is not very nice, but allows us to work around using termcolor for Windows support.

Targets can receive multiple messages per item to print, and each message will need to own its data (or be 'static). Another approach would be to have one message per item that contains a vector of control instructions, that the target get execute to get the wanted output.

For human output, I'm thinking of a structure like this:

enum Part {
    Command(Cmd),
    // Option 1: Just send owned strings
    Content(String),
    // Option 2: Use a buffer in the StringArea and refer to slices of it
    Content { start: usize, end: usize },
}

struct StringArena {
    content: Vec<Part>
    // For option 2:
    buffer: String,
}

enum Cmd {
    ResetStyle,
    Bold,
    Underline,
    Foreground(Color),
    Background(Color),
    ClearLine,
}

struct Color(termcolor::Color)

Option 2 would have the additional advantage of being trivial to convert to plain-text – just return the string buffer.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    design decision requiredIt's not yet decided how best to implement this.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions