pop3.el itegration with netrc.el

pop3.el itegration with netrc.el

[Ted Zlatanov]

pop3.el seems to be separate from the rest of Gnus, so I'm not sure if
I should add netrc.el (authinfo) support to it - then pop3.el would
also depend on gnus-encrypt.el.  Please advise.

Thanks
Ted

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

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

> pop3.el seems to be separate from the rest of Gnus, so I'm not sure if
> I should add netrc.el (authinfo) support to it - then pop3.el would
> also depend on gnus-encrypt.el.  Please advise.

There are many incompatible forks of pop3.el, the copy in Gnus CVS
used to be one of them.  I see now that the copies in Gnus CVS and
Emacs CVS are in sync.  I'm not sure how that happened, but it is a
good thing.  So perhaps we can make this one the canonical copy, and
add new features to it.  I'd say go ahead.

Btw, is it difficult to modularize gnus-encrypt.el into, say,
encrypt.el, that doesn't use a lot of Gnus functions?  I recall some
discussions about that, though.

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

On Thu, 14 Oct 2004, jas@extundo.com wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
> 
>> pop3.el seems to be separate from the rest of Gnus, so I'm not sure if
>> I should add netrc.el (authinfo) support to it - then pop3.el would
>> also depend on gnus-encrypt.el.  Please advise.
> 
> There are many incompatible forks of pop3.el, the copy in Gnus CVS
> used to be one of them.  I see now that the copies in Gnus CVS and
> Emacs CVS are in sync.  I'm not sure how that happened, but it is a
> good thing.  So perhaps we can make this one the canonical copy, and
> add new features to it.  I'd say go ahead.

I've cc-ed the emacs-devel list in case anyone there has suggestions.
This is regarding pop3.el and its use of netrc (~/.authinfo) files.

> Btw, is it difficult to modularize gnus-encrypt.el into, say,
> encrypt.el, that doesn't use a lot of Gnus functions?  I recall some
> discussions about that, though.

This may be a good time to make that break.  The current
gnus-encrypt.el can be turned into encrypt.el with very few changes
except for the dependency on password.el, which is in Gnus.
gnus-encrypt.el will remain as a wrapper for Gnus, using password.el
and allowing closer integration with other Gnus libraries.  This is
not the real problem, though.

The root problem is that netrc.el is a part of Gnus I can't break out
(I think), so the Gnus version of pop3.el will have a dependency we
don't want.  Maybe we should have gnus-pop3.el to implement what I'm
proposing, so pop3.el remains clean of Gnus dependencies?

Ted

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

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

>> Btw, is it difficult to modularize gnus-encrypt.el into, say,
>> encrypt.el, that doesn't use a lot of Gnus functions?  I recall some
>> discussions about that, though.
>
> This may be a good time to make that break.  The current
> gnus-encrypt.el can be turned into encrypt.el with very few changes
> except for the dependency on password.el, which is in Gnus.

We can install password.el in Emacs.

> The root problem is that netrc.el is a part of Gnus I can't break out
> (I think)

Why not?  Doing so seem like a good idea, to me.  netrc.el doesn't
call any Gnus functions, except for gnus-encrypt, as far as I can
tell.  And if we (you) move gnus-encrypt.el to encrypt.el, all will be
fine, I think.

> so the Gnus version of pop3.el will have a dependency we don't want.

pop3.el would depend on netrc.el, which would depend on encrypt.el,
which would depend on password.el.  All small files, and no Gnus
dependencies.

Re: pop3.el itegration with netrc.el

[Reiner Steib]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

On Thu, Oct 14 2004, Simon Josefsson wrote:

> "Ted Zlatanov" <tzz@lifelogs.com> writes:
>
>> pop3.el seems to be separate from the rest of Gnus, so I'm not sure if
>> I should add netrc.el (authinfo) support to it - then pop3.el would
>> also depend on gnus-encrypt.el.  Please advise.
>
> There are many incompatible forks of pop3.el, the copy in Gnus CVS
> used to be one of them.  I see now that the copies in Gnus CVS and
> Emacs CVS are in sync.  I'm not sure how that happened, but it is a
> good thing.

I've merged the changes from Emacs to Gnus initially and Miles keeps
them in sync now.  The most important thing was
`pop3-leave-mail-on-server'.  I'm not sure if this feature (introduced
in Emacs) was a good idea in the first place (and I don't know if it
works reliably [1]).  But if upgrading from Gnus 5.9 to 5.11 would
suddenly delete the mails on the server after pop (when
`pop3-leave-mail-on-server' is ignored as in Gnus 5.10.6), people
won't be happy ("Gnus deleted all my mail!!!1").

