The code in pager.cc already handles buffering of Octave output. Are
you not using any of that?
I just look that up to see whether I am. I'm afraid I'm not. I'm rdbuf()ing octave_stdout to my own subclass of streambuf, which dumps everything to the window as soon as it receives it. I guess it would be niftier if I could grab octave_pager_buf's output and stuff, but the functions aren't virtual so I don't see how I can simply reuse the object.
Do you suggest a different approach?
You are using eval_string to process commands typed in the GUI input
window? To me, that doesn't seem like the best way to handle user
input. If you are using eval_string, how do you handle multi-line
input?
I don't handle them. What's the best way? (This is the way that's taught in the
embed.cc example on
octave.sourceforge.net aka octave forge.)
octave.cc:
std::cout is used for startup and version messages. It doesn't
Which means I won't be able to capture it in MinGW (in Linux, I could go back to rdbuf()fing cout, that would probably do it.) Should I just hard code your copyright message into Workshop so it gets printed in the output tab?
parse.y:
parse_and_execute writes info messages directly to std::cout (used
for debugging of which startup files are being read).
Octave maintainer type debugging, or debugging that normal people could want? Because if it's the latter I'm missing it and I might want it.
toplev.cc:
After recovering from an exception, or when exiting, Octave prints
a newline character to std::cout.
Why? I guess a newline isn't too important.