[Top][All Lists]

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

Re: epg.el: epg--status-GET_LINE not working?

From: Neal H. Walfield
Subject: Re: epg.el: epg--status-GET_LINE not working?
Date: Thu, 06 Jul 2017 21:29:30 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Mon, 26 Jun 2017 09:58:43 +0300,
Teemu Likonen wrote:
> I have been thinking of fixing epg.el bug #24350
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24350>.
> The problem is that in tofu conflicts epg interprets GnuPG's "GET_LINE
> tofu.conflict" and waits for user input on minibuffer. The user
> interaction is implemented in epg--status-GET_LINE function. But as far
> as I can see it can't work. I'll try explain the problem.

I use Wanderlust for mail and epg-* functions directly and in both
cases, when there is a tofu conflict, I get a prompt in the
mini-buffer along the lines of "tofu.conflict?" and I'm able to
specify a resolution.  So, it does work in the sense that the user is
prompted and can respond to a promt---at least in my situation.  I'm
told this is also the case with notmuch.

What needs improvement is that when epg sees a tofu.conflict prompt,
it should describe the conflict so that the user is able to resolve it
intelligently instead of having to known what is going on, as is
currently the case.  Some details are described here:


> Gpg is called with a command-line like this:
>     GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1 /usr/bin/gpg
>     --no-tty --status-fd 1 --yes --use-agent --command-fd 0 --output
>     /tmp/epg-output983w_C --verify -- /tmp/epg-signature9839JJ -
> Note that "--command-fd 0" expects interactive commands from the file
> descriptor 0 (standard input). Such commands are handled by
> epg--status-GET_LINE function which is triggered when "--status-fd 1"
> output contains GET_LINE command. But also note the "-" at the end of
> the command line. It means that the message contents is also being
> received from the file descriptor 0 (standard input). Getting both the
> message's contents and --command-fd's GET_LINE input from stardard input
> stream doesn't work, or so it seems in my tests.

If you type in 'a' at the minibuffer prompt (for accept once), does
epg continue?  It does for me.

reply via email to

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