> So perhaps we can make this one the canonical copy, and add new
> features to it.  I'd say go ahead.

Dave Love pointed out that `pop3.el' could be used outside Gnus and
suggested to remove the nn-whatever dependencies.  If we think that
this is a valuable goal, we should avoid adding further dependencies.

,----[ http://thread.gmane.org/gmane.emacs.pretest.bugs/3974 ]
| pop3.el shouldn't use nnheader-accept-process-output, so it can be
| used outside Gnus.
`----

Bye, Reiner.

[1] I think I'll add a warning, see the attached patch.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: rs-pop-leave.patch --]
[-- Type: text/x-patch, Size: 2058 bytes --]

Index: lisp/pop3.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pop3.el,v
retrieving revision 6.23.2.2
diff -u -r6.23.2.2 pop3.el
--- lisp/pop3.el	22 Aug 2004 21:48:11 -0000	6.23.2.2
+++ lisp/pop3.el	30 Aug 2004 16:43:52 -0000
@@ -55,7 +55,14 @@
 values are 'apop.")
 
 (defvar pop3-leave-mail-on-server nil
-  "*Non-nil if the mail is to be left on the POP server after fetching.")
+  "*Non-nil if the mail is to be left on the POP server after fetching.
+
+If the `pop3-leave-mail-on-server' is non-`nil' the mail is to be
+left on the POP server after fetching.  Note that POP servers
+maintain no state information between sessions, so what the
+client believes is there and what is actually there may not match
+up.  If they do not, then the whole thing can fall apart and
+leave you with a corrupt mailbox.")
 
 (defvar pop3-timestamp nil
   "Timestamp returned when initially connected to the POP server.
Index: texi/gnus.texi
===================================================================
RCS file: /usr/local/cvsroot/gnus/texi/gnus.texi,v
retrieving revision 6.603.2.4
diff -u -r6.603.2.4 gnus.texi
--- texi/gnus.texi	26 Aug 2004 09:59:57 -0000	6.603.2.4
+++ texi/gnus.texi	30 Aug 2004 16:43:53 -0000
@@ -13528,10 +13528,16 @@
 
 @end table
 
+@vindex pop3-movemail
+@vindex pop3-leave-mail-on-server
 If the @code{:program} and @code{:function} keywords aren't specified,
 @code{pop3-movemail} will be used.  If the
 @code{pop3-leave-mail-on-server} is non-@code{nil} the mail is to be
-left on the POP server after fetching.
+left on the @acronym{POP} server after fetching when using
+@code{pop3-movemail}.  Note that POP servers maintain no state
+information between sessions, so what the client believes is there and
+what is actually there may not match up.  If they do not, then the whole
+thing can fall apart and leave you with a corrupt mailbox.
 
 Here are some examples.  Fetch from the default @acronym{POP} server,
 using the default user name, and default fetcher:

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> So perhaps we can make this one the canonical copy, and add new
>> features to it.  I'd say go ahead.
>
> Dave Love pointed out that `pop3.el' could be used outside Gnus and
> suggested to remove the nn-whatever dependencies.  If we think that
> this is a valuable goal, we should avoid adding further dependencies.
>
> ,----[ http://thread.gmane.org/gmane.emacs.pretest.bugs/3974 ]
> | pop3.el shouldn't use nnheader-accept-process-output, so it can be
> | used outside Gnus.
> `----

I agree, but I wouldn't consider netrc.el, password.el nor encrypt.el
as something part of Gnus, even though they technically are.  They are
(or will be) small standalone libraries.

But the nn* dependency is bad, using nn* will lead to loading parts of
Gnus.  Can't we write a pop3-accept-process-output, and drop the
nnheader dependency?  Seems simple.

Re: pop3.el itegration with netrc.el

[Reiner Steib]

On Thu, Oct 14 2004, Simon Josefsson wrote:

> I agree, but I wouldn't consider netrc.el, password.el nor encrypt.el
> as something part of Gnus, even though they technically are.  They are
> (or will be) small standalone libraries.

Ah, sorry.  I didn't know that `[gnus-]encrypt.el' (Ted wrote "pop3.el
would also depend on gnus-encrypt.el") has no real Gnus dependencies.

> But the nn* dependency is bad, using nn* will lead to loading parts of
> Gnus.  Can't we write a pop3-accept-process-output, and drop the
> nnheader dependency?  Seems simple.

I didn't look at it in detail.  We'd probably have to duplicate
`nnheader-accept-process-output' and the strange
`nnheader-read-timeout' thingie.  I would be glad if you could fix
this.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> But the nn* dependency is bad, using nn* will lead to loading parts of
>> Gnus.  Can't we write a pop3-accept-process-output, and drop the
>> nnheader dependency?  Seems simple.
>
> I didn't look at it in detail.  We'd probably have to duplicate
> `nnheader-accept-process-output' and the strange
> `nnheader-read-timeout' thingie.  I would be glad if you could fix
> this.

Done.  I hope it will be merged automatically to Emacs CVS (that
gateway is quite neat, btw!).

Perhaps emacs/lisp/gnus/pop3.el should be moved to emacs/lisp/net/?
People seem to be afraid of using files from gnus/.  And now pop3.el
is standalone.  What do you think?

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

I'm attaching the new encrypt.el (mostly gnus-encrypt.el minus cruft
and with a search&replace done) and the related netrc.el (just
search&replace of gnus-encrypt with encrypt).

Let me know if it looks OK before I put it into Gnus.  gnus-encrypt.el
will become a shallow wrapper with no options for now if this
conversion happens.

If password.el, netrc.el, encrypt.el, and pop3.el move to Emacs,
that's OK but I don't have CVS access to Emacs source code so it will
be harder for me to maintain those files.

Ted


[-- Attachment #2: netrc.el --]
[-- Type: application/emacs-lisp, Size: 6523 bytes --]

[-- Attachment #3: encrypt.el --]
[-- Type: application/emacs-lisp, Size: 9201 bytes --]

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

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

> I'm attaching the new encrypt.el (mostly gnus-encrypt.el minus cruft
> and with a search&replace done) and the related netrc.el (just
> search&replace of gnus-encrypt with encrypt).
>
> Let me know if it looks OK before I put it into Gnus.

Looks fine (untested though).

Perhaps there should be some autoload cookies in encrypt.el, to avoid
the autoload declarations inside netrc.el.

> gnus-encrypt.el will become a shallow wrapper with no options for
> now if this conversion happens.

Would gnus-encrypt.el still be useful?

> If password.el, netrc.el, encrypt.el, and pop3.el move to Emacs,
> that's OK but I don't have CVS access to Emacs source code so it will
> be harder for me to maintain those files.

I'd say we can maintain them in Gnus CVS, and sync the version in
Emacs from time to time.

When you have installed the files in Gnus HEAD, I'll write a proposal
to install them in Emacs CVS on emacs-devel, and install them if
nobody object.  Since it is new functionality, I'm assuming they
shouldn't go into Gnus 5.10.  Hopefully by moving the files away from
emacs/lisp/gnus/ the auto-sync gateway won't merge the files back into
Gnus 5.10.

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

On Fri, 15 Oct 2004, jas@extundo.com wrote:

> Perhaps there should be some autoload cookies in encrypt.el, to
> avoid the autoload declarations inside netrc.el.

Done, I think (I didn't remove the autoload declarations in netrc.el
yet though).

All the changes are in CVS now.

> Would gnus-encrypt.el still be useful?

I don't think so, so I've mentally marked it for tentative removal.
If no complaints arise I'll remove it next week.

> I'd say we can maintain them in Gnus CVS, and sync the version in
> Emacs from time to time.
> 
> When you have installed the files in Gnus HEAD, I'll write a proposal
> to install them in Emacs CVS on emacs-devel, and install them if
> nobody object.  Since it is new functionality, I'm assuming they
> shouldn't go into Gnus 5.10.  Hopefully by moving the files away from
> emacs/lisp/gnus/ the auto-sync gateway won't merge the files back into
> Gnus 5.10.

I have a feeling a lot of people will have something to say about
encrypt.el - it's a touchy topic for a lot of developers, and it's
hard to do it right.

Ted

Re: pop3.el itegration with netrc.el

[Reiner Steib]

On Fri, Oct 15 2004, Simon Josefsson wrote:

> I'd say we can maintain them in Gnus CVS, and sync the version in
> Emacs from time to time.
>
> When you have installed the files in Gnus HEAD, I'll write a
> proposal to install them in Emacs CVS on emacs-devel, and install
> them if nobody object.  Since it is new functionality, I'm assuming
> they shouldn't go into Gnus 5.10.

[ I haven't looked at Ted's encryption code; please disregard my remarks
if irrelevant. ]

We intended to keep "Gnus in Emacs trunk" and Gnus 5.10.x (v5-10
branch) in sync in order to avoid merging problems in the future.

If it is new functionality that will most probably not make the
current Gnus instable, Lars may agree to add it in v5-10.  The storing
of plain-text passwords in ~/.authinfo may even qualify as a bug that
needs to be fixed in the stable series.

> Hopefully by moving the files away from emacs/lisp/gnus/ the
> auto-sync gateway won't merge the files back into Gnus 5.10.

It would surely require some additional work for Miles.  It's not a
fully automated process, AFAIK.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: pop3.el itegration with netrc.el

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> Hopefully by moving the files away from emacs/lisp/gnus/ the
>> auto-sync gateway won't merge the files back into Gnus 5.10.
>
> It would surely require some additional work for Miles.  It's not a
> fully automated process, AFAIK.

The sync process ignores file location, it uses the arch "id-tags" you
can see at the bottom of each source file.  So if you move a file in one
tree, I'll have to intervene to make sure that it does/doesn't move in
the other tree (whichever is appropriate), but subsequent changes to the
moved file will still propagate.

If you want the association between files to be completely broken (I
don't think you usually do), then you can remove the arch-tag: line at
the bottom of one copy (it will get a new one automatically).  It's
_not_ desirable in general to do this; if a particular file needs
special care with regard to propagating changes, just tell me, and I'll
watch out for anything funny.

The main problem is ChangeLogs:  if you add entries to lisp/ChangeLog
(in Gnus) or lisp/gnus/ChangeLog (in Emacs), it's clear that they should
simply be propagated to the corresponding file in the other tree,
because the changes they describe almost certainly will be as well.

However, if files from Gnus are present in other Emacs directories, then
this easy 1-to-1 correspondence is lost, so it will likely require me to
manually deal with such ChangeLog entries.  This problem already exists
with texi/ChangeLog, but it's not that heavily updated, so it hasn't
proved much of burden; hopefully the bulk of Gnus changes will still
remain inside the main gnus source even if these "generic" files are
moved.

But anyway, dealing with ChangeLogs is a relatively minor hassle becuase
it's only 1 or 2 files, and if it gets too annoying I'll write a script
that deals with it.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

On Mon, 18 Oct 2004, miles@gnu.org wrote:

> The main problem is ChangeLogs: if you add entries to lisp/ChangeLog
> (in Gnus) or lisp/gnus/ChangeLog (in Emacs), it's clear that they should
> simply be propagated to the corresponding file in the other tree,
> because the changes they describe almost certainly will be as well.
> 
> However, if files from Gnus are present in other Emacs directories, then
> this easy 1-to-1 correspondence is lost, so it will likely require me to
> manually deal with such ChangeLog entries.  This problem already exists
> with texi/ChangeLog, but it's not that heavily updated, so it hasn't
> proved much of burden; hopefully the bulk of Gnus changes will still
> remain inside the main gnus source even if these "generic" files are
> moved.
> 
> But anyway, dealing with ChangeLogs is a relatively minor hassle becuase
> it's only 1 or 2 files, and if it gets too annoying I'll write a script
> that deals with it.

If you could make the default add-change-log-entry-other-window to
mention the arch-tag (if available at the end of the file), I think
your life and ours will be much easier.  This would require changes to
add-log.el though.

I love the idea of a general identifier for all files in the VCS.
That makes the CVS annoyance of directory mis-management much easier
to reconcile with TLA.  Thanks for helping with all the Gnus <-> Emacs
sync issues.

Ted

Re: pop3.el itegration with netrc.el

[Ted Zlatanov]

On 18 Oct 2004, tzz@lifelogs.com wrote:

> If you could make the default add-change-log-entry-other-window to
> mention the arch-tag (if available at the end of the file), I think
> your life and ours will be much easier.  This would require changes to
> add-log.el though.

Would you like me to try this or is it better raised on emacs-devel?

It seems like a very useful feature, if the arch-tags are generally
used for Emacs development.

Ted

Re: pop3.el itegration with netrc.el

[Reiner Steib]

On Fri, Oct 15 2004, Ted Zlatanov wrote:

> If password.el, netrc.el, encrypt.el, and pop3.el move to Emacs,
> that's OK but I don't have CVS access to Emacs source code so it will
> be harder for me to maintain those files.

netrc.el has already been "moved to Emacs" a long time ago.  This
doesn't mean that you cannot maintain the files anymore.  Changes in
v5-10/lisp/netrc.el should still be merged into Emacs (follow the URL
for more):

,----[ http://thread.gmane.org/20041010225828.GA31829@fencepost ]
| From: Miles Bader <miles@lsi.nec.co.jp>
| Subject: Re: [rmail-mbox-branch]: mail-utils
| Date: Tue, 12 Oct 2004 11:09:11 +0900
| Message-ID: <buoy8ick7qw.fsf@mctpc71.ucom.lsi.nec.co.jp>
| 
| Richard Stallman <rms@gnu.org> writes:
| >     Do you mean that a patch from a gnus maintainer would have to be
| >     posted to the mailing list to be put into emacs (unlike Gnus
| >     changes)?
| >
| > I mean they should treat these files the same way they treat all the
| > other Lisp files that are not part of Gnus.  That does not mean ALL
| > changes have to be discussed.  They can install local uncontroversial
| > bug fixes without discussion, just as any of us would.  However,
| > beyond that, they ought to post on this list.
| 
| Ok, that sounds reasonable, and workable in practice for my Gnus-syncing.
`----

password.el and encrypt.el (tla, ...) are new in No Gnus.  So these
files will not be considered now, I think.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

encrypt.el (was: pop3.el itegration with netrc.el)

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Fri, 15 Oct 2004, reinersteib+gmane@imap.cc wrote:

> password.el and encrypt.el (tla, ...) are new in No Gnus.  So these
> files will not be considered now, I think.

encrypt.el should be general-purpose enough that it can be outside
Gnus itself.  I would like it to be part of Emacs, not just Gnus,
because encryption is important to users and Emacs doesn't come with
much built-in for handling encryption.  I'm attaching a copy, the same
(as of now) as the one in the Gnus CVS HEAD.  Can anyone comment on
the likelihood of inclusion in Emacs?

The current list of encryption methods is minimal but can be easily
expanded.  The API is IMHO more important.

Thanks
Ted


[-- Attachment #2: encrypt.el --]
[-- Type: application/emacs-lisp, Size: 9233 bytes --]

Re: encrypt.el

[Reiner Steib]

On Wed, Dec 01 2004, Ted Zlatanov wrote:

> I need to clarify, however, how encrypt.el will coexist with the
> Gnus version.  Should I remove encrypt.el from Gnus, or leave it in
> as a duplicate of the Emacs tree version?

[I think you mean Gnus repository here, right?]

No Gnus is supposed to run on Emacs 21.1 (and up) and XEmacs 21.4 (and
up).  Wouldn't removing encrypt.el break running Gnus on versions
before Emacs 21.4?

Bye, Reiner.

[ Cc-ing Ding, trimming xemacs-beta ]
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Ted Zlatanov]

On Wed, 01 Dec 2004, reinersteib+gmane@imap.cc wrote:

On Wed, Dec 01 2004, Ted Zlatanov wrote:
> 
>> I need to clarify, however, how encrypt.el will coexist with the
>> Gnus version.  Should I remove encrypt.el from Gnus, or leave it in
>> as a duplicate of the Emacs tree version?
> 
> [I think you mean Gnus repository here, right?]

Gnus CVS is synchronized with Emacs these days, so it would be both.

> No Gnus is supposed to run on Emacs 21.1 (and up) and XEmacs 21.4 (and
> up).  Wouldn't removing encrypt.el break running Gnus on versions
> before Emacs 21.4?

Yes, and I'll leave it in on yours and Simon Josefsson's advice.  So I
will only add encrypt.el to the Emacs lisp/ tree without removing it
from anywhere else.

I do wish that CVS supported symlinks :)

Ted

Re: encrypt.el

[Reiner Steib]

On Thu, Dec 02 2004, Ted Zlatanov wrote:

> On Wed, 01 Dec 2004, reinersteib+gmane@imap.cc wrote:
[...]
>> [I think you mean Gnus repository here, right?]
>
> Gnus CVS is synchronized with Emacs these days, so it would be both.

I think that Miles can do the syncing independent of the location, e.g.

  [v5-10]gnus/lisp/netrc.el <--> emacs/lisp/net/net/netrc.el

BTW, should `encrypt.el' go in the stable branch (v5-10), too?  Maybe
we already discussed this, but I forgot.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Ted Zlatanov]

I'll hold off on the encrypt.el migration until after the next Emacs
release, as requested.

Thanks for all the help
Ted

Re: pop3.el itegration with netrc.el

[Reiner Steib]

[ Resending this message.  The first one didn't make it to the list,
  it seems.  At least it's not on Gmane.  Sorry for any duplicates. ]

On Fri, Oct 15 2004, Simon Josefsson wrote:

> Done.

Thanks.

> I hope it will be merged automatically to Emacs CVS

When installed in v5-10 (i.e. if it is a bug fix), it should be
automatically synced to Gnus trunk and to Emacs.

> (that gateway is quite neat, btw!).

ACK.  Miles also syncs from Emacs to Gnus, but he said that Gnus ->
Emacs is easier for him.  I don't know if it is inconvenient for Miles
if we install a change in v5-10 and trunk at the same time.

Maybe we should have MAINTAINANCE file (or README.developer) in Gnus
CVS to explain these non-obvious things, WDYT?

Other items in this file could be:

- ./etc/gnus-news.texi -> make -> GNUS-NEWS

- Avoiding dependencies:

  - message / gnus

  - nn*

  - mm*

  - rfc*

  - tla netrc pop3 dig dns ...

- Compatibility with XEmacs and older Emacs versions in v5-10 and in
  the trunk.

> Perhaps emacs/lisp/gnus/pop3.el should be moved to emacs/lisp/net/?
> People seem to be afraid of using files from gnus/.  And now pop3.el
> is standalone.  What do you think?

I'd agree.  Also for some other files: dig.el dns.el ...  If I recall
the discussions on emacs-devel correctly, this implies that the file
would be officially maintained by the Emacs developers.  Thus Richard
has to decide about it.  Please suggest the moving on emacs-devel.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: pop3.el itegration with netrc.el

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> ACK.  Miles also syncs from Emacs to Gnus, but he said that Gnus ->
> Emacs is easier for him.  I don't know if it is inconvenient for Miles
> if we install a change in v5-10 and trunk at the same time.
>
> Maybe we should have MAINTAINANCE file (or README.developer) in Gnus
> CVS to explain these non-obvious things, WDYT?

Yes, please.  I know I will forget about them unless they are written
down somewhere.

> Other items in this file could be:

Neat.  Looks like a "Gnus Coding Style" file, which indeed would be
useful.

>> Perhaps emacs/lisp/gnus/pop3.el should be moved to emacs/lisp/net/?
>> People seem to be afraid of using files from gnus/.  And now pop3.el
>> is standalone.  What do you think?
>
> I'd agree.  Also for some other files: dig.el dns.el ...  If I recall
> the discussions on emacs-devel correctly, this implies that the file
> would be officially maintained by the Emacs developers.  Thus Richard
> has to decide about it.  Please suggest the moving on emacs-devel.

But the files are in emacs/lisp/gnus, so in theory that already means
they are maintained by the Emacs developers?

dns.el has a mm-util dependency, but dig.el should be moved to
emacs/lisp/net/.  Any other files?  Perhaps: starttls.el, sha1.el,
sieve*.el, format-spec.el.

Re: pop3.el itegration with netrc.el

[Reiner Steib]

On Fri, Oct 15 2004, Simon Josefsson wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
[...]
>>> Perhaps emacs/lisp/gnus/pop3.el should be moved to emacs/lisp/net/?
>>> People seem to be afraid of using files from gnus/.  And now pop3.el
>>> is standalone.  What do you think?
>>
>> I'd agree.  Also for some other files: dig.el dns.el ...  If I recall
>> the discussions on emacs-devel correctly, this implies that the file
>> would be officially maintained by the Emacs developers.  Thus Richard
>> has to decide about it.  Please suggest the moving on emacs-devel.
>
> But the files are in emacs/lisp/gnus, so in theory that already means
> they are maintained by the Emacs developers?

In _my_ understanding, Richard considers the files in emacs/lisp/gnus
(and the corresponding manuals) as "maintained by the Gnus
developers".  If a file is useful for other Emacs packages and doesn't
depend on Gnus he want it to be moved to a different directory.  (But
I might be misunderstanding him.)

> dns.el has a mm-util dependency, but dig.el should be moved to
> emacs/lisp/net/.  Any other files?  Perhaps: starttls.el, sha1.el,
> sieve*.el, format-spec.el.

pgg*.el?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: pop3.el itegration with netrc.el

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> I don't know if it is inconvenient for Miles if we install a change in
> v5-10 and trunk at the same time.

The automatic merge usually deals with ignoring completely identical
changes, so they're not generally a problem.  If the code actually has to
be different for the trunk and v5-10 then there will be a conflict, but
I'll usually just notice that it's essentially the same code, and drop the
merge for that hunk -- which is easier than actually having to fix the code
myself!

So far it hasn't been much of a problem; as usual (see my previous post...)
the main annoyance is ChangeLogs:  I try to eliminate redundant ChangeLog
entries, but often this takes searching around.

The main thing that would help me is if when you install in both places,
try to make sure the ChangeLog text is _identical_, as much as possible.

Thanks,

-Miles
-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

emacs->gnus merge questions

[Miles Bader]

I'm doing the back-merge from the Emacs trunk to the Gnus trunk.

There are some changes which may or may not be appropriate for Gnus:

(1) deleted:  encrypt.el
(2) deleted:  assistant.el
(3) rename:   password.el => password-cache.el

I'm inclined to include all these changes (the fewer differences between
Gnus and Gnus-in-Emacs, the better); does anyone have a comment?

In addition, uses of `declare-function' have been added to various
files.  I assume a Gnus maintainer will want to replace this with a
gnus-specific macro for backwards compatibility.

-Miles

-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: emacs->gnus merge questions

[Reiner Steib]

On Sat, Dec 08 2007, Miles Bader wrote:

> I'm doing the back-merge from the Emacs trunk to the Gnus trunk.
>
> There are some changes which may or may not be appropriate for Gnus:
>
> (1) deleted:  encrypt.el

I'm not sure about this one.  Ted?

> (2) deleted:  assistant.el

Please don't delete assistant.el.  I hope that someone will continue
developing it.  (In Emacs, *.ast need to be removed as well.)

> (3) rename:   password.el => password-cache.el

Yes, please do.  Could you also sync the relevant changes from Emacs?

E.g. use...
(or (require 'password-cache nil t)
    (require 'password))

> I'm inclined to include all these changes (the fewer differences between
> Gnus and Gnus-in-Emacs, the better); does anyone have a comment?
>
> In addition, uses of `declare-function' have been added to various
> files.  I assume a Gnus maintainer will want to replace this with a
> gnus-specific macro for backwards compatibility.

Yes, there is a discussion about this:
<http://thread.gmane.org/gmane.emacs.devel/84386/focus=65888>

I hope Richard won't object to keep the files the same in both CVSes
(e.g. imap.el) even if we add compatibility code like...

(eval-and-compile
  (unless (fboundp 'declare-function) (defmacro declare-function (&rest r))))

BTW, sometimes it would be nice to know which changes have already be
synced from/to Emacs CVS and or compare.

What do you think about adding tags to Gnus CVS:

merge_to_emacs_trunk
merge_from_emacs_trunk
merge_to_emacs_22
merge_from_emacs_22

After you have done the merge, (re)tag the repositories.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: emacs->gnus merge questions

[Ted Zlatanov]

On Sat, 08 Dec 2007 20:38:29 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Sat, Dec 08 2007, Miles Bader wrote:
>> I'm doing the back-merge from the Emacs trunk to the Gnus trunk.
>> 
>> There are some changes which may or may not be appropriate for Gnus:
>> 
>> (1) deleted:  encrypt.el

RS> I'm not sure about this one.  Ted?

It would be great if it could stay somewhere, maybe under contrib/
because I know at least 2 people use it.  Also, can we have a
conditional use in netrc.el if it's loaded?  I don't want to redefine
netrc functionality as well for everyone that wants to use it.

If it can stay, I'll need to change its library requirements from
password to password-cache as previously discussed.

Ted

Re: emacs->gnus merge questions

[Ted Zlatanov]

On Tue, 11 Dec 2007 10:22:50 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 08 Dec 2007 20:38:29 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 
RS> On Sat, Dec 08 2007, Miles Bader wrote:
>>> I'm doing the back-merge from the Emacs trunk to the Gnus trunk.
>>> 
>>> There are some changes which may or may not be appropriate for Gnus:
>>> 
>>> (1) deleted:  encrypt.el

RS> I'm not sure about this one.  Ted?

TZ> It would be great if it could stay somewhere, maybe under contrib/
TZ> because I know at least 2 people use it.  Also, can we have a
TZ> conditional use in netrc.el if it's loaded?  I don't want to redefine
TZ> netrc functionality as well for everyone that wants to use it.

TZ> If it can stay, I'll need to change its library requirements from
TZ> password to password-cache as previously discussed.

I am including a patch (not comitted yet) which changes encrypt.el docs
to specifically say a (require) call is needed, and uses the
(load-library) idea Glen Morris posted earlier to pick between
password.el and password-cache.el.  I like its brevity :)

The patch also changes netrc.el to work with or without encrypt.el; when
encrypt.el is loaded and encrypt-file-alist is not nil (using the
(bound-and-true-p) macro from bindings.el) the netrc.el code behaves as
before; otherwise it will just insert the netrc file contents normally.
Will this work in XEmacs?

Please review the patch and let me know if encrypt.el is staying in
gnus/contrib or if I should host it separately.  Either way, the patch
should be applied if everyone agrees it will work OK.

Thanks
Ted

encrypt.el (was: emacs->gnus merge questions)

[Reiner Steib]

[ Sorry for the long delay.  I'm trying to go through my ticked
articles...]

On Tue, Dec 18 2007, Ted Zlatanov wrote:

> Please review the patch and let me know if encrypt.el is staying in
> gnus/contrib or if I should host it separately. 

If you don't have a strong preference, I'd suggest to move encrypt.el
to contrib/ to make it more clear that it is not part of Gnus bundled
with Emacs.  Please also add an entry to contrib/README.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Ted Zlatanov]

On Sat, 16 Feb 2008 14:12:26 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> [ Sorry for the long delay.  I'm trying to go through my ticked
RS> articles...]

RS> On Tue, Dec 18 2007, Ted Zlatanov wrote:

>> Please review the patch and let me know if encrypt.el is staying in
>> gnus/contrib or if I should host it separately. 

RS> If you don't have a strong preference, I'd suggest to move encrypt.el
RS> to contrib/ to make it more clear that it is not part of Gnus bundled
RS> with Emacs.  Please also add an entry to contrib/README.

I'd rather remove it in favor of EasyPG.

I'll adjust the netrc.el code so it doesn't reference encrypt.el
anymore, and uses EasyPG to load the same files.

The only downside is that uses must install EasyPG to get those
features, until it's part of Emacs (I don't know when that will happen,
maybe after the next release?)

Ted

Re: encrypt.el

[Reiner Steib]

On Thu, Feb 28 2008, Ted Zlatanov wrote:

> On Sat, 16 Feb 2008 14:12:26 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 
> RS> On Tue, Dec 18 2007, Ted Zlatanov wrote:
>>> [...] let me know if encrypt.el is staying in gnus/contrib or if I
>>> should host it separately.
>
> RS> If you don't have a strong preference, I'd suggest to move encrypt.el
> RS> to contrib/ to make it more clear that it is not part of Gnus bundled
> RS> with Emacs.  Please also add an entry to contrib/README.
>
> I'd rather remove it in favor of EasyPG.

That's up to you.

> I'll adjust the netrc.el code so it doesn't reference encrypt.el
> anymore, and uses EasyPG to load the same files.
>
> The only downside is that uses must install EasyPG to get those
> features, until it's part of Emacs (I don't know when that will happen,
> maybe after the next release?)

It is already in Emacs CVS.  But it won't appear in Emacs 22.*.  I
don't know about XEmacs.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: encrypt.el

[Ted Zlatanov]

On Thu, 28 Feb 2008 21:28:38 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Thu, Feb 28 2008, Ted Zlatanov wrote:
>> I'll adjust the netrc.el code so it doesn't reference encrypt.el
>> anymore, and uses EasyPG to load the same files.
>> 
>> The only downside is that uses must install EasyPG to get those
>> features, until it's part of Emacs (I don't know when that will happen,
>> maybe after the next release?)

RS> It is already in Emacs CVS.  But it won't appear in Emacs 22.*.  I
RS> don't know about XEmacs.

Hm, I wonder if I should leave encrypt.el hooks in netrc.el or remove
them.  If I remove them, Emacs 22 users will have to get EasyPG and
enable epa-file-mode on their own to encrypt their authinfo/netrc files.
I could put up a warning if I detect encrypt-* variables after
encrypt.el is remove, but that's annoying and about as much work as
keeping encrypt.el around.

I was hoping to remove encrypt.el altogether but am not sure after
thinking about it.  Does anyone have an opinion?

Ted