[Top][All Lists]

[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>

Attachment: signature.asc
Description: Digital signature

reply via email to

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