Re: [PATCHv3 1/2] Initial TUI mouse support

[Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>]

 Am Samstag, 5. Juni 2021, 01:48:38 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-04 9:54 p.m., Pedro Alves wrote:
> > On 2021-06-04 7:46 p.m., Tom Tromey wrote:
> >> Pedro> The trouble is that now pressing anywhere on the screen with the
> >> Pedro> mouse just results in weird characters being printed on the
> >> Pedro> command line window (probably uninterpreted control sequences).
> >>
> >> I tried it here, and it worked fine for me.
> >>
> >> I couldn't select text, but I didn't see any control characters.
> >>
> >> Pedro> This was on Ubuntu 20.04.
> >>
> >> I'm on Fedora 32.
> >
> > I'm currently on Fedora 32 too, and while it works here too, I just found a way to reproduce a similar
> > problem that I'm seeing on the Ubuntu machine (which I currently don't have access to).  (Though
> > on Ubuntu it was worse.)
> >
> > Try this:
> >
> > $ ./gdb ./gdb
> > ...
> > (gdb) start
> > c-x a
> > scroll up and down with mouse to check that it works ok.
> > c-x o # select command window
> > scroll up and down with mouse, and see escape codes being printed on the command window
> >
> > If I "c-x o" again to select the source window, then scrolling works correctly again.
> >
> > If I "c-x o" again to select the command window, then scrolling and clicking with the mouse
> > prints more bad characters.  Like these:
> >
> > (top-gdb) 64;40;21M64;40;21M65;40;21M65;40;21M64;40;21M64;40;21M64;40;21M65;40;21M0;67;32M0;67;32m0;64;18M0;64;18m0;64;18M0;64;18m2;64;18M2;64;18m0;64;18M0;64;18M0;64;18M0
> > ;64;18m1;64;18M1;64;18m64;64;18M64;64;18M1;64;19M1;64;19m1;64;19M1;64;19m2;64;19M2;64;19m0;64;19M0;64;19m0;51;13M0;51;13m0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0
> > ;1;27M0;1;27M0;1;27m
>
> I have access to the Ubuntu machine again now.  The symptom I see now the same as on Fedora -- I can scroll
> the source window, when when I focus on the command window, I start seeing all the badness.  I don't think
> I focused on the command window earlier when I first reported it, maybe there's some other way to trigger
> it, but can't say for sure.  So it is looking like this isn't OS specific afterall.
>
> Sorry for the spotty reporting.  Hopefully the reproducer helps identifying the issue.

On Windows I can mostly reproduce this, when the command window has focus,
mouse scrolling just doesn't work.
I don't see any escape sequences, because the Windows console works different.
I probably wouldn't have noticed this for a long time, because I never set
the focus to the command window (I always wondered why this is possible at all).

Anyways, I think this happens because when the command window gets focus,
we disable the curses keypad.
As the docu says:

  The keypad option enables the keypad of the user's terminal. If enabled
  (bf is TRUE), the user can press a function key (such as an arrow key) and
  wgetch returns a single value representing the function key, as in KEY_LEFT.
  If disabled (bf is FALSE), curses does not treat function keys specially
  and the program has to interpret the escape sequences itself.

I imagine the same is true for mouse escape sequences.
So I would just disable the mouse when the command window has focus, but
what do you think?


Hannes