Replacing curses

Thomas Dickey dickey at saltmine.radix.net
Wed Feb 8 19:16:28 EST 2006


Ian Ward <ian at excess.org> wrote:
> Thomas Dickey wrote:
>> hmm - I've read Urwid, and most of the comments I've read in that regard
>> reflect problems in Urwid.  Perhaps it's time for you to do a little analysis.
>> 
>> (looking forward to bug reports, rather than line noise)

> A fair request.  My appologies for the inflammatory subject :-)

> When trying to check for user input without waiting I use code like:
> window_object.nodelay(1)
> curses.cbreak()
> input = window_object.getch()

> Occasionally (hard to reproduce reliably) the cbreak() call will raise
> an exception, but if I call it a second time before calling getch the
> code will work properly.  This problem might be related to a signal
> interrupting the function call, I'm not sure.

perhaps a more complete test-case would let me test it and see.

> Also, screen resizing only seems to be reported once by getch() even if
> the user continues to resize the window.  I have worked around this by
> calling curses.doupdate() between calls to getch(). Maybe this is by design?

Or perhaps it's some interaction with python - I don't know.
The applications that I use with resizing (and ncurses' test
programs) work smoothly enough.

> Finally, the curses escape sequence detection could be broadened. The
> top part of the curses_display module in Urwid defines many escape
> sequences I've run into that curses doesn't detect.

That's data (terminfo).  ncurses is data-driven, doesn't "detect"
features of the terminal (though it does of course use environment
variables for locale, etc.).

xterm's terminfo lists a lot of function keys, for instance.

The limit for predefined function-key names for terminfo is 60,
but ncurses can accept extended terminfo descriptions (but I like to
limit the length and style of names so it's possible to access them
from termcap).  One could define names like shift_f1, but then termcap
applications couldn't see them.  (The last I knew, slang doesn't either,
but that's a different thread).

That's been true for about 6 years.

Current xterm's terminfo includes these names which apply to your
comment:  The ones on the end are extended names that ncurses' tic
deduces from the terminfo file when it compiles it:

comparing xterm-new to xterm-xf86-v44.
    comparing booleans.
    comparing numbers.
    comparing strings.
        kf49: '\EO3P', NULL.
        kf50: '\EO3Q', NULL.
        kf51: '\EO3R', NULL.
        kf52: '\EO3S', NULL.
        kf53: '\E[15;3~', NULL.
        kf54: '\E[17;3~', NULL.
        kf55: '\E[18;3~', NULL.
        kf56: '\E[19;3~', NULL.
        kf57: '\E[20;3~', NULL.
        kf58: '\E[21;3~', NULL.
        kf59: '\E[23;3~', NULL.
        kf60: '\E[24;3~', NULL.
        kf61: '\EO4P', NULL.
        kf62: '\EO4Q', NULL.
        kf63: '\EO4R', NULL.
        kind: '\E[1;2B', NULL.
        kri: '\E[1;2A', NULL.
        kDN: '\E[1;2B', NULL.
        kDN5: '\E[1;5B', NULL.
        kDN6: '\E[1;6B', NULL.
        kLFT5: '\E[1;5D', NULL.
        kLFT6: '\E[1;6D', NULL.
        kRIT5: '\E[1;5C', NULL.
        kRIT6: '\E[1;6C', NULL.
        kUP: '\E[1;2A', NULL.
        kUP5: '\E[1;5A', NULL.
        kUP6: '\E[1;6A', NULL.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net



More information about the Python-list mailing list