How to handle output.

[agathazeren]

There are a number of reasons why we wouldn't want to just use print!.

• Adding spaces after multispace characters.
• If we decide to upgrade from a terminal
• Handling windows function call based apis

Potential options:

• use the gag crate to capture stdout and postproccess it
• write a custom ui_print! macro that will do the post processing
• write a custom reader that does the postprocessing and into stdout. and use write! to write to it.

Also, when should the spaces be applied to the cuneiform characters? I'm thinking that they should only be applied at the end, with the rest of the code assuming they are the width they actually are. But we could do it at different points.

[agathazeren]

Another issue with adding the spaces at the end is that if we enter cuneiform characters in our source code, they will have to have spaces after them, or the code will look really ugly in our editors. (Unless the editors handle it right. Or worse, some do and some don't.) We could easily write a macro to strip those spaces at compile time though.

[yvnat]

Display should be handled by a class. All code will use the functions for this class, and that way it will be trivial to change the implementation of the display without affecting the code. Very generally, the class would look something like this:

class Display
    putCharacter(character, x, y)   //mark a character to be put at a specific x and y position (this does not display the character yet)
    putString(string, x, y)         //similar to putCharacter but for strings; x represents the position of the beginning of the string
    clear()                         //clear the terminal
    display()                       //display all new characters to the terminal at once

//display() and putCharacter() are separate because it is usually much faster to write a lot of characters at once than even a few characters one at a time

Interfacing with this class should also mostly be limited to a specific class that handles UI and maybe a few methods within the other classes. The UI class should be responsible for putting spaces after the cuneiforms.

[agathazeren]

I agree that there should be a separate UI struct, but I don't agree that display needs to be it's own struct. I would just use the a macro call from the UI code that directly prints out on the screen. (But with some post processing; there are several ways to do this.) (also Rust doesn't have classes) I don't think that making this a class will have much benefit. keep in mind that since the terminal is controlled by escape codes, all control instructions are embedded in the strings.

[yvnat]

A display struct isn't necessary if the program is meant to be implemented for only one environment, but it will probably be implemented at least for both Linux and Windows. Embedding display into the UI ensures that a lot of logic would need to be changed, and two parallel versions of the UI would need to be maintained, for no significant performance gain. Separating display into its own struct allows for much simpler porting, and isn't much more complex than using macros within the UI struct.

[agathazeren]

There would not need to be any invasive changes. Only the function(s)/macro(s) that actually do the work may need to be changed slightly, if at all. Perhaps just a little conditional code in the post processor. Also, macros are not unwieldy. print! and println! are macros in rust, in order to do formatting at compile time and allow variadic parameters.

[agathazeren]

Before cuneiform can be handled correctly, we need to decide how we are handling spaces. We have agreed it should be right before output, but I don't know if we should capture stdout, use a custom reader, or use a ui_print macro.

[agathazeren]

I’m currently leaning towards a ui_print macro. What are your thought?

[agathazeren]

By a custom reader, I meant a custom class that implements Write. (and I confused reading and writing). Also, I wrote a ui_print! macro to see how it would be done, with mock proccessing, https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d6135bea4cd69bc553fedf6a2007d35b

[yvnat]

If I understand correctly, there shouldn't be much of a difference between the way that a custom writer would be used and a the way a ui_print macro would be used, aside from the fact that one is a macro and one is a class. Since I don't understand rust nearly well enough to determine which way would be better, I will entirely defer to what you think is best

[agathazeren]

So I guess we will go for the ui_print!. For reference, a writer would be used like this: write!(UI_OUT, "{}", "Foo"), while ui_print, is used like this: ui_print!("{}", "Foo")