Describe the feature you'd likebyexample disables or turns off the echo of the terminal so any input is not echoed back and it is not being displayed on the "screen" which would get mixed the the interpreter's output.
This turn off happens at the moment that the runner/interpreter is spawned.
However some interpreters turn the echo on which makes byexample's efforts ineffective. This is the case of python on MacOS.
Other interpreters may implement their own terminal emulation which ignores the echo setting. This is the case of ipython and any program based on python-prompt-toolkit.
We cannot do anything with the latter but we can solve the issue in the former case.
We could call pexpect's setecho(False)before executing each source code, ensuring that the interpreter will not have a chance to turn it on again. We may call setecho(False) only once after the interpreter initialization if calling it before each source code exec is too slow.
Describe alternatives you've considered (optional)
An alternative could execute within the interpreter a shell and run there stty -echo but calling setecho(False) seems less hacky and faster.
Compatibility
For interpreters that honor the echo turned off during the spawn, calling setecho(False) should not change anything.
However for interpreters that don't honor and turn the echo on, calling setecho(False)may break user's examples.
Consider an user running byexample in MacOS. To make any sense of python's output mixed with the echoed code, the user probably is running byexample with +force-echo-filtering. This unfortunately requires that the interpreter is really echoing the code. If we "fix" the issue calling setecho(False), we'll make python to not echo the code on MacOS (good) but it will break any user running +force-echo-filtering because now, no echo has to be filtered!
It would be tempting to say "if the echo was successfully turned off, ignore +force-echo-filtering" but this does not work.
+force-echo-filtering implies +term=ansi so this heavily changes the way that the output is processed. Ignoring +force-echo-filtering will break the examples too.
some interpreters emulate a terminal and they will totally ignore the echo setting even if the echo is turned off so +force-echo-filtering still has value.
Probably the safest thing to do is to say "if +force-echo-filtering is on, do not call setecho(False)" and update the documentation for MacOS users that they can try byexample 11.0.0 without setting +force-echo-filtering.
Describe the feature you'd like
byexample
disables or turns off theecho
of the terminal so any input is not echoed back and it is not being displayed on the "screen" which would get mixed the the interpreter's output.This turn off happens at the moment that the runner/interpreter is spawned.
However some interpreters turn the
echo
on which makesbyexample
's efforts ineffective. This is the case ofpython
on MacOS. Other interpreters may implement their own terminal emulation which ignores theecho
setting. This is the case ofipython
and any program based on python-prompt-toolkit.We cannot do anything with the latter but we can solve the issue in the former case.
We could call
pexpect
'ssetecho(False)
before executing each source code, ensuring that the interpreter will not have a chance to turn it on again. We may callsetecho(False)
only once after the interpreter initialization if calling it before each source code exec is too slow.Describe alternatives you've considered (optional) An alternative could execute within the interpreter a shell and run there
stty -echo
but callingsetecho(False)
seems less hacky and faster.Compatibility
For interpreters that honor the
echo
turned off during the spawn, callingsetecho(False)
should not change anything.However for interpreters that don't honor and turn the
echo
on, callingsetecho(False)
may break user's examples.Consider an user running
byexample
in MacOS. To make any sense ofpython
's output mixed with the echoed code, the user probably is runningbyexample
with+force-echo-filtering
. This unfortunately requires that the interpreter is really echoing the code. If we "fix" the issue callingsetecho(False)
, we'll makepython
to not echo the code on MacOS (good) but it will break any user running+force-echo-filtering
because now, no echo has to be filtered!It would be tempting to say "if the
echo
was successfully turned off, ignore+force-echo-filtering
" but this does not work.+force-echo-filtering
implies+term=ansi
so this heavily changes the way that the output is processed. Ignoring+force-echo-filtering
will break the examples too.echo
setting even if theecho
is turned off so+force-echo-filtering
still has value.Probably the safest thing to do is to say "if
+force-echo-filtering
is on, do not callsetecho(False)
" and update the documentation for MacOS users that they can trybyexample 11.0.0
without setting+force-echo-filtering
.