[Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

By default, curses will only report single ESC key event after 1s delay,
since ESC is also used for keypad escape sequences. This however makes users
believe that ESC is not working. Reducing to 0.2s provides good enough user
experience, while still allowing 200ms for keypad sequences to get in, which
should be more than enough.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 ui/curses.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/curses.c b/ui/curses.c
index b475589..49d3ce6 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -222,7 +222,7 @@ static void curses_refresh(DisplayChangeListener *dcl)
         keycode = curses2keycode[chr];
         keycode_alt = 0;
 
-        /* alt key */
+        /* alt or esc key */
         if (keycode == 1) {
             nextchr = getch();
 
@@ -349,6 +349,7 @@ static void curses_setup(void)
     initscr(); noecho(); intrflush(stdscr, FALSE);
     nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
     start_color(); raw(); scrollok(stdscr, FALSE);
+    set_escdelay(200);
 
     /* Make color pair to match color format (3bits bg:3bits fg) */
     for (i = 0; i < 64; i++) {
-- 
2.8.1

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Peter Maydell]

On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> By default, curses will only report single ESC key event after 1s delay,
> since ESC is also used for keypad escape sequences. This however makes users
> believe that ESC is not working. Reducing to 0.2s provides good enough user
> experience, while still allowing 200ms for keypad sequences to get in, which
> should be more than enough.

That the default delay is this massive seems like a bug in curses,
but I don't suppose it's likely to be changed at this point :-(

-- PMM

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

Peter Maydell, on Wed 22 Jun 2016 21:49:04 +0100, wrote:
> On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> > By default, curses will only report single ESC key event after 1s delay,
> > since ESC is also used for keypad escape sequences. This however makes users
> > believe that ESC is not working. Reducing to 0.2s provides good enough user
> > experience, while still allowing 200ms for keypad sequences to get in, which
> > should be more than enough.
> 
> That the default delay is this massive seems like a bug in curses,

I guess it's a "feature" due to old sluggish terminals.

Samuel

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Peter Maydell]

On 22 June 2016 at 22:06, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Peter Maydell, on Wed 22 Jun 2016 21:49:04 +0100, wrote:
>> On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
>> > By default, curses will only report single ESC key event after 1s delay,
>> > since ESC is also used for keypad escape sequences. This however makes users
>> > believe that ESC is not working. Reducing to 0.2s provides good enough user
>> > experience, while still allowing 200ms for keypad sequences to get in, which
>> > should be more than enough.
>>
>> That the default delay is this massive seems like a bug in curses,
>
> I guess it's a "feature" due to old sluggish terminals.

Even the old mechanical terminals like the ASR33 could do
at least five or six characters a second :-)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

Hello,

Peter Maydell, on Wed 22 Jun 2016 21:49:04 +0100, wrote:
> On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> > By default, curses will only report single ESC key event after 1s delay,
> > since ESC is also used for keypad escape sequences. This however makes users
> > believe that ESC is not working. Reducing to 0.2s provides good enough user
> > experience, while still allowing 200ms for keypad sequences to get in, which
> > should be more than enough.
> 
> That the default delay is this massive seems like a bug in curses,
> but I don't suppose it's likely to be changed at this point :-(

So, could this be applied?  Otherwise e.g. DOS applications ESC actions
are very slugguish and thus look bogus in the ncurses UI.

Samuel

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Gerd Hoffmann]

On Sa, 2016-10-15 at 19:24 +0200, Samuel Thibault wrote:
> Hello,
> 
> Peter Maydell, on Wed 22 Jun 2016 21:49:04 +0100, wrote:
> > On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> > > By default, curses will only report single ESC key event after 1s delay,
> > > since ESC is also used for keypad escape sequences. This however makes users
> > > believe that ESC is not working. Reducing to 0.2s provides good enough user
> > > experience, while still allowing 200ms for keypad sequences to get in, which
> > > should be more than enough.
> > 
> > That the default delay is this massive seems like a bug in curses,
> > but I don't suppose it's likely to be changed at this point :-(
> 
> So, could this be applied?  Otherwise e.g. DOS applications ESC actions
> are very slugguish and thus look bogus in the ncurses UI.

Somehow slipped through and not in my qemu-devel folder any more.
Can you resend?

thanks,
  Gerd

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

Gerd Hoffmann, on Wed 26 Oct 2016 14:51:00 +0200, wrote:
> On Sa, 2016-10-15 at 19:24 +0200, Samuel Thibault wrote:
> > Peter Maydell, on Wed 22 Jun 2016 21:49:04 +0100, wrote:
> > > On 22 June 2016 at 16:44, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> > > > By default, curses will only report single ESC key event after 1s delay,
> > > > since ESC is also used for keypad escape sequences. This however makes users
> > > > believe that ESC is not working. Reducing to 0.2s provides good enough user
> > > > experience, while still allowing 200ms for keypad sequences to get in, which
> > > > should be more than enough.
> > > 
> > > That the default delay is this massive seems like a bug in curses,
> > > but I don't suppose it's likely to be changed at this point :-(
> > 
> > So, could this be applied?  Otherwise e.g. DOS applications ESC actions
> > are very slugguish and thus look bogus in the ncurses UI.
> 
> Somehow slipped through and not in my qemu-devel folder any more.
> Can you resend?

I have bounced it, (its "Date:" is 22 Jun 2016).

Samuel

[Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

By default, curses will only report single ESC key event after 1s delay,
since ESC is also used for keypad escape sequences. This however makes users
believe that ESC is not working. Reducing to 0.2s provides good enough user
experience, while still allowing 200ms for keypad sequences to get in, which
should be more than enough.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

---
rebased on master

diff --git a/ui/curses.c b/ui/curses.c
index 2e132a7..3599295 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -216,7 +216,7 @@ static void curses_refresh(DisplayChangeListener *dcl)
         keycode = curses2keycode[chr];
         keycode_alt = 0;
 
-        /* alt key */
+        /* alt or esc key */
         if (keycode == 1) {
             int nextchr = getch();
 
@@ -345,6 +345,7 @@ static void curses_setup(void)
     initscr(); noecho(); intrflush(stdscr, FALSE);
     nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
     start_color(); raw(); scrollok(stdscr, FALSE);
+    set_escdelay(200);
 
     /* Make color pair to match color format (3bits bg:3bits fg) */
     for (i = 0; i < 64; i++) {

[Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

By default, curses will only report single ESC key event after 1s delay,
since ESC is also used for keypad escape sequences. This however makes users
believe that ESC is not working. Reducing to 0.2s provides good enough user
experience, while still allowing 200ms for keypad sequences to get in, which
should be more than enough.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 ui/curses.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/curses.c b/ui/curses.c
index 6e0091c3b2..700315bc09 100644
--- a/ui/curses.c
+++ b/ui/curses.c
@@ -231,7 +231,7 @@ static void curses_refresh(DisplayChangeListener *dcl)
         keycode = curses2keycode[chr];
         keycode_alt = 0;
 
-        /* alt key */
+        /* alt or esc key */
         if (keycode == 1) {
             int nextchr = getch();
 
@@ -361,6 +361,7 @@ static void curses_setup(void)
     initscr(); noecho(); intrflush(stdscr, FALSE);
     nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
     start_color(); raw(); scrollok(stdscr, FALSE);
+    set_escdelay(200);
 
     /* Make color pair to match color format (3bits bg:3bits fg) */
     for (i = 0; i < 64; i++) {
-- 
2.20.1

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Warner Losh]

On Sun, Mar 3, 2019, 12:45 AM Samuel Thibault <samuel.thibault@ens-lyon.org>
wrote:

> By default, curses will only report single ESC key event after 1s delay,
> since ESC is also used for keypad escape sequences. This however makes
> users
> believe that ESC is not working. Reducing to 0.2s provides good enough user
> experience, while still allowing 200ms for keypad sequences to get in,
> which
> should be more than enough.
>

How did you come up with this number? Still seems a bit long for the ESC
ESC case where the user hits ESC twice in quick succession. Even back in
the day, terminals would send the characters back to back at 1200 baud,
which is 8ms per character. 32ms is 4x that, 32x 9600 baud rates. 25 or
50ms is suggested from these figures.

Warner

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ---
>  ui/curses.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/ui/curses.c b/ui/curses.c
> index 6e0091c3b2..700315bc09 100644
> --- a/ui/curses.c
> +++ b/ui/curses.c
> @@ -231,7 +231,7 @@ static void curses_refresh(DisplayChangeListener *dcl)
>          keycode = curses2keycode[chr];
>          keycode_alt = 0;
>
> -        /* alt key */
> +        /* alt or esc key */
>          if (keycode == 1) {
>              int nextchr = getch();
>
> @@ -361,6 +361,7 @@ static void curses_setup(void)
>      initscr(); noecho(); intrflush(stdscr, FALSE);
>      nodelay(stdscr, TRUE); nonl(); keypad(stdscr, TRUE);
>      start_color(); raw(); scrollok(stdscr, FALSE);
> +    set_escdelay(200);
>
>      /* Make color pair to match color format (3bits bg:3bits fg) */
>      for (i = 0; i < 64; i++) {
> --
> 2.20.1
>
>
>

Re: [Qemu-devel] [PATCH] Reduce curses escdelay from 1s to 0.2s

[Samuel Thibault]

Warner Losh, le dim. 03 mars 2019 10:11:52 -0700, a ecrit:
> On Sun, Mar 3, 2019, 12:45 AM Samuel Thibault <[1]samuel.thibault@ens-lyon.org>
> wrote:
> 
>     By default, curses will only report single ESC key event after 1s delay,
>     since ESC is also used for keypad escape sequences. This however makes
>     users
>     believe that ESC is not working. Reducing to 0.2s provides good enough user
>     experience, while still allowing 200ms for keypad sequences to get in,
>     which
>     should be more than enough.
> 
> How did you come up with this number?

Since the default was very long, I chose a value that felt fast enough
for the user.

> Still seems a bit long for the ESC ESC case where the user hits ESC
> twice in quick succession.

Right, there might be such double-press.

> Even back in the day, terminals would send the characters back to back
> at 1200 baud, which is 8ms per character. 32ms is 4x that, 32x 9600
> baud rates. 25 or 50ms is suggested from these figures.

Alright, let's try 25 then.

Samuel