On Thu, Jan 28, 2010 at 9:00 AM, John W. Eaton
<address@hidden> wrote:
On 27-Jan-2010, Michael D Godfrey wrote:
| On 01/27/2010 10:12 AM, Shai Ayal wrote:
| > Will changing octave_kbhit to use readline's rl_read_key&
| > rl_set_keyboard_input_timeout (which call the input_event_hook) break
| > anything?
What will happen if Octave is configured with --without-readline? I
think your proposed change needs to be conditional on having readline
available.
Does rl_read_key have the same behavior as the current octave_kbhit
function? Looking at the readline sources, it appears that
rl_read_key can return '\n' if the rl_event_hook function sets
rl_done. It seems that could have strange results. But I'm not sure
of how this is intended to work. How would you distinguish between a
'\n' character coming from user input and one generated by rl_read_key?
If rl_read_key can be adapted so that the behavior of the current
octave_kbhit function does not change except to call the
input_event_hook function, I'd also prefer to avoid calling any
readline functions directly from Octave. All calls to readline should
go through the command_editor class.
If all you want is to have the event hook function called in a few
more places, then why not just call the input hook function where it
is needed?
What I want is to have the input event hook function called periodically, so that even during a long pause the figure windows remain responsive.
It seems that if this behavior is implemented in octave_kbhit It should take care of this issue. Any hints before I take a stab at this?
Shai