emacs->gnus merge questions

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

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> (eval-and-compile
>   (unless (fboundp 'declare-function) (defmacro declare-function (&rest r))))

Defining standard functions is a very bad idea in general.  Better to
use the standard Gnus approach of a special `gnus-declare-function' or
whatever (yeah it's ugly, but...).

> 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

Ok.

-Miles

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: emacs->gnus merge questions

[Reiner Steib]

On Sat, Dec 08 2007, Miles Bader wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> (eval-and-compile
>>   (unless (fboundp 'declare-function) (defmacro declare-function (&rest r))))
>
> Defining standard functions is a very bad idea in general.  Better to
> use the standard Gnus approach of a special `gnus-declare-function' or
> whatever (yeah it's ugly, but...).

That was my first reaction too, but Richard and other Emacs developers
say it is okay in this case:
<http://thread.gmane.org/gmane.emacs.devel/84621>

>> merge_to_emacs_trunk
>> merge_from_emacs_trunk
>> merge_to_emacs_22
>> merge_from_emacs_22
>
> Ok.

Thanks.  (Feel free to suggest better names.)

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

Re: emacs->gnus merge questions

[Miles Bader]

-- 
Do not taunt Happy Fun Ball.

Re: emacs->gnus merge questions

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> (1) deleted:  encrypt.el
> I'm not sure about this one.  Ted?
>> (2) deleted:  assistant.el
> Please don't delete assistant.el.

Ok, I will leave both in for the time being.  Maybe encrypt.el should be
removed later though.

As best I can figure from the discussion on emacs-devel (the threads
seem all over the place):

 * There's some interest in assistant.el, but it hasn't been developed
   enough yet.  It's the sort of feature Gnus could really use (because
   of the complexity of configuring Gnus), but nobody is actually doing
   anything about it...

 * It seems unlikely encrypt.el is going to go into Emacs.

   The merge from Emacs changes netrc.el to not use encrypt.el, so
   leaving it in Gnus seems a bit pointless (the changes to netrc.el
   could be reverted in Gnus, but I'd rather avoid diverging sources
   when possible).

-Miles

-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

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

[Reiner Steib]

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

On Sun, Dec 09 2007, Miles Bader wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>> (1) deleted:  encrypt.el
>> I'm not sure about this one.  Ted?
[...]
> Ok, I will leave both in for the time being.  Maybe encrypt.el should be
> removed later though.

I just suggested to move in
<news:v9r6fd11vp.fsf_-_@marauder.physik.uni-ulm.de>.

> As best I can figure from the discussion on emacs-devel (the threads
> seem all over the place):
>
[...]
>  * It seems unlikely encrypt.el is going to go into Emacs.

That's my conclusion as well.  Now that EasyPG is included in
Emacs 23, users could probably use the `auto-compression-mode'-like
feature (under discussion/development?) for ~/.authinfo, too.

>    The merge from Emacs changes netrc.el to not use encrypt.el, so
>    leaving it in Gnus seems a bit pointless (the changes to netrc.el
>    could be reverted in Gnus, but I'd rather avoid diverging sources
>    when possible).

ACK, diverging sources should be avoided.  As i understand, encrypt.el
can now be used optionally in netrc.el so both versions (Emacs trunk
and Gnus trunk) should be identical.

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

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

[Reiner Steib]

On Sun, Dec 09 2007, Miles Bader wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>> (2) deleted:  assistant.el
>> Please don't delete assistant.el.
>
> Ok, I will leave both in for the time being.  [...]
>
> As best I can figure from the discussion on emacs-devel (the threads
> seem all over the place):
>
>  * There's some interest in assistant.el, but it hasn't been developed
>    enough yet.

Correct.

>    It's the sort of feature Gnus could really use (because of the
>    complexity of configuring Gnus), but nobody is actually doing
>    anything about it...

It would probably be useful for other parts of Emacs as well.

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

Re: emacs->gnus merge questions

[Ted Zlatanov]

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

On Mon, 17 Dec 2007 17:02:35 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> I am including a patch (not comitted yet) ...

I didn't, but I am now :)

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: netrc+encrypt.patch --]
[-- Type: text/x-diff, Size: 2207 bytes --]

? netrc+encrypt.patch
Index: encrypt.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/encrypt.el,v
retrieving revision 7.11
diff -u -r7.11 encrypt.el
--- encrypt.el	1 Nov 2007 15:01:11 -0000	7.11
+++ encrypt.el	17 Dec 2007 22:55:28 -0000
@@ -29,11 +29,12 @@
 ;;; particular aspect.
 
 ;;; Use in Gnus like this:
+;;; (require 'encrypt)
 ;;; (setq
 ;;;   nnimap-authinfo-file "~/.authinfo.enc"
 ;;;   nntp-authinfo-file "~/.authinfo.enc"
 ;;;   smtpmail-auth-credentials "~/.authinfo.enc"
-;;;   ;; using the AES256 cipher, feel free to use your own favorite
+;;;   ;; GnuPG using the AES256 cipher, feel free to use your own favorite
 ;;;   encrypt-file-alist (quote (("~/.authinfo.enc" (gpg "AES256"))))
 ;;;   password-cache-expiry 600)
 
@@ -53,7 +54,9 @@
 
 ;; autoload password
 (eval-and-compile
-  (autoload 'password-read "password"))
+  (if (locate-library "password-cache")
+      (require 'password-cache)
+    (require 'password)))
 
 (defgroup encrypt '((password-cache custom-variable)
 		    (password-cache-expiry custom-variable))
Index: netrc.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/netrc.el,v
retrieving revision 7.17
diff -u -r7.17 netrc.el
--- netrc.el	9 Dec 2007 00:04:21 -0000	7.17
+++ netrc.el	17 Dec 2007 22:55:28 -0000
@@ -34,6 +34,10 @@
 ;;; .netrc and .authinfo rc parsing
 ;;;
 
+;; use encrypt if loaded (but netrc-use-encrypt also has to be on)
+(eval-and-compile
+  (autoload 'encrypt-find-model "encrypt")
+  (autoload 'encrypt-insert-file-contents "encrypt"))
 (defalias 'netrc-point-at-eol
   (if (fboundp 'point-at-eol)
       'point-at-eol
@@ -54,8 +58,12 @@
       (let ((tokens '("machine" "default" "login"
 		      "password" "account" "macdef" "force"
 		      "port"))
+	    (encryption-model (when (bound-and-true-p encrypt-file-alist)
+				(encrypt-find-model file)))
 	    alist elem result pair)
-	(insert-file-contents file)
+	(if encryption-model
+	    (encrypt-insert-file-contents file encryption-model)
+	  (insert-file-contents file))
 	(goto-char (point-min))
 	;; Go through the file, line by line.
 	(while (not (eobp))

Re: emacs->gnus merge questions

[Ted Zlatanov]

On Mon, 17 Dec 2007 17:02:35 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> 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.

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

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

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

I am comitting this patch, assuming encrypt.el will remain within Gnus.

Ted

encrypt.el glue to PGG library added (was: emacs->gnus merge questions)

[Ted Zlatanov]

I added an encrypt.el option (for encrypt-file-alist) to use PGG as the
encode/decode option.  It currently only uses the symmetric
functionality and lets PGG do all the cipher and passphrase management.
If you want me to add more PGG glue, let me know.

I also reworked the encrypt.el API to be a bit nicer, using more
temporary buffers in a few places.

Please let me know if you need anything in the encrypt.el library.  I
currently use it to keep my NNTP, SMTP, IMAP, POP, etc. passwords
encrypted in a single place with netrc.el.  If you can think of any
other places in Gnus where encryption would make sense, let me know.

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