BlissOutput clean up
Some notes about BLissOutput
Maybe related to !5954 (merged)
Related to !5347 (merged), i think this PR improve the state
-
It exposes elog_add
which have nothing to do here.BlissOutput
could just expose the cells index, no need to mix that with elobbooks features -
It's a mixin while i think this should be implemented based on stream/proxy pattern (i think this would simplify the implementation) -
The last feature is something dispatching the write into 2 streams (the one forapp.output
and another one for the builtin print (i guess one for the screen and one for the blissterm) this could be split into a dedicated component based on stream pattern -
_cell_output_history
and_log_stdout_buffer
looks to be the same feature implemented twice in 2 different ways (why do we have that) [ ] -_log_stdout_buffer
was protected against refreshable cells used by scan progress [ ] -_cell_output_history
is not protected for refreshable cells, this could just explode the memory right? [ ] - The responsibility of writing stuffs could be moved outside -
\x1b[1A
and\r
are used to protect against refleshable cells- It's just a guess because a result from print_formatted_text
will probably not be logged (because it will contains\r
)-
This probably have to be handled at higher level, at the place we know cells are refreshable -
There is a an implementation of write
but nowrite_raw
, that's maybe a way to dispatch the content between output and refleshable cells
-
It would be good to have a design document of that
Edited by Valentin Valls