[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue with (not) restoring original keypad mode on exit
From: |
Thomas Dickey |
Subject: |
Re: Issue with (not) restoring original keypad mode on exit |
Date: |
Sun, 5 Oct 2014 17:28:19 -0400 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Sun, Oct 05, 2014 at 11:59:19AM +0400, Paul Fertser wrote:
> Hi,
>
> When an ncurses application that uses keypad mode is executing another such
> application, the keypad mode gets reset after the child exits, so the
> parent application gets wrong keycodes as it's still expecting keypad mode
> to be active.
I've noticed (had tried using gpg-agent a while back, found that it doesn't
work as a replacement for ssh-agent, but returned to get some of the package
signing done - long story). In xterm, I can reset it with a menu entry...
> The particular issue I have is with mcabber (Jabber client) calling
> (indirectly, via gpgme -> gpg2 -> gpg-agent) pinentry-curses to unlock a GPG
> key, using TERM=screen. After pinentry-curses exits, the bindings are
> obviously
> messed up. This doesn't happen with TERM=linux as it lacks smkx, rmkx
> sequences.
>
> I have no clue how to fix it properly, as there doesn't seem to be any way to
> query the current keypad mode. Probably it would work just fine if screen
> definition didn't include smkx, rmkx at all. Spent a whole day digging this...
I think the place to fix this is in screen, because it "owns" that information.
For instance, one might extend it to implement xterm's save/restore-modes, and
then modify out-of-band applications such as gpgme to do this. Then both
xterm and screen would work. (I did this with xterm's title-strings several
years ago).
(I agree -- there's no way to solve the problem using ncurses)
--
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature