Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[Katsumi Yamaoka]

Hi,

On Sun, 11 Oct 2015 21:03:07 +0000, Nicolas Petton wrote:
>     * lisp/gnus/auth-source.el (auth-source-epa-make-gpg-token): Replace an
>       usage of `epg-context-set-armor' with `setf'.
[...]
> -    (epg-context-set-armor context t)
> +    (setf (epg-context-armor context) t)

This doesn't seem to be expanded properly when building Emacs:

In end of data:
gnus/auth-source.el:2145:1:Warning: the function `(setf epg-context-armor)' is
    not known to be defined.

How do we fix it?  Similarly old Emacsen fail on compiling this
because of an error (I merged the change to the Gnus git master):

(Emacs 23.2)
In toplevel form:
auth-source.el:1161:47:Error: No setf-method known for epg-context-armor

(XEmacs 21.5)
While compiling auth-source-epa-make-gpg-token in file auth-source.el:
  !! error (("No setf-method known for epg-context-armor"))

Whatever is done in Emacs master, the change might have to be
reverted in only Gnus master separately from Emacs master, I
think.

Thanks.

bug#21724: 25.0.50; (void-function (setf epg-context-armor))

[Katsumi Yamaoka]

References: <http://thread.gmane.org/gmane.emacs.diffs/132036>

On Tue, 13 Oct 2015 09:36:28 +0900, Katsumi Yamaoka wrote:
> On Sun, 11 Oct 2015 21:03:07 +0000, Nicolas Petton wrote:
>>     * lisp/gnus/auth-source.el (auth-source-epa-make-gpg-token): Replace an
>>       usage of `epg-context-set-armor' with `setf'.
> [...]
>> -    (epg-context-set-armor context t)
>> +    (setf (epg-context-armor context) t)

> This doesn't seem to be expanded properly when building Emacs:

> In end of data:
> gnus/auth-source.el:2145:1:Warning: the function `(setf epg-context-armor)' is
>     not known to be defined.

> How do we fix it?

I got:

Debugger entered--Lisp error: (void-function \(setf\ epg-context-armor\))

Recipe:

$ emacs -Q
load: lisp/gnus/auth-source.elc
eval: (auth-source-epa-make-gpg-token "foo" "bar")

To fix it, epg.el(c) is required when compiling auth-source.el,
I think.  Though once I merged the change to the Gnus git master,
I reverted it thereafter, since old Emacsen that Gnus supports do
not have the setf-method for epg-context-armor.

Regards,

bug#21724: 25.0.50; (void-function (setf epg-context-armor))

[Katsumi Yamaoka]

On Wed, 21 Oct 2015 18:03:38 +0900, Katsumi Yamaoka wrote:
> References: <http://thread.gmane.org/gmane.emacs.diffs/132036>

>>> -    (epg-context-set-armor context t)
>>> +    (setf (epg-context-armor context) t)

> Debugger entered--Lisp error: (void-function \(setf\ epg-context-armor\))

> To fix it, epg.el(c) is required when compiling auth-source.el,
> I think.

First I tried adding: (eval-when-compile (require 'epg))
It fixed the setf compilation problem.  However, the byte compiler
got to issue a new warning as follows:

In end of data:
auth-source.el:2145:1:Warning: the following functions might not be defined at
    runtime: epg-context-set-passphrase-callback, epg-decrypt-string,
    epg-encrypt-string

So, I'm not quite sure why it helps, but I wrapped the existing
autoload settings for those functions with `eval-and-compile':

<http://article.gmane.org/gmane.emacs.diffs/132162>

bug#21724: 25.0.50; (void-function (setf epg-context-armor))

[Glenn Morris]

Katsumi Yamaoka wrote:

> So, I'm not quite sure why it helps, but I wrapped the existing
> autoload settings for those functions with `eval-and-compile':

IMO it is better to move the epg autoloads after the epg eval-when-compile.

bug#21724: 25.0.50; (void-function (setf epg-context-armor))

[Katsumi Yamaoka]

On Thu, 22 Oct 2015 20:27:16 -0400, Glenn Morris wrote:
> Katsumi Yamaoka wrote:
>> So, I'm not quite sure why it helps, but I wrapped the existing
>> autoload settings for those functions with `eval-and-compile':

