#562 delay of cursor in GDL console

v1.0 (example)
closed-remind
nobody
None
5
2014-02-14
2013-08-23
Martin Svec
No

This is an interface-related thing. Movement of cursor in GDL console has a notable (and somewhat annoying) delays. Especially after an arrow is pressed down and then released, the last movement is significantly delayed. Compared to xterm. Any ideas?

Discussion

  • giloo
    giloo
    2013-08-27

    Works for me. Works terribly well in fact, compared to IDL's line editing mode: fast, supports line wrapping, etc.
    Wonder what your setup is to get such poor results?

     
  • Martin Svec
    Martin Svec
    2013-08-27

    Well, nothing unusual, latest ubuntu LTS, on a server. Desktop is xorg with xfce. I appreciate Gdl's better functionality. Did you try to hold down the arrow on a long line? Thanks for the reply anyway.

     
    Last edit: giloo 2014-01-21
  • giloo
    giloo
    2013-08-29

    Hi,
    I've made test on my laptop (64 bits, Mandriva 2010.2, KDE, xterm equivalent is 'Konsole'). Works, as I said, like a charm.
    However, when using icewm (i do not have xfce installed) and xterm (or Konsole) i eventually feel a (slight) delay as you describe. So this would arise from a different (unoptimized) handling of keyboard by the 'light' WMs as xfce or icewm???

     
  • Martin Svec
    Martin Svec
    2013-09-03

    I think it is not an issue with any WM. the same behavoiur I can see
    in the console outside of X. The issue appears only in GDL cmd line,
    but not in the console itself..

     
    Last edit: giloo 2014-01-21
  • Martin Svec
    Martin Svec
    2013-09-03

    Sorry to post again, I have been testing a bit more so I can describe
    better now:

    The movement of cursor in GDL cmd line is as rapid as in the normal
    console/xterm/whatever except of these cases:

    1) Delete key has a delay at deleting the last character after the key
    is released.
    2) Home/End keys actions are delayed, although ctrl-E and ctrl-A is immediate!
    3) last cursor movement when held down in a long line and released has
    a delay (so it is tricky to locate it precisely without iterations)
    4) calling statements from history by up/down arrows also has delays
    (ctrl-P/ctrl-N again works)
    5) hitting any of the F's normally produced ~, but with a delay. If
    more of them are typed rapidly, the delay appears only on the last
    one.

    Definitely it has something to do with special keys handling.
    My system is Ubuntu 12.04.2 LTS 64-bit

     
    Last edit: giloo 2014-01-21
  • giloo
    giloo
    2013-09-04

    Hi,
    I am sorry but on my config every movement you describe now precisely is instantaneous. It would be interesting to explore the web in case somebody has complained about sluginess of keyboard input for other applications, on the latest Ubuntu. This could help find the culprit, possibly a "libreadline" problem since we use libreadline for input handling...

     
  • Martin Svec
    Martin Svec
    2013-09-04

    Hmm.
    It makes me really curious why this happens for Ubuntu and not for
    Mandriva. I will try to convince my colleague with Suse to test it.
    Not able to find examples of similar things on the web.

    Other programs, that rely on libreadline6, particularly octave,
    python, bc, ftp etc., do not suffer of this problem. My GDL was
    compiled with libreadline-dev 6.2-2.

    Have found another small harmless issue with the GDL cmdline that
    could be related or not - try to paste some characters with accents,
    for example four times the angstrom symbol - Å. and then hold down
    backspace to see the "GDL> " vanish. Or instead, you can press down
    left arrow and see how the cursor goes over the "GDL>". Presence of
    any such symbol in the cmd line also prevents using ctrl-D. If ctrl-C
    is pressed, the buffer will still hold this character. Same behaviour
    in the plain console out of X-windows.

    I wonder if you can reproduce anything of this.
    Anyway, thanks for your great effort at improving GDL!

     
    Last edit: giloo 2014-01-21
  • Martin Svec
    Martin Svec
    2013-09-05

    I found a description that closely matches the original problem:

    https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2012/007705.html

    -see the email that is commented

    However, its on Mac OSX, they also blame readline. I will try to see
    if I can downgrade libread and make the problem disappear.

     
    Last edit: giloo 2014-01-21
  • giloo
    giloo
    2014-01-21

    As a followup:
    On a new Mageia3 with lib64readline6-6.2-7 All the symptoms reported by Martin are present, with various degrees of annoyance. The worst being the delay in the last displacement of the cursor when using the arrows (^F and ^B work perfectly). This is definitely a libreadline bug.

     
  • giloo
    giloo
    2014-01-21

    Hi.
    Made some tests rebuilding and linking GDL with libreadline 6.1 and 6.2
    Bug is not present in 6.1 and appears in 6.2
    I was able to trace it back to changes in (readline's)input.c between the two versions.
    I submitted a report to readline maintainers.
    In the meantime I advise to use readline <= 6.1

     
  • giloo
    giloo
    2014-01-21

    A quick comparison of both sources point on the culprit lines in input.c. If line 430 of input.c from 6.2 is replaced by line 430 of input.c from 6.1 problem disappears:

    $ diff input.c input.c.orig
    430c430
    <         while (rl_event_hook && rl_get_char (&c) == 0)
    ---
    >         while (rl_event_hook)
    
     
    Last edit: giloo 2014-01-21
  • giloo
    giloo
    2014-01-21

    • status: open --> open-invalid
     
  • Has anyone reported this to bug-readline@gnu.org?

     
  • giloo
    giloo
    2014-01-29

    Actually, one has. And got answers. It looks like the change introduced between readline 6.1 and 6.2 now triggers the use of GDLEventHandler() on keyboard timeouts. So we're back to GDL and we'll make a patch.

     
  • giloo
    giloo
    2014-01-30

    I tested GDL after removing the call to GDLEventHandler() and the bug has disappeared. So this is definitely a GDL problem (handler takes too long to activate and/or do... nothing). I change back the ticket to open.

     
  • giloo
    giloo
    2014-01-30

    • status: open-invalid --> open
     
  • giloo
    giloo
    2014-02-14

    • status: open --> closed-remind
     
  • giloo
    giloo
    2014-02-14

    solved by reverting to default event handler for all readline events.