[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: Paul Fertser
Subject: Re: Issue with (not) restoring original keypad mode on exit
Date: Mon, 6 Oct 2014 11:44:36 +0400
User-agent: Mutt/1.5.23 (2014-03-12)


On Sun, Oct 05, 2014 at 05:28:19PM -0400, Thomas Dickey wrote:
> On Sun, Oct 05, 2014 at 11:59:19AM +0400, Paul Fertser wrote:
> > 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).

This really sounds messy to me, and requiring gpgme to issue custom
sequences behind ncurses's back doesn't seem like a clean solution.
Probably if a custom control sequence that implements saving and restoring
all the operation parameters (not only icon and window title) is
implemented in xterm and screen, and is added to the terminfo database, and
ncurses would automatically use it to save on initscr() and restore on
endwin(), that would work nicely.

> (I agree -- there's no way to solve the problem using ncurses)

I admit I'm completely arrogant when it comes to terminals but what is the
reasoning of using "keypad mode" ever on those that lack not only keypad
but even a keyboard altogether? I've tried commenting out smkx and rmkx in
screen definition along with changing k* variables to match linux-basic
and so far couldn't notice any ill effects... Of course, that's not
anywhere near real solution, but I assume if this can work for the majority
of the users (and I bet the most terminals out there are not real terminals
anymore) that's probably good enough?

Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!

Attachment: signature.asc
Description: Digital signature

reply via email to

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