> IMO it is better to move the epg autoloads after the epg eval-when-compile.

Thanks.  I see why adding (eval-when-compile (require 'epg))
caused a new warning.  It marked all the epg functions including
those autoloads maybe non-existent at the run-time, didn't it?
Committed.

bug#21724: 25.0.50; (void-function (setf epg-context-armor))

[Glenn Morris]

Katsumi Yamaoka wrote:

> Thanks.  I see why adding (eval-when-compile (require 'epg))
> caused a new warning.  It marked all the epg functions including
> those autoloads maybe non-existent at the run-time, didn't it?

Yes. I didn't investigate, but it's probably a compiler bug.
It doesn't properly track autoloaded-but-not-actually-defun'd definitions
before eval-when-compile, so whatever statement comes last wins.

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[Ted Zlatanov]

On Tue, 13 Oct 2015 09:36:28 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> How do we fix it?  Similarly old Emacsen fail on compiling this
KY> because of an error (I merged the change to the Gnus git master):

KY> (Emacs 23.2)
KY> In toplevel form:
KY> auth-source.el:1161:47:Error: No setf-method known for epg-context-armor

KY> (XEmacs 21.5)
KY> While compiling auth-source-epa-make-gpg-token in file auth-source.el:
KY>   !! error (("No setf-method known for epg-context-armor"))

KY> Whatever is done in Emacs master, the change might have to be
KY> reverted in only Gnus master separately from Emacs master, I
KY> think.

Maybe drop Gnus support for Emacs 23.x and old XEmacs too?

I think we've had too many of these annoyances over the years.

Ted

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[Katsumi Yamaoka]

On Thu, 05 Nov 2015 15:03:59 -0500, Ted Zlatanov wrote:
> Maybe drop Gnus support for Emacs 23.x and old XEmacs too?
> I think we've had too many of these annoyances over the years.

Although the problem isn't due to those Emacsen's oldness as for
particularly this thread, making Gnus drop old Emacsen is a good
idea.  Probably dropping Emacs 23 won't trouble many users.  But
what is old XEmacs to be?  In some sense, all XEmacsen is old. ;-)

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[David Kastrup]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> On Thu, 05 Nov 2015 15:03:59 -0500, Ted Zlatanov wrote:
>> Maybe drop Gnus support for Emacs 23.x and old XEmacs too?

The most current stable XEmacs version is 21.4.22 (released 2009),
roughly corresponding to Emacs 21.1 if I remember correctly.  So there
is not much of a point in thinking about Emacs 23.x as long as XEmacs is
in the equation.

>> I think we've had too many of these annoyances over the years.
>
> Although the problem isn't due to those Emacsen's oldness as for
> particularly this thread, making Gnus drop old Emacsen is a good
> idea.  Probably dropping Emacs 23 won't trouble many users.  But
> what is old XEmacs to be?  In some sense, all XEmacsen is old. ;-)

Every XEmacs developer will tell you that you are crazy to use
XEmacs 21.4, but since it is the official stable version, it is what
will be packaged by default with standard distributions.

I am not in a position to prescribe to Gnus developers how they are
maintaining their software.  Maybe Gnus stopping to support XEmacs 21.4
is the kick in the behind that XEmacs needs for preparing a new "stable"
release rather than face the prospect of having to backport or freeze
Gnus.  But I don't know how receptive to kicks that behind might be
right now.  For most active users, XEmacs 21.4 does not appear to be
more than a practical joke.

-- 
David Kastrup

dropping support for old Emacsen (was: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el)

[Ted Zlatanov]

On Fri, 06 Nov 2015 11:22:22 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> On Thu, 05 Nov 2015 15:03:59 -0500, Ted Zlatanov wrote:
>> Maybe drop Gnus support for Emacs 23.x and old XEmacs too?
>> I think we've had too many of these annoyances over the years.

KY> making Gnus drop old Emacsen is a good idea. Probably dropping Emacs
KY> 23 won't trouble many users. But what is old XEmacs to be? In some
KY> sense, all XEmacsen is old. ;-)

I should note I've brought this up before. Crossposting to the Gnus
mailing list as well. Concretely, the proposal is to support only Emacs
24.x in Gnus. If XEmacs or Emacs 23 support breaks, then users can
submit patches but it won't be a primary focus for the developers.

On Fri, 06 Nov 2015 10:41:16 +0100 David Kastrup <dak@gnu.org> wrote: 

DK> I am not in a position to prescribe to Gnus developers how they are
DK> maintaining their software.  Maybe Gnus stopping to support XEmacs 21.4
DK> is the kick in the behind that XEmacs needs for preparing a new "stable"
DK> release rather than face the prospect of having to backport or freeze
DK> Gnus.  But I don't know how receptive to kicks that behind might be
DK> right now.  For most active users, XEmacs 21.4 does not appear to be
DK> more than a practical joke.

Agreed.  Emacs 23.1 is from 2009 so it's similarly outdated though not
as humorous.

Ted

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I don't think we should consider Emacs 23 "old" yet.  I would guess
that many users still use it.  Indeed, one of the machines I use has
Emacs 21.4 installed.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I don't think we should consider Emacs 23 "old" yet.  I would guess
> that many users still use it.  Indeed, one of the machines I use has
> Emacs 21.4 installed.

But it is unlikely that you are going to update it with a current
version of Gnus.

-- 
David Kastrup

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I don't think we should consider Emacs 23 "old" yet.  I would guess
  > > that many users still use it.  Indeed, one of the machines I use has
  > > Emacs 21.4 installed.

  > But it is unlikely that you are going to update it with a current
  > version of Gnus.

I won't, but some people using a system they don't maintain, with an
old Emacs installed, might want to run a newer Gnus.


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: master 644d31a 2/2: Replace the usage of an obsolete function in auth-source.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > I don't think we should consider Emacs 23 "old" yet.  I would
>   > > guess that many users still use it.  Indeed, one of the machines
>   > > I use has Emacs 21.4 installed.
>
>   > But it is unlikely that you are going to update it with a current
>   > version of Gnus.
>
> I won't, but some people using a system they don't maintain, with an
> old Emacs installed, might want to run a newer Gnus.

New programming features are developed because they make developers'
life easier and the code base more maintainable, lowering the barrier of
entry for new blood.

So for systems like Gnus, I would prefer to leave the decision of which
compatibility to pursue to the active maintainers of Gnus (or whatever
subsystem we are talking about).  They likely know best how many of
their users and how many of their developers complain about which kind
of thing.

-- 
David Kastrup

Re: dropping support for old Emacsen

[Uwe Brauer]

>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

   > On Fri, 06 Nov 2015 11:22:22 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 
   KY> On Thu, 05 Nov 2015 15:03:59 -0500, Ted Zlatanov wrote:
   >>> Maybe drop Gnus support for Emacs 23.x and old XEmacs too?
   >>> I think we've had too many of these annoyances over the years.

   KY> making Gnus drop old Emacsen is a good idea. Probably dropping Emacs
   KY> 23 won't trouble many users. But what is old XEmacs to be? In some
   KY> sense, all XEmacsen is old. ;-)

I think 21.5.34 should be at least considered not dead...

   > I should note I've brought this up before. Crossposting to the Gnus
   > mailing list as well. Concretely, the proposal is to support only Emacs
   > 24.x in Gnus. If XEmacs or Emacs 23 support breaks, then users can
   > submit patches but it won't be a primary focus for the developers.

   > On Fri, 06 Nov 2015 10:41:16 +0100 David Kastrup <dak@gnu.org> wrote: 

   DK> I am not in a position to prescribe to Gnus developers how they
   DK> are maintaining their software. Maybe Gnus stopping to support
   DK> XEmacs 21.4 is the kick in the behind that XEmacs needs for
   DK> preparing a new "stable" release rather than face the prospect of
   DK> having to backport or freeze Gnus. But I don't know how receptive
   DK> to kicks that behind might be right now. For most active users,
   DK> XEmacs 21.4 does not appear to be more than a practical joke.

Sadly enough most debian based distribution still ship it instead of 
21.5.34 which is more decent.