bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two issues with using ncurses with "gdb -tui" on Windows


From: Thomas Dickey
Subject: Re: Two issues with using ncurses with "gdb -tui" on Windows
Date: Fri, 2 Jan 2015 13:08:15 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jan 02, 2015 at 05:55:09PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 2 Jan 2015 10:40:54 -0500
> > From: Thomas Dickey <address@hidden>
> > Cc: address@hidden
> > 
> > >  . When GDB displays a string with embedded TAB characters, ncurses
> > >    displays an IBM graphics character instead of an appropriate number
> > >    of spaces.  Is this a problem to be solved in ncurses, and if so,
> > >    is there any existing feature to request such a TAB expansion?  Or
> > >    is this an unportable assumption in GDB, and should be handled
> > >    there?
> > 
> > From the context, and your followup email to mingw-users, I think you're
> > talking about the case when ncurses isn't running, e.g,. gdb is using
> > stdio directly.  If gdb were using ncurses, the tab would be converted
> > to spaces.
> 
> No, I'm talking about invoking GDB as "gdb -tui", in which case GDB is
> using curses, see the file tui-io.c in the GDB sources.  It defines a
> callback for the Readline library (tui_redisplay_readline), and that
> callback uses waddch to display characters.
> 
> Which ncurses functions expand tabs on output?

It _could_, if one enabled the hard-tabs configure option.  For any of the
windows ports (cygwin, mingw, msys2), that likely would not work, since it
relies on the device (terminal driver) to do this.

That's in painting the display (an optimization choice).

> 
> > >  . The arrow and other keypad keys do not work in the GDB command
> > >    window.  When that window is active, GDB calls the 'keypad'
> > >    function with the 2nd argument FALSE.  As result, it looks like
> > >    ncurses stops sending any valid code for these special keys (other
> > >    keys, like ASCII characters, and control characters, like Ctrl-p,
> > >    continue to work).  Does ncurses support disabling the keypad mode
> > >    on MS-Windows, and if so, what should the application do to ensure
> > >    this support?
> > 
> > Normally (unless some application does something), those keys do not send
> > characters.  I've thought about providing dummy strings (e.g., to match some
> > existing terminal), but arguably it's correct as is, and without knowing 
> > how an
> > application might use the strings, I don't see a need to change ncurses.
> 
> Sorry, I'm not sure I'm following.  What does ncurses do now on
> Windows, when the application calls 'keypad' to disable the keypad?
> Does the behavior of getch and wgetch changes in any way after such a
> call on Windows, when the arrow keys are pressed?  Or does ncurses
> send nothing when these keys are pressed?

There might be something (I'm not where I can test) - but reading the code,
        + The timed-wait function discards keydown events if keypad mode's off.
        + The console-read function discards keydown events if keypad mode is
          off and there was no character associated with the event.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]