From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Fix needed for communication with gpg-agent Date: Tue, 20 Feb 2007 16:11:40 +0100 Message-ID: References: <87irdzs6pp.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1171984333 16672 80.91.229.12 (20 Feb 2007 15:12:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Feb 2007 15:12:13 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 20 16:11:57 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HJWep-0002w4-Rh for ged-emacs-devel@m.gmane.org; Tue, 20 Feb 2007 16:11:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HJWep-0007Tq-Ba for ged-emacs-devel@m.gmane.org; Tue, 20 Feb 2007 10:11:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HJWeE-0007Co-5w for emacs-devel@gnu.org; Tue, 20 Feb 2007 10:11:18 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HJWeB-0007BY-50 for emacs-devel@gnu.org; Tue, 20 Feb 2007 10:11:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HJWeB-0007BS-15 for emacs-devel@gnu.org; Tue, 20 Feb 2007 10:11:15 -0500 Original-Received: from pfepb.post.tele.dk ([195.41.46.236]) by monty-python.gnu.org with esmtp (Exim 4.52) id 1HJWe8-0004aC-JC; Tue, 20 Feb 2007 10:11:12 -0500 Original-Received: from kfs-l.imdomain.dk.cua.dk (unknown [80.165.4.124]) by pfepb.post.tele.dk (Postfix) with SMTP id 09A63A5004B; Tue, 20 Feb 2007 16:10:54 +0100 (CET) In-Reply-To: <87irdzs6pp.fsf@stupidchicken.com> (Chong Yidong's message of "Sun\, 18 Feb 2007 12\:42\:26 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:66554 Archived-At: Chong Yidong writes: > Richard Stallman writes: > >> Would someone please implement this code, needed for correct >> redisplay after running pinentry? Then please ack. >> >> ... >> >> Without X, Pinentry falls back to a curses implementation (there is >> also a curses only version of Pinentry). This works pretty reliable >> but poses one problem: The screen needs a redraw as there is no >> portable way to save and restore the old screen content. What can be >> done is to redraw the screen every time after calling a crypto >> operation which uses gpg or gpgsm. This is of course not optimal as >> in most cases the passphrase has been cached and an expensive redraw >> is not required. > > I don't see any reasonable way to do this. So why does Werner say that "this works pretty reliable" ...? > > Roughly speaking, when Emacs is run in a console (i.e. as a curses > program), it monopolizes terminal input and output. I don't know of > any way to call the curses version of pinentry, have it temporarily > "take over" the terminal, and return control to Emacs once it's done. Well, if Emacs just "sleeps" while it waits for gpg to finish, then we can assume that pinentry has finished using the screen as well. accept-process-output has a just-this-one argument which causes emacs to wait without reading the keyboard (it will still run timers though). Maybe we use that to wait for gpg + pinentry already? I guess Emacs cannot really continue without getting the result from gpg. .. and if we waited for more than a few seconds for gpg to complete, we can (safely) assume that the user was involved, and redraw the screen. (so no need to implement the "protocol".) Of course, we only need to do any of this if "no X". -- Kim F. Storm http://www.cua.dk