GNU bug report logs - #24229
25.1; Can't set EPA program

Previous Next

Package: emacs;

Reported by: Nick Helm <nick <at> tenpoint.co.nz>

Date: Mon, 15 Aug 2016 06:33:02 UTC

Severity: minor

Merged with 24268

Found in version 25.1

Done: Daiki Ueno <ueno <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #33 received at 24229 <at> debbugs.gnu.org (full text, mbox):

From: Nick Helm <nick <at> tenpoint.co.nz>
To: "24229 <at> debbugs.gnu.org" <24229 <at> debbugs.gnu.org>
Subject: Re: bug#24229: 25.1; Can't set EPA program
Date: Thu, 18 Aug 2016 01:32:42 +0000
> On 17/08/2016, at 7:46 PM, Daiki Ueno <ueno <at> gnu.org> wrote:
> 
> Nick Helm <nick <at> tenpoint.co.nz> writes:
> 
>> None of these variables forces the use of customize. Why 
>> is epg-gpg-program such a special case?
> 
> That is primarily because of the UX differences between three maintained
> versions of GnuPG: 2.0, 2.1, and 1.x.  GnuPG 2.0 does not provide a way
> to prompt passphrase without GUI, but others do.  Some people are fine
> with 2.0 as they use Emacs on a graphical environment only, but other
> people are not.
> 
> So, we really need to take account of user's intention here; check
> whether the variable set by user or it is the default value.  With
> 'setq' it is not possible to have such distinction.

I'm not sure I follow. If the user sets a variable, I think 
they're making their intention pretty clear – use the set 
value. 

If they know enough to set epg-gpg-program (using whatever 
mechanism), I'd argue they know enough to understand the 
capabilities of the program they're pointing to. Isn't it 
up to the user to know that gnupg 2.0 only supports 
GUI-based pinentry? 

But if the existing arrangement is important, can we at
least extend the test to determine if the variable has 
been set using either mechanism? Something like this might
work:

(not (equal (eval (car (get 'epg-gpg-program 'standard-value))) 
            (default-value 'epg-gpg-program)))

This returns true when the user sets the variable with 
setq or with customize (both current and future sessions). 
It doesn't detect the case where the user setqs one of the 
two possible standard-values ("gpg2" or "gpg") and the 
same (or both) executable(s) exists in the path, but that 
is the same as the default case anyway and is not a change 
from current behaviour.

Nick



This bug report was last modified 8 years and 134 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.