nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] Patch for !ncurses


From: David Ramsey
Subject: Re: [Nano-devel] Patch for !ncurses
Date: Mon, 3 Dec 2007 21:57:12 -0600

On Dec 3, 2007 8:45 PM, OBATA Akio <address@hidden> wrote:

<snip>

> I'm not a curses expert,

Okay.  I wasn't sure whether you were or not.  I hope I'm not getting
too technical below.

> but it seems that NetBSD curses manage termios by own way after
> initscr(). So, raw() is a function in curses, it effect to curses, but
> using termios directly, it does not effect anything. Control-C is
> ignored but application can't get the key code.

If termios and NetBSD's curses interact like this, I'm wondering whether
it affects other areas where curses and termios mix.  With (unpatched)
nano 2.0.6 built against NetBSD curses, and not running with the -p
option, do pressing Ctrl-S and Ctrl-Q in nano 2.0.6 give you the
"XON/XOFF ignored, mumble mumble." messages?  (If nano's -p option isn't
used, the flow control characters are shut off using termios, because
there's no way to do that using curses.)

> > Regarding patch 2: A wrefresh() every time the cursor moves gets
> > expensive in terms of screen updates.  Also, nano uses wnoutrefresh()
> > after reset_cursor() in other places.  So, does adding
> > "wnoutrefresh(edit);" instead of "wrefresh(edit);" in the place the
> > second patch does work with NetBSD curses?
>
> No.

One question: By "no," do you mean "no, because the man page says the
proposed changes won't work", or "no, I tried making the changes, and
they didn't fix the problem".  If so, could you try making the changes
and let me know whether they fix the problem?  See below for why.

> In NetBSD's man page:
>
>       The wnoutrefresh() function performs the internal processing
>       required by curses to determine what changes need to be made to
>       synchronise the internal screen buffer and the terminal but does
>       not modify the terminal display.
>
> The window must be refreshed somewhere.

It is.  When all pending keyboard input has been handled (directly via
get_kbinput(), and indirectly via get_key_buffer()), get_key_buffer()
calls doupdate(), which does that synchronization.  This is why many
other places that call reset_cursor() follow it with wnoutrefresh();
that way, as soon as all the typing has been processed, the screen will
be updated only once, instead of many times during typing (that's what
nano 1.2 did, which is why 1.2 was much slower over remote connections,
which is why I changed it in 2.0).  That's how it's supposed to work,
anyway.

Thanks for your patience.




reply via email to

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