Gnus in Emacs is updated to No Gnus 0.7

Gnus in Emacs is updated to No Gnus 0.7

[Miles Bader]

I've merged the Gnus CVS trunk (No Gnus 0.7) into the Emacs CVS trunk.

I made sure it compiled and works for basic news reading but I suppose
there's bound to be something that broke.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gnus in Emacs is updated to No Gnus 0.7

[Leo]

On 2007-10-28 09:20 +0000, Miles Bader wrote:
> I've merged the Gnus CVS trunk (No Gnus 0.7) into the Emacs CVS trunk.
>
> I made sure it compiled and works for basic news reading but I suppose
> there's bound to be something that broke.
>
> -Miles

Many thanks.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: Gnus in Emacs is updated to No Gnus 0.7

[Miles Bader]

BTW, some issues that probably need to be dealt with:

  1) I left the version name/number as "No Gnus 0.7".  I assume that
     should be changed to something like 5.13?

  2) It includes "password.el" (in lisp/gnus), which I seemed to
     remember was not liked in previous emacs-devel discussion.  However
     that's a small enough file that I suppose it can be easily replaced
     if necessary.

  3) There are a bunch of new image files (in etc/images/...), and two
     new image subdirectoryes "etc/images/smilies/grayscale" and
     "etc/images/smilies/medium".

[If anybody wants a big patch file containing the entire changeset, I
can send one.]

-Miles

-- 
Fast, small, soon; pick any 2.

Re: Gnus in Emacs is updated to No Gnus 0.7

[Reiner Steib]

On Sun, Oct 28 2007, Miles Bader wrote:

> I've merged the Gnus CVS trunk (No Gnus 0.7) into the Emacs CVS trunk.

Thanks a lot.

> BTW, some issues that probably need to be dealt with:
>
>   1) I left the version name/number as "No Gnus 0.7".  I assume that
>      should be changed to something like 5.13?

Fixed.

>   2) It includes "password.el" (in lisp/gnus), which I seemed to
>      remember was not liked in previous emacs-devel discussion.  However
>      that's a small enough file that I suppose it can be easily replaced
>      if necessary.

There are some other non-Gnus specific files which should probably be
moved from lisp/gnus/ to other directories.  I'll come back to this in
a separate message.

>   3) There are a bunch of new image files (in etc/images/...), and two
>      new image subdirectoryes "etc/images/smilies/grayscale" and
>      "etc/images/smilies/medium".

What needs to be done here?  Adjust the Makefiles to install these?

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

Re: Gnus in Emacs is updated to No Gnus 0.7

[Leo]

On 2007-10-28 14:25 +0000, Reiner Steib wrote:
>>   1) I left the version name/number as "No Gnus 0.7".  I assume that
>>      should be changed to something like 5.13?
>
> Fixed.

Is there a point to make 4 versions of gnus, for now we have:

  5.11,  5.10.8
  5.13,  No Gnus 0.7

It is unnecessarily confusing for new users.

HTH,
-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: Gnus in Emacs is updated to No Gnus 0.7

[Miles Bader]

Leo <sdl.web@gmail.com> writes:
> Is there a point to make 4 versions of gnus

Yes.

There really only two:  the stable distribution (5.11 and 5.10.8), and
the development distribution (5.13 and No Gnus).  The members of each
pair are more or less the same as each other, the only difference being
whether they're bundled with Emacs or not.

> It is unnecessarily confusing for new users.

I doubt they care, unless they're making a bug report, and it's exactly
for the purpose of bug reports that the current numbering exists...

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: Gnus in Emacs is updated to No Gnus 0.7

[Reiner Steib]

On Sun, Oct 28 2007, Miles Bader wrote:

> Leo <sdl.web@gmail.com> writes:
>> Is there a point to make 4 versions of gnus
>
> Yes.
>
> There really only two:  the stable distribution (5.11 and 5.10.8), and
> the development distribution (5.13 and No Gnus).  The members of each
> pair are more or less the same as each other, the only difference being
> whether they're bundled with Emacs or not.
>
>> It is unnecessarily confusing for new users.

New users should either use the version bundled with the most recent
Emacs release (Gnus 5.11 in Emacs 22.1) or the most recent stand-alone
distribution Gnus 5.10.*.

New users should not use Emacs CVS (i.e. Gnus 5.13) nor No Gnus unless
they know what they are doing.  This is why these are *development*
versions.

> I doubt they care, unless they're making a bug report, and it's exactly
> for the purpose of bug reports that the current numbering exists...

ACK

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

Re: Gnus in Emacs is updated to No Gnus 0.7

[Glenn Morris]

Reiner Steib wrote:

>>   3) There are a bunch of new image files (in etc/images/...), and two
>>      new image subdirectoryes "etc/images/smilies/grayscale" and
>>      "etc/images/smilies/medium".
>
> What needs to be done here?  Adjust the Makefiles to install these?

No need to adjust the Makefile, but I updated make-dist.

Are the images in these directories just automatically converted
versions of those in the parent directory? If so, I will add
appropriate READMEs.

Re: Gnus in Emacs is updated to No Gnus 0.7

[Reiner Steib]

On Mon, Oct 29 2007, Glenn Morris wrote:

> Reiner Steib wrote:
>>>   3) There are a bunch of new image files (in etc/images/...), and two
>>>      new image subdirectoryes "etc/images/smilies/grayscale" and
>>>      "etc/images/smilies/medium".
>> What needs to be done here?  Adjust the Makefiles to install these?
> No need to adjust the Makefile, but I updated make-dist.

Thanks.

> Are the images in these directories just automatically converted
> versions of those in the parent directory? If so, I will add
> appropriate READMEs.

No, these are _different_ smilies from Adam Sjøgren,
cf. `smiley-style'.  It seems that the corresponding ChangeLog entries
were not included.

I will look through Gnus' top-level ChangeLog and see what needs to be
done (starting from `grep-changelog --text=etc/ --from-date=2004-01-04
--exclude=etc/Makefile ChangeLog').

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

Re: Gnus in Emacs is updated to No Gnus 0.7

[Daiki Ueno]

2007/10/28, Miles Bader <miles@gnu.org>:
>   2) It includes "password.el" (in lisp/gnus), which I seemed to
>      remember was not liked in previous emacs-devel discussion.  However
>      that's a small enough file that I suppose it can be easily replaced
>      if necessary.

I can't remember the previous discussion, but I think it's not so bad
for *applications* (such as Gnus) to use password.el.  I'd just say
that it's bad if it is implicitly used by low-level *libraries* such
as pgg.el.

Regards,
-- 
Daiki Ueno

Re: Gnus in Emacs is updated to No Gnus 0.7

[Michael Albinus]

"Daiki Ueno" <ueno@unixuser.org> writes:

> 2007/10/28, Miles Bader <miles@gnu.org>:
>>   2) It includes "password.el" (in lisp/gnus), which I seemed to
>>      remember was not liked in previous emacs-devel discussion.  However
>>      that's a small enough file that I suppose it can be easily replaced
>>      if necessary.
>
> I can't remember the previous discussion, but I think it's not so bad
> for *applications* (such as Gnus) to use password.el.  I'd just say
> that it's bad if it is implicitly used by low-level *libraries* such
> as pgg.el.

Tramp uses also password.el if it is in the load path. It is a
convenient library if somebody uses an scp-like method, but does not run
ssh-agent.

It would be important to know whether there are deficiencies which would
make the use of password.el impossible for Tramp.

> Regards,

Best regards, Michael.

Re: Gnus in Emacs is updated to No Gnus 0.7

[Daiki Ueno]

2007/10/29, Michael Albinus <michael.albinus@gmx.de>:
> > I can't remember the previous discussion, but I think it's not so bad
> > for *applications* (such as Gnus) to use password.el.  I'd just say
> > that it's bad if it is implicitly used by low-level *libraries* such
> > as pgg.el.
>
> Tramp uses also password.el if it is in the load path. It is a
> convenient library if somebody uses an scp-like method, but does not run
> ssh-agent.
>
> It would be important to know whether there are deficiencies which would
> make the use of password.el impossible for Tramp.

My recommendation is simple: do password caching things at the
(single) place closest to a human user, or do nothing (just trust
ssh-agent/gpg-agent).  Otherwise the user will have to track down the
code between the UI and ssh/gpg to make sure where his secret is
really cached.

If Tramp had been designed to be mainly used by other programs rather
than human users, it might have caused the deficiencies.  However, I
believe it's not.  i.e. Tramp is an *application* rather than a
*library*.

Yes, password.el is a library itself.  But no one will be confused
about what it does.

Regards,
-- 
Daiki Ueno

New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Reiner Steib]

On Sun, Oct 28 2007, Miles Bader wrote:

>   2) It includes "password.el" (in lisp/gnus), which I seemed to
>      remember was not liked in previous emacs-devel discussion.  However
>      that's a small enough file that I suppose it can be easily replaced
>      if necessary.

There are some other non-Gnus specific files which should probably be
moved from lisp/gnus/ to other directories. [1]

I'll provide a list of new files with some comments.  If you need to
know more about these files, I'd suggest to make a _separate_ reply
and cc the author or maintainer.

* assistant.el:

;;; assistant.el --- guiding users through Emacs setup
;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>

Its purpose is to provide a setup assistant ("setup wizard" in some
programs).  IIRC, this is not finished yet.

See etc/gnus/*.ast for some prototype assistant files.

* dns-mode.el: Already in Emacs 22 as textmodes/dns-mode.el.

* ecomplete.el:

;;; ecomplete.el --- electric completion of addresses and the like
;; Author: Lars Magne Ingebrigtsen <larsi

* encrypt.el:

;;; encrypt.el --- file encryption routines
;; Author: Teodor Zlatanov <tzz@lifelogs.com>

* gnus-bookmark.el: Gnus specific.

* hashcash.el:

;;; hashcash.el --- Add hashcash payments to email
;; Maintainer: Paul Foley <mycroft@actrix.gen.nz>

* hmac-def.el: From FLIM (Faithful Library about Internet Message).
  Used for sasl-*.el.
* hmac-md5.el: Ditto.
* md4.el: Ditto.
* ntlm.el: Ditto.

hmac-def.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
hmac-md5.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
md4.el:;; Author: Taro Kawagishi <tarok@transpulse.org>
ntlm.el:;; Author: Taro Kawagishi <tarok@transpulse.org>

* password.el:

;;; password.el --- Read passwords from user, possibly using a password cache.
;; Author: Simon Josefsson <simon@josefsson.org>

,----[ doc/misc/gnus-news.el ]
| @item Gnus includes a password cache mechanism in password.el.
| 
| It is enabled by default (see @code{password-cache}), with a short
| timeout of 16 seconds (see @code{password-cache-expiry}).  If
| @acronym{PGG} is used as the @acronym{PGP} back end, the @acronym{PGP}
| passphrase is managed by this mechanism.  Passwords for ManageSieve
| connections are managed by this mechanism, after querying the user
| about whether to do so.
`----

* sasl.el: Simple Authentication and Security Layer.  From FLIM [1].
* sasl-cram.el:
* sasl-digest.el:
* sasl-ntlm.el:

sasl-cram.el:;; Author: Daiki Ueno <ueno@unixuser.org>
sasl-digest.el:;; Author: Daiki Ueno <ueno@unixuser.org>
sasl.el:;; Author: Daiki Ueno <ueno@unixuser.org>
sasl-ntlm.el:;; Author: Taro Kawagishi <tarok@transpulse.org>

,----[ doc/misc/gnus-news.el ]
| @item Gnus includes the Emacs Lisp @acronym{SASL} library.
| 
| This provides a clean @acronym{API} to @acronym{SASL} mechanisms from
| within Emacs.  The user visible aspects of this, compared to the earlier
| situation, include support for @acronym{DIGEST}-@acronym{MD5} and
| @acronym{NTLM}.   @xref{Top, ,Emacs SASL, sasl, Emacs SASL}.
`----

* smime-ldap.el:

;;; smime-ldap.el --- client interface to LDAP for Emacs
;; Author: Oscar Figueiredo <Oscar.Figueiredo@di.epfl.ch>

* spam-wash.el: Gnus specific.

Bye, Reiner.

[1]
,----[ <http://thread.gmane.org/gmane.emacs.devel/80123/focus=81191> ]
| From: Richard Stallman
| Subject: Re: mailcap viewers in dired; gnus-dired.el, mailcap.el
| To: Lars Magne Ingebrigtsen
| Cc: emacs-devel@gnu.org
| Date: Fri, 19 Oct 2007 01:40:48 -0400
| Message-ID: <E1IikbI-000076-Rp@fencepost.gnu.org>
| 
|     [...] When a new, general facility has been developed because
|     Gnus needed it, it would be counter-productive to not distribute
|     it with Gnus just because it's not Gnus-specific.
| 
| I don't mind if you distribute it with Gnus.  The point is to install it
| into Emacs.
| 
|     But when merging, the general stuff should not end up in the Gnus
|     directory, though.
| 
| If that means thinking of these added files as Emacs facilities rather
| than as part of Gnus, that would do the job.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

encrypt.el in No Gnus 0.7 (was: New Emacs facilities from Gnus)

[Ted Zlatanov]

On Mon, 29 Oct 2007 08:49:10 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> I'll provide a list of new files [in No Gnus 0.7] with some
RS> comments.  If you need to know more about these files, I'd suggest
RS> to make a _separate_ reply and cc the author or maintainer.

...

RS> * encrypt.el:

RS> ;;; encrypt.el --- file encryption routines
RS> ;; Author: Teodor Zlatanov <tzz@lifelogs.com>

(I haven't brought this up sooner due to lack of time, but this seems
like a good chance to discuss it)

This could go into mainline Emacs if people are interested.  For Gnus it
lets a user encrypt the .netrc file for example (I modified netrc.el
accordingly).  It can encrypt/decrypt any file (ciphers are matched with
the file path) and doesn't interfere with the regular Emacs file
facilities since it provides a separate API.  Software has to explicitly
use the encrypt.el API, e.g.

(let (encryption-model (encrypt-find-model file))
     (if encryption-model
	    (encrypt-insert-file-contents file encryption-model)
	  (insert-file-contents file)))

It uses password.el to manage passphrase caching.

I posted instructions on usage to the ding list, but they haven't gone
into the manual (partly because I didn't know if people would complain
about encrypt.el, or if it would eventually move to mainline Emacs).

FWIW, I think it's really nice to encrypt the .netrc file when you are
on a shared machine.  Then you can put IMAP passwords, etc. in the file
without the obvious plaintext risks; one passphrase decrypts the whole
thing and you don't enter any more passwords until the passphrase
expires.

Ted

Re: encrypt.el in No Gnus 0.7

[Reiner Steib]

On Wed, Oct 31 2007, Ted Zlatanov wrote:

> This could go into mainline Emacs if people are interested.  For Gnus it
> lets a user encrypt the .netrc file for example (I modified netrc.el
> accordingly).  

FYI: `net/netrc.el' has also been updated, so these changes are
already in Emacs CVS.

> I posted instructions on usage to the ding list, but they haven't gone
> into the manual (partly because I didn't know if people would complain
> about encrypt.el, or if it would eventually move to mainline Emacs).

Could you please send it again?

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

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Wed, 31 Oct 2007 21:36:00 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Wed, Oct 31 2007, Ted Zlatanov wrote:
>> This could go into mainline Emacs if people are interested.  For Gnus it
>> lets a user encrypt the .netrc file for example (I modified netrc.el
>> accordingly).  

RS> FYI: `net/netrc.el' has also been updated, so these changes are
RS> already in Emacs CVS.

It definitely makes sense to move encrypt.el into Emacs as well then.
My main concern was that it overlaps with all the other *crypt*.el
packages, and I really think that encrypt.el's simplicity and
non-invasiveness justifies its existence.  But it requires password.el.
I'm open to suggestions as to the best way to manage it.

>> I posted instructions on usage to the ding list, but they haven't gone
>> into the manual (partly because I didn't know if people would complain
>> about encrypt.el, or if it would eventually move to mainline Emacs).

RS> Could you please send it again?

This was in <g6964b530cd.fsf@dhcp-65-162.kendall.corp.akamai.com>, in January, I wrote:
> I put in some docs and fixes for encrypt.el.  Please see the beginning
> of the file.  Let me know if you have ideas or suggestions.  In the
> context of Gnus, encrypt.el is a very nice way to keep all your
> passwords and login info locked under one decryption password, usually
> that means your ~/.authinfo.  I've been using encrypt.el in Gnus for a
> while with GnuPG, and it works fine.  Those that know GnuPG well will
> probably have ideas on improving--using the private key instead of a
> password, etc.  The idea for encrypt.el is to let the user choose from
> any number of methods, so if you have suggestions for additional
> encryption/decryption models, please let me know.

So I actually posted a pointer to the instructions :)  Sorry for the
confusion, I didn't remember so long ago.

I have updated the docs in the code since, with the setup I use
day-to-day and which I am confident is reliable.  So encrypt.el has, at
the very beginning of the file, docs sufficient to get started using it
to keep encrypted netrc/authinfo files.

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/1, Ted Zlatanov <tzz@lifelogs.com>:
> It definitely makes sense to move encrypt.el into Emacs as well then.
> My main concern was that it overlaps with all the other *crypt*.el
> packages, and I really think that encrypt.el's simplicity and
> non-invasiveness justifies its existence.  But it requires password.el.
> I'm open to suggestions as to the best way to manage it.

epa-file.el in EasyPG can also do that.  Have you looked at it?
I think it is much easier to use since it does not need elisp setup
like encrypt-file-alist.

Yes, EasyPG is a bit complex and invasive.  But IMO sometimes
usability should be given priority over simplicity & non-invasiveness.

BTW, I just tried encrypt.el and I encountered a few issues.  (1) It
uses gnus-error to report errors so there is a dependency to
gnus-util.el.  (2) The instruction says M-x encrypt-file-contents but
there is no such function (perhaps is it a typo of
encrypt-write-file-contents?).  (3) encrypt-find-model does not
resolve path names.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Thu, 1 Nov 2007 10:30:54 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote: 

DU> 2007/11/1, Ted Zlatanov <tzz@lifelogs.com>:
>> It definitely makes sense to move encrypt.el into Emacs as well then.
>> My main concern was that it overlaps with all the other *crypt*.el
>> packages, and I really think that encrypt.el's simplicity and
>> non-invasiveness justifies its existence.  But it requires password.el.
>> I'm open to suggestions as to the best way to manage it.

DU> epa-file.el in EasyPG can also do that.  Have you looked at it?
DU> I think it is much easier to use since it does not need elisp setup
DU> like encrypt-file-alist.

encrypt-file-alist can be set up via Customize.  It's intended as an
API, however, so I am not concerned about end users too much.

Your EasyPG code is probably better, I am not an ELisp expert by any
means.  But epa-file.el not an API, and does not support arbitrary
ciphers as encrypt.el does (AFAIK).  See the encrypt.el XOR cipher for
an example of what I mean.  EasyPG seems firmly attached to the GPG/PGP
process, which is not a bad thing, only it doesn't provide an abstract
encryption API.

DU> Yes, EasyPG is a bit complex and invasive.  But IMO sometimes
DU> usability should be given priority over simplicity &
DU> non-invasiveness.

Sure, and that's your choice to make within the EasyPG package, which
has specific needs.  I think an API must be simple an non-invasive,
though, and encrypt.el is by those standards a better API than
epa-file.el or any other *crypt* package I've seen.  If I'm wrong,
please tell me.

DU> BTW, I just tried encrypt.el and I encountered a few issues.  (1) It
DU> uses gnus-error to report errors so there is a dependency to
DU> gnus-util.el.

Yes.  I'll gladly fix that if it moves outside Gnus but for now that's
the appropriate notification mechanism.

DU> (2) The instruction says M-x encrypt-file-contents but there is no
DU> such function (perhaps is it a typo of
DU> encrypt-write-file-contents?).

I fixed that in the docs.  Thank you very much.

DU> (3) encrypt-find-model does not resolve path names.

That was intentional at the time, because I thought resolving the path
wouldn't allow matching ~ and such.  If it's wrong, please let me know.

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/2, Ted Zlatanov <tzz@lifelogs.com>:
> On Thu, 1 Nov 2007 10:30:54 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote:
> DU> epa-file.el in EasyPG can also do that.  Have you looked at it?
> DU> I think it is much easier to use since it does not need elisp setup
> DU> like encrypt-file-alist.
>
> encrypt-file-alist can be set up via Customize.  It's intended as an
> API, however, so I am not concerned about end users too much.

I think encrypt-file-alist is too much custamisable since GnuPG
records what cipher is used to encrypt in the PGP message.  See
RFC2440.

> Your EasyPG code is probably better, I am not an ELisp expert by any
> means.  But epa-file.el not an API, and does not support arbitrary
> ciphers as encrypt.el does (AFAIK).  See the encrypt.el XOR cipher for
> an example of what I mean.  EasyPG seems firmly attached to the GPG/PGP
> process, which is not a bad thing, only it doesn't provide an abstract
> encryption API.

Yes, EasyPG does not (yet) provide a way to specify the cipher
algorithm but as I mentioned above we need to specify only the first
time.  Is it not enough to edit ~/.gnupg/gpg.conf or manually call the
gpg command with options?

I also think that your XOR cipher is not a good idea as a fallback
algorithm.  Have you ever read Simon Singh's "The Code Book"?

> DU> Yes, EasyPG is a bit complex and invasive.  But IMO sometimes
> DU> usability should be given priority over simplicity &
> DU> non-invasiveness.
>
> Sure, and that's your choice to make within the EasyPG package, which
> has specific needs.  I think an API must be simple an non-invasive,
> though, and encrypt.el is by those standards a better API than
> epa-file.el or any other *crypt* package I've seen.  If I'm wrong,
> please tell me.

epa-file.el is an *application* not a *libarary* (I'm a bit tired of
explanating these difference again and again...).  epg.el is the
library and it provides the API.  Since it only accepts string or file
for encryption and do not cache passphrase,  it is simpler than
encrypt.el.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

We have already decided we want to install epg.  If encrypt.el
basically duplicates epg, let's not install encrypt.el in Emacs,
or in Gnus.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Thu, 01 Nov 2007 19:08:26 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS> We have already decided we want to install epg.  If encrypt.el
RS> basically duplicates epg, let's not install encrypt.el in Emacs,
RS> or in Gnus.

My arguments are in a separate message, but essentially the difference
is between providing a GnuPG interface (epg) and providing an
architecture with user-supplied ciphers that does not depend on GnuPG or
any other external tools (encrypt.el).  I think at least Gnus, and IMHO
Emacs too, benefit from a self-contained, non-invasive, simple library
like encrypt.el.

Ted

Re: encrypt.el in No Gnus 0.7

[Stefan Monnier]

> On Thu, 01 Nov 2007 19:08:26 -0400 Richard Stallman <rms@gnu.org> wrote: 
RS> We have already decided we want to install epg.  If encrypt.el
RS> basically duplicates epg, let's not install encrypt.el in Emacs,
RS> or in Gnus.

> My arguments are in a separate message, but essentially the difference
> is between providing a GnuPG interface (epg) and providing an
> architecture with user-supplied ciphers that does not depend on GnuPG or
> any other external tools (encrypt.el).  I think at least Gnus, and IMHO
> Emacs too, benefit from a self-contained, non-invasive, simple library
> like encrypt.el.

I think there's enough space in the Emacs world for both to coexist.


        Stefan

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    My arguments are in a separate message, but essentially the difference
    is between providing a GnuPG interface (epg) and providing an
    architecture with user-supplied ciphers that does not depend on GnuPG or
    any other external tools (encrypt.el).

I just looked at encrypt.el.  It appears to support just GnuPG
and "Built-in simple XOR".  And built-in simple XOR is just an
example, not for real use.

So what useful generality do we really get from this?

By contrast, if Gnus uses EasyPG, I presume that gives
various advantages in using GnuPG compared with the more
direct use of GnuPG thru encrypt.el.  Could someone confirm
that that is true?

All in all it looks like the best thing is to install EasyPG and make
Gnus use it directly.  I'm willing to change my mind if shown a real
advantage of encrypt.el, but I don't see one now.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Sun, 04 Nov 2007 14:56:37 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS>     My arguments are in a separate message, but essentially the difference
RS>     is between providing a GnuPG interface (epg) and providing an
RS>     architecture with user-supplied ciphers that does not depend on GnuPG or
RS>     any other external tools (encrypt.el).

RS> I just looked at encrypt.el.  It appears to support just GnuPG
RS> and "Built-in simple XOR".  And built-in simple XOR is just an
RS> example, not for real use.

The idea is to allow users to supply their own ciphers, and to support
other external utilities as users find it necessary.  I have not had the
time to write more ciphers.

RS> So what useful generality do we really get from this?

1) users don't have to install GnuPG to use simple obfuscation ciphers
(yes, this is sometimes useful).

2) users can be creative and experiment with ciphers in Emacs Lisp, and
share them with others without modifying GnuPG.

3) other external utilities can be supported.  As an example of a nice
use of multiple utilities, spam.el in the Gnus package supports a wide
array of anti-spam tools (including built-in Lisp); because it's easy to
write a backend for spam.el, users have contributed many (at least 4).

4) ciphers, being Emacs Lisp code, can do almost anything: SSH to a
remote machine, use BBDB, use IMAP, use version control...  There's just
no limit to what users can create within the encrypt.el API, which is
intentionally simple and non-invasive.  GnuPG can not match that
flexibility.

RS> By contrast, if Gnus uses EasyPG, I presume that gives
RS> various advantages in using GnuPG compared with the more
RS> direct use of GnuPG thru encrypt.el.  Could someone confirm
RS> that that is true?

It's not an A or B choice.  Both EasyPG and encrypt.el can be installed
and supported.  They are different libraries with different purposes.
One is a GnuPG interface, the other is a generic API.  At least within
Gnus I see no problem with using both.  Also, encrypt.el can use EasyPG
for GnuPG work, if that's necessary (and I think it's a good idea).

RS> All in all it looks like the best thing is to install EasyPG and make
RS> Gnus use it directly.  I'm willing to change my mind if shown a real
RS> advantage of encrypt.el, but I don't see one now.

I've explained this over and over.  I hope you will see the advantages
after all the explanations I've written.  If you need an example of a
more complicated and more creative Lisp cipher, I'll write one.  I do
hope the idea of giving the users creative freedom appeals to you.

Ted

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    RS> I just looked at encrypt.el.  It appears to support just GnuPG
    RS> and "Built-in simple XOR".  And built-in simple XOR is just an
    RS> example, not for real use.

    The idea is to allow users to supply their own ciphers, and to support
    other external utilities as users find it necessary.

It is a sensible feature, but is it worth including in Emacs?  I am
not convinced this is sufficiently useful to be worth including.

Is there any sign that users use it?

    1) users don't have to install GnuPG to use simple obfuscation ciphers
    (yes, this is sometimes useful).

If you mean Rot13, aren't there other interfaces for that?  It seems
to me that we don't want to use the same command for Rot13 as we use
for GPG, because it is inconvenient to have to select one or the other
each time.  We want two different commands.

    3) other external utilities can be supported.

Are there any that are useful to support?

    4) ciphers, being Emacs Lisp code, can do almost anything: SSH to a
    remote machine, use BBDB, use IMAP, use version control...

I really don't like the idea of labeling such things as "encryption".

All in all, encrypt.el still looks like unnecessary complexity which
doesn't pull its weight.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Mon, 05 Nov 2007 03:47:04 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS> I just looked at encrypt.el.  It appears to support just GnuPG
RS> and "Built-in simple XOR".  And built-in simple XOR is just an
RS> example, not for real use.

RS>     The idea is to allow users to supply their own ciphers, and to support
RS>     other external utilities as users find it necessary.

RS> It is a sensible feature, but is it worth including in Emacs?  I am
RS> not convinced this is sufficiently useful to be worth including.

In my experience, giving users creative freedom is always worth it.
Emacs is built around the idea of letting users do what they want, isn't
it?  I am surprised you are OK with locking Emacs users into GnuPG,
which is nice software but certainly not the only way to do encryption.

RS> Is there any sign that users use it?

The package was in Gnus, and I don't have bug reports.  I have not
advertised the library so far, except for brief notes to Gnus users.  So
I don't have a sample big enough to answer your question.

RS>     1) users don't have to install GnuPG to use simple obfuscation ciphers
RS>     (yes, this is sometimes useful).

RS> If you mean Rot13, aren't there other interfaces for that?  It seems
RS> to me that we don't want to use the same command for Rot13 as we use
RS> for GPG, because it is inconvenient to have to select one or the other
RS> each time.  We want two different commands.

I don't mean ROT13 specifically.  I keep repeating this: the users will
come up with interesting ciphers.  Instead of anticipating their needs,
the API should support them by being simple and flexible.

In any case, the user wouldn't select a cipher each time.  The
encrypt-find-model function will determine the encryption model,
currently from an alist.  The user chooses, for example, that
~/.authinfo is encrypted with GnuPG, but ~/emacs/*.el will use cipher X
because it's more appropriate.  Perhaps cipher X is the XOR cipher
because the user is OK with simple obfuscation.

RS>     3) other external utilities can be supported.

RS> Are there any that are useful to support?

I found a few GPL ones (just a sample list) with a simple web search:

MCrypt http://mcrypt.sourceforge.net/
AxCrypt http://www.axantum.com/AxCrypt/
ScramDisk 4 Linux http://sourceforge.net/projects/sd4l/
Several steganography tools (hide data inside an image, for example)

They all do things GnuPG doesn't as far as I can tell, though some
functionality may overlap.

RS>     4) ciphers, being Emacs Lisp code, can do almost anything: SSH to a
RS>     remote machine, use BBDB, use IMAP, use version control...

RS> I really don't like the idea of labeling such things as "encryption".

External functions may be involved in customizing the encryption process
Here are some examples (again, I'd rather let the users implement what
they need, this is just my list of things I might find interesting):

- use BBDB to store shared keys or public keys

- get shared or public keys from an IMAP server (stored in a message)

- on a CVS/SVN/etc. checkin/checkout, use another file in the repository
  to modify the shared key or as the shared key

- pure Lisp ciphers for quick experimentation and sharing

Ted

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    In my experience, giving users creative freedom is always worth it.

The question is whether to give users certain facilities.

    Emacs is built around the idea of letting users do what they want, isn't
    it?

In Emacs, users can change any Lisp code at run time.  This general
facility, which lets users do absolutely whatever they want, means we
do not need to provide specific customization features for everything
somebody would like to change.  We only provide specific customization
features where they are substantially useful.

Providing every hook that someone might imaginably want is an explicit
non-goal of Emacs development.  (And always has been.)

    RS> Is there any sign that users use it?

    The package was in Gnus, and I don't have bug reports.  I have not
    advertised the library so far, except for brief notes to Gnus users.  So
    I don't have a sample big enough to answer your question.

In other words, there is no indication that users actually use this
particular customization facility.

You could post a request where Gnus users will see it, asking them to
let you know if they have used it.

    I found a few GPL ones (just a sample list) with a simple web search:

    MCrypt http://mcrypt.sourceforge.net/
    AxCrypt http://www.axantum.com/AxCrypt/
    ScramDisk 4 Linux http://sourceforge.net/projects/sd4l/
    Several steganography tools (hide data inside an image, for example)

We are miscommunicating.  I think you mean that in principle they
could be useful for encryption.  Maybe they are.  But the question is
whether this particular feature is useful, not whether other useful
encryption programs exist.

    - use BBDB to store shared keys or public keys

    - get shared or public keys from an IMAP server (stored in a message)

    - on a CVS/SVN/etc. checkin/checkout, use another file in the repository
      to modify the shared key or as the shared key

I think the right place to implement any of these features is elsewhere.

    - pure Lisp ciphers for quick experimentation and sharing

That seems unimportant to me.

    In any case, the user wouldn't select a cipher each time.  The
    encrypt-find-model function will determine the encryption model,
    currently from an alist.  The user chooses, for example, that
    ~/.authinfo is encrypted with GnuPG, but ~/emacs/*.el will use cipher X
    because it's more appropriate.  Perhaps cipher X is the XOR cipher
    because the user is OK with simple obfuscation.

It does not seem very useful.

The main use of simple obfuscation ciphers is in sending mail, and for
that purpose, you cannot tell from a file name (there's none) or a
buffer name (it's the same as always) whether to do it.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Mon, 05 Nov 2007 21:16:18 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS>     Emacs is built around the idea of letting users do what they want, isn't
RS>     it?

RS> In Emacs, users can change any Lisp code at run time.  This general
RS> facility, which lets users do absolutely whatever they want, means we
RS> do not need to provide specific customization features for everything
RS> somebody would like to change.  We only provide specific customization
RS> features where they are substantially useful.

RS> Providing every hook that someone might imaginably want is an explicit
RS> non-goal of Emacs development.  (And always has been.)

All right.  I know what I find useful, and EasyPG is too limited in what
it does to be useful for general encryption.  It does a particular job
well, which is interfacing with GnuPG, but I think it's a disservice to
Emacs users to assume that GnuPG is all they need, and that they want to
install it to get encryption/decryption services.  If you disagree with
me, there's little more I can say to convince you otherwise, since this
is the essential point I'm trying to make.

RS>     The package was in Gnus, and I don't have bug reports.  I have not
RS>     advertised the library so far, except for brief notes to Gnus users.  So
RS>     I don't have a sample big enough to answer your question.

RS> In other words, there is no indication that users actually use this
RS> particular customization facility.

As I explained, I have not advertised it.  You're playing catch-22,
justifying to yourself that no one will use the library with the lack of
users before it's been advertised.  To put it in your language, there is
also no indication that users don't use encrypt.el.  The sample size is
too small.

RS> You could post a request where Gnus users will see it, asking them to
RS> let you know if they have used it.

By now they have, this thread is CCed to the Gnus mailing list.

RS>     I found a few GPL ones (just a sample list) with a simple web search:

RS>     MCrypt http://mcrypt.sourceforge.net/
RS>     AxCrypt http://www.axantum.com/AxCrypt/
RS>     ScramDisk 4 Linux http://sourceforge.net/projects/sd4l/
RS>     Several steganography tools (hide data inside an image, for example)

RS> We are miscommunicating.  I think you mean that in principle they
RS> could be useful for encryption.  Maybe they are.  But the question is
RS> whether this particular feature is useful, not whether other useful
RS> encryption programs exist.

Steganography is useful, in particular, and GnuPG doesn't support it.
Users could hide secret information, or messages for other users, or
watermarks.  This data can hide inside images or other binary data in a
public directory.  This seems obviously useful to me.  Maybe you're
considering just encryption, rather than general cryptography (of which
steganography is generally considered a part).  We could change the
package name to cipher.el or ecode.el if that makes more sense to you.

RS>     - pure Lisp ciphers for quick experimentation and sharing

RS> That seems unimportant to me.

I think cryptography is a field where experimentation is very
important.  Wouldn't you like to see Emacs become a breeding ground for
cryptography work?  I would love to see that.  GnuPG is not a good
vehicle for experimentation, since it requires C code and lots of prep
work to do even simple things (as I understand it from reading the
docs).

RS> The main use of simple obfuscation ciphers is in sending mail, and for
RS> that purpose, you cannot tell from a file name (there's none) or a
RS> buffer name (it's the same as always) whether to do it.

Obfuscation can be used for a lot more, but I don't know if that
argument is all that interesting.  Steganography is probably the more
convincing argument, since it's essentially obfuscation by
concealment, and there's plenty of interest in it.

Ted

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    It does a particular job
    well, which is interfacing with GnuPG, but I think it's a disservice to
    Emacs users to assume that GnuPG is all they need, and that they want to
    install it to get encryption/decryption services.  If you disagree with
    me, there's little more I can say to convince you otherwise, since this
    is the essential point I'm trying to make.

Evidence of users actually wanting to use that sort of extension in
Emacs would convince me very quickly.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Wed, 07 Nov 2007 02:56:07 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS>     It does a particular job
RS>     well, which is interfacing with GnuPG, but I think it's a disservice to
RS>     Emacs users to assume that GnuPG is all they need, and that they want to
RS>     install it to get encryption/decryption services.  If you disagree with
RS>     me, there's little more I can say to convince you otherwise, since this
RS>     is the essential point I'm trying to make.

RS> Evidence of users actually wanting to use that sort of extension in
RS> Emacs would convince me very quickly.

So far Stefan Monnier, Reiner Steib, and I have said this is something
we want.  Daiki Ueno is the only one to have spoken against it.
Excluding the package maintainers for each side, this is 2-0.  Any more
votes for either side?

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/7, Ted Zlatanov <tzz@lifelogs.com>:
> RS> Evidence of users actually wanting to use that sort of extension in
> RS> Emacs would convince me very quickly.
>
> So far Stefan Monnier, Reiner Steib, and I have said this is something
> we want.  Daiki Ueno is the only one to have spoken against it.
> Excluding the package maintainers for each side, this is 2-0.  Any more
> votes for either side?

They really use encrypt.el and are saying that they want to use such
sort of extension?  It seems not.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/8, Daiki Ueno <ueno@unixuser.org>:
> 2007/11/7, Ted Zlatanov <tzz@lifelogs.com>:
> > RS> Evidence of users actually wanting to use that sort of extension in
> > RS> Emacs would convince me very quickly.
> >
> > So far Stefan Monnier, Reiner Steib, and I have said this is something
> > we want.  Daiki Ueno is the only one to have spoken against it.
> > Excluding the package maintainers for each side, this is 2-0.  Any more
> > votes for either side?
>
> They really use encrypt.el and are saying that they want to use such
> sort of extension?  It seems not.

Also, I'm not against that we have at least one builtin cipher.  I
just opposed that including a crap called encrypt.el.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Thu, 8 Nov 2007 10:16:50 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote: 

DU> 2007/11/8, Daiki Ueno <ueno@unixuser.org>:
>> 2007/11/7, Ted Zlatanov <tzz@lifelogs.com>:

>> > So far Stefan Monnier, Reiner Steib, and I have said this is something
>> > we want.  Daiki Ueno is the only one to have spoken against it.
>> > Excluding the package maintainers for each side, this is 2-0.  Any more
>> > votes for either side?
>> 
>> They really use encrypt.el and are saying that they want to use such
>> sort of extension?  It seems not.

Stefan wrote:
> I think there's enough space in the Emacs world for both to coexist.

Reiner wrote:
> I think it would be useful to have at least one builtin encryption
> (without requiring external programs) in Emacs, if possible.

I'd rather get actual votes at this point than debate semantics.  So, if
anyone wants to vote for or against encrypt.el, please do (including
Stefan and Reiner, please, to remove ambiguity).  I think I have said
enough on the topic to make up everyone's mind.  I will integrate with
rijndael.el if anyone needs that.

DU> Also, I'm not against that we have at least one builtin cipher.  I
DU> just opposed that including a crap called encrypt.el.

So your vote is a no, as we've already established.  Let's move on.

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/8, Ted Zlatanov <tzz@lifelogs.com>:
> >> > So far Stefan Monnier, Reiner Steib, and I have said this is something
> >> > we want.  Daiki Ueno is the only one to have spoken against it.
> >> > Excluding the package maintainers for each side, this is 2-0.  Any more
> >> > votes for either side?
> >>
> >> They really use encrypt.el and are saying that they want to use such
> >> sort of extension?  It seems not.
>
> Stefan wrote:
> > I think there's enough space in the Emacs world for both to coexist.
>
> Reiner wrote:
> > I think it would be useful to have at least one builtin encryption
> > (without requiring external programs) in Emacs, if possible.

You apperantly misinterpreted their non-negative opinions as positive
supports of including encrypt.el.

I think their opinions are neutral.   They should be considered as 0.
Now the score is 1-2 (including you, RMS and me).  Are you alright?

> I think I have said
> enough on the topic to make up everyone's mind.  I will integrate with
> rijndael.el if anyone needs that.

I think you haven't told enough.  I asked what kind of people do you
think of your users, again and again.  You just told about your
imaginary users.

IIUC, your users must satisfy at least one of the following conditions:

(1) They have some difficulties on installing GnuPG.
(2) They are so interested in cryptography that they want to select
ciphers or rather to implement them, and want to use their ciphers
through too ristricted file-based API.

I estimate the user base to be quite few.  Otherwise we should make
GnuPG installation easier, or provide more flexible API for
user-defined ciphers, including encryption of strings and buffers as
well as files, support for public key encryption, or other many
important features that encrypt.el lacks.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Leo]

On 2007-11-08 23:11 +0000, Daiki Ueno wrote:
> I estimate the user base to be quite few.  Otherwise we should make
> GnuPG installation easier, or provide more flexible API for
> user-defined ciphers, including encryption of strings and buffers as
> well as files, support for public key encryption, or other many
> important features that encrypt.el lacks.

I agree with this.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Fri, 9 Nov 2007 08:11:00 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote: 

DU> You apperantly misinterpreted their non-negative opinions as positive
DU> supports of including encrypt.el.

DU> I think their opinions are neutral.   They should be considered as 0.
DU> Now the score is 1-2 (including you, RMS and me).  Are you alright?

As I said, I'm asking for votes from everyone, including Reiner and
Stefan, so we don't get mired in semantics.  If votes are conditional
("I'd want encrypt.el if it did X") that's fine, I can answer those
questions.

>> I think I have said enough on the topic to make up everyone's mind.
>> I will integrate with rijndael.el if anyone needs that.

DU> I think you haven't told enough.  I asked what kind of people do you
DU> think of your users, again and again.  You just told about your
DU> imaginary users.

Well, I've been supporting Emacs users for a while with various Gnus and
Emacs questions, so I have some idea of what they like.  I may be wrong,
but I am working in good faith to provide users what I think they want.
I have not advertised the library so I don't have user feedback.

DU> IIUC, your users must satisfy at least one of the following conditions:

DU> (1) They have some difficulties on installing GnuPG.
DU> (2) They are so interested in cryptography that they want to select
DU> ciphers or rather to implement them, and want to use their ciphers
DU> through too ristricted file-based API.

DU> I estimate the user base to be quite few.  

You're not exactly right.  I also want to help users who can't or won't
install GnuPG (this is common for me when I administer Unix systems; on
Windows machines users may not have permission to install it even for
themselves, etc.).  Furthermore, GnuPG is not the only encryption tool
available, so it's not fair to the users to assume (1) applies to them.

The encrypt.el API can change as needed.  The idea of a simple standard
encryption API is more important to me than the implementation.  I see
no reason why the API should not support string and buffer encryption;
if you or anyone else would like to see that in encrypt.el then let me
know.  The essentials, to me, are 

1) flexible models that can accomodate EasyPG and other libraries,
especially user-supplied ciphers and interfacing with external
steganographic tools.  I think these models should actually be
stackable, e.g. "hide and encrypt my passwords in this image."

2) easy configuration by the user (thus the file-based setup right now,
because it's familiar to Emacs users).

3) easy API for those who need to integrate it into their code (but this
should be efficient so we don't store data in memory unnecessarily, of
course)

4) non-invasive (no hidden hook action, etc.)

If you agree with these goals, great.  I apologize if they were not
clear before.

DU> Otherwise we should make GnuPG installation easier, or provide more
DU> flexible API for user-defined ciphers, including encryption of
DU> strings and buffers as well as files, support for public key
DU> encryption, or other many important features that encrypt.el lacks.

It's not clear if you are interested in working with me to improve
encrypt.el or only within EasyPG to achieve those goals.  Either way,
I'll be glad to assist you any way I can.

Ted

Re: encrypt.el in No Gnus 0.7

[Stephen J. Turnbull]

Daiki Ueno writes:

 > I estimate the user base to be quite few.

Think "insurance", not "daily use."  If an advance in cryptography
that threatens all of the usual algorithms or a major data theft based
on cracking any of them occurs, suddenly all sorts of people for whom
"pretty good privacy" used to be good enough will want more options.

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    Think "insurance", not "daily use."  If an advance in cryptography
    that threatens all of the usual algorithms or a major data theft based
    on cracking any of them occurs, suddenly all sorts of people for whom
    "pretty good privacy" used to be good enough will want more options.

In such a situation, distributing a little Lisp code so people
can use a different algorithm would be a small job.
We can do it if it is needed.

Re: encrypt.el in No Gnus 0.7

[Sascha Wilde]

Ted Zlatanov <tzz@lifelogs.com> wrote:

> I'd rather get actual votes at this point than debate semantics.  So, if
> anyone wants to vote for or against encrypt.el, please do

Then: I vote against it's inclusion.

Reasons:
- there is no clear indication that it provides useful features to
  a significant group of Emacs users
- the group of people wanting to play around with cryptographic
  algorithms is very special and probably small
- experimenting with cryptographic infrastructure (starting from
  algorithms over pass phrase management to IPC and memory management in
  cryptographic tool changes) by untrained people leads to less security
  and productive use of the results of such experiments should by no
  means be encouraged.

sascha
-- 
Sascha Wilde 
"If you were young again, would you start writing TeX again or would
you use Microsoft Word, or another word processor?" - "I hope to die
before I *have* to use Microsoft Word."    --  Prof. Donald E. Knuth

Re: encrypt.el in No Gnus 0.7

[Richard Stallman]

    Steganography is useful, in particular, and GnuPG doesn't support it.
    Users could hide secret information, or messages for other users, or
    watermarks.

Steganography is certainly useful, but the question is whether users
want to use encrypt.el.

    RS>     - pure Lisp ciphers for quick experimentation and sharing

    RS> That seems unimportant to me.

    I think cryptography is a field where experimentation is very
    important.  Wouldn't you like to see Emacs become a breeding ground for
    cryptography work?

Encryption programs generally need to be fast.
Emacs Lisp doesn't seem very good for the job.

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Wed, 07 Nov 2007 02:56:08 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS>     Steganography is useful, in particular, and GnuPG doesn't support it.
RS>     Users could hide secret information, or messages for other users, or
RS>     watermarks.

RS> Steganography is certainly useful, but the question is whether users
RS> want to use encrypt.el.

Well, it's the only library within Emacs that could support it AFAIK (I
can write a sample implementation if necessary).  Whether that's
sufficient to make it wanted by the users, I don't know, since it's
neither been advertised to the users nor does it support steganography
yet.

RS>     I think cryptography is a field where experimentation is very
RS>     important.  Wouldn't you like to see Emacs become a breeding ground for
RS>     cryptography work?

RS> Encryption programs generally need to be fast.
RS> Emacs Lisp doesn't seem very good for the job.

GnuPG uses an external library to do its job (libgcrypt as documented at
http://www.gnupg.org/(en)/documentation/manuals/gcrypt/).  We could use
that library *and others* directly from encrypt.el, providing the extra
speed.  But as I mentioned, what's important is experimentation.  Speed
is not my concern, since the Lisp code can be rewritten in C when it's
not experimental anymore.

Ted

Re: encrypt.el in No Gnus 0.7

[Reiner Steib]

On Mon, Nov 05 2007, Richard Stallman wrote:

>     RS> I just looked at encrypt.el.  It appears to support just GnuPG
>     RS> and "Built-in simple XOR".  And built-in simple XOR is just an
>     RS> example, not for real use.
>
>     The idea is to allow users to supply their own ciphers, and to
>     support other external utilities as users find it necessary.
>
> It is a sensible feature, but is it worth including in Emacs?  

Some thoughts...

I think it would be useful to have at least one builtin encryption
(without requiring external programs) in Emacs, if possible.

The cipher should be significantly better than obfuscation (ROT13) but
it doesn't need to be as GPG's ciphers.  I'm thinking of protection of
for not-too-valuable stuff like email and NNTP passwords
(e.g. passwords that are stored completely unprotected on disk by many
users up to now) against (accidentally?) exposing it to your
administrator, colleagues, family members, etc.

How strong or week are the builtin ciphers compared to e.g. the
algorithm used in Firefox/Thunderbird's password manager (I couldn't
find out which cipher the use)?  How long does it take on a "standard
PC" to break an ~/.authinfo file protected with a password of say 8
chars?

> Is there any sign that users use it?

As it was not part of any released Gnus version, so I can't be in
widespread use.

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

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Tue, 06 Nov 2007 22:11:12 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> I think it would be useful to have at least one builtin encryption
RS> (without requiring external programs) in Emacs, if possible.

RS> The cipher should be significantly better than obfuscation (ROT13) but
RS> it doesn't need to be as GPG's ciphers.  I'm thinking of protection of
RS> for not-too-valuable stuff like email and NNTP passwords
RS> (e.g. passwords that are stored completely unprotected on disk by many
RS> users up to now) against (accidentally?) exposing it to your
RS> administrator, colleagues, family members, etc.

RS> How strong or week are the builtin ciphers compared to e.g. the
RS> algorithm used in Firefox/Thunderbird's password manager (I couldn't
RS> find out which cipher the use)?  How long does it take on a "standard
RS> PC" to break an ~/.authinfo file protected with a password of say 8
RS> chars?

The XOR cipher is trivial (it would take a few seconds to a few minutes
to break it) but it's slightly better than ROT-13.  I can write
something stronger, or a steganographic cipher which might be more
interesting.  Reimplementing AES, for example, would be too slow and
unnecessary for an Lisp-based cipher.

Firefox uses a plugin-based security device, and I can't find the
default cipher it uses.  It's much stronger than XOR, though.

Ted

Re: encrypt.el in No Gnus 0.7

[Stefan Monnier]

> interesting.  Reimplementing AES, for example, would be too slow and
> unnecessary for an Lisp-based cipher.

No need to guess: look for for rijndael.el and you shall be served.


        Stefan

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Wed, 07 Nov 2007 11:12:17 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> interesting.  Reimplementing AES, for example, would be too slow and
>> unnecessary for an Lisp-based cipher.

SM> No need to guess: look for for rijndael.el and you shall be served.

I can add it as a cipher in encrypt.el, if anyone wants it.  I can make
a cipher that interfaces with http://josefsson.org/aes/rijndael.el
(which seems to be the latest version).

Ted

Re: encrypt.el in No Gnus 0.7

[Reiner Steib]

On Wed, Nov 07 2007, Ted Zlatanov wrote:

> Firefox uses a plugin-based security device, and I can't find the
> default cipher it uses.

It is part of a plain Firefox installation, see Edit / Preferences /
Security / { Change Master Password | Show Passwords }.  Maybe it
isn't called "password manager"?

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

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Wed, 07 Nov 2007 17:47:47 +0100 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Wed, Nov 07 2007, Ted Zlatanov wrote:
>> Firefox uses a plugin-based security device, and I can't find the
>> default cipher it uses.

RS> It is part of a plain Firefox installation, see Edit / Preferences /
RS> Security / { Change Master Password | Show Passwords }.  Maybe it
RS> isn't called "password manager"?

Yes, and it uses a plugin-based security device, with a "software
security device" enabled by default (and implications it could use a
hardware-based security device).  I just couldn't find the actual
encryption cipher it uses.

Ted

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Fri, 2 Nov 2007 00:24:04 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote: 

DU> 2007/11/2, Ted Zlatanov <tzz@lifelogs.com>:
>> On Thu, 1 Nov 2007 10:30:54 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote:
DU> epa-file.el in EasyPG can also do that.  Have you looked at it?
DU> I think it is much easier to use since it does not need elisp setup
DU> like encrypt-file-alist.
>> 
>> encrypt-file-alist can be set up via Customize.  It's intended as an
>> API, however, so I am not concerned about end users too much.

DU> I think encrypt-file-alist is too much custamisable since GnuPG
DU> records what cipher is used to encrypt in the PGP message.  See
DU> RFC2440.

Again, you're tightly bound to GnuPG.  Does EasyPG support arbitrary,
user-supplied ciphers?  I didn't see that ability.

DU> Yes, EasyPG does not (yet) provide a way to specify the cipher
DU> algorithm but as I mentioned above we need to specify only the first
DU> time.  Is it not enough to edit ~/.gnupg/gpg.conf or manually call the
DU> gpg command with options?

Definitely no.  Again, you're tightly bound to GnuPG.  Your README says:

"EasyPG is an all-in-one GnuPG interface for Emacs.  It has two
aspects: convenient tools which allow to use GnuPG from Emacs (EasyPG
Assistant), and a fully functional interface library to GnuPG (EasyPG
Library)."

There's nothing wrong with that, but you're entirely dependent on GnuPG
to do the encryption and decryption, so you most definitely do not
provide the same services as encrypt.el.

DU> I also think that your XOR cipher is not a good idea as a fallback
DU> algorithm.  Have you ever read Simon Singh's "The Code Book"?

It's not a fallback, it's an example implementation.  I have not read
that particular book, but I have studied encryption algorithms in
college and have used them at the API level many times since.

DU> Yes, EasyPG is a bit complex and invasive.  But IMO sometimes
DU> usability should be given priority over simplicity &
DU> non-invasiveness.
>> 
>> Sure, and that's your choice to make within the EasyPG package, which
>> has specific needs.  I think an API must be simple an non-invasive,
>> though, and encrypt.el is by those standards a better API than
>> epa-file.el or any other *crypt* package I've seen.  If I'm wrong,
>> please tell me.

DU> epa-file.el is an *application* not a *libarary* (I'm a bit tired of
DU> explanating these difference again and again...).  

Sorry, but you'll have to be patient with me.  I did not get that
distinction from the EasyPG docs, perhaps I missed it.

DU> epg.el is the library and it provides the API.  Since it only
DU> accepts string or file for encryption and do not cache passphrase,
DU> it is simpler than encrypt.el.

We're talking in circles.

What you consider simplicity is in fact reliance on an external tool,
which handles everything for you.  I think encryption and decryption
should be possible with an API, without external tools.  If we disagree
and EasyPG is the only encryption API in Emacs, then I will keep
maintaining encrypt.el in the Gnus development tree.

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/2, Ted Zlatanov <tzz@lifelogs.com>:
> DU> I think encrypt-file-alist is too much custamisable since GnuPG
> DU> records what cipher is used to encrypt in the PGP message.  See
> DU> RFC2440.
>
> Again, you're tightly bound to GnuPG.  Does EasyPG support arbitrary,
> user-supplied ciphers?  I didn't see that ability.

I doubt that the ability is worth considering.  Who wants to use
user-supplied ciphers which are appearantly weaker than ones GnuPG
supports?

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7

[Ted Zlatanov]

On Sat, 3 Nov 2007 11:49:50 +0900 "Daiki Ueno" <ueno@unixuser.org> wrote: 

DU> 2007/11/2, Ted Zlatanov <tzz@lifelogs.com>:
DU> I think encrypt-file-alist is too much custamisable since GnuPG
DU> records what cipher is used to encrypt in the PGP message.  See
DU> RFC2440.
>> 
>> Again, you're tightly bound to GnuPG.  Does EasyPG support arbitrary,
>> user-supplied ciphers?  I didn't see that ability.

DU> I doubt that the ability is worth considering.  Who wants to use
DU> user-supplied ciphers which are appearantly weaker than ones GnuPG
DU> supports?

The proper question is, why don't you let the users use the ciphers and
external utilities they want?  You are assuming that every Emacs user
will a) install GnuPG, and b) find it adequate.  Furthermore, you're
basing your "apparently weaker" argument on an example XOR
implementation I supplied to show the API, which is unfair.

Ted

Re: encrypt.el in No Gnus 0.7

[Daiki Ueno]

2007/11/5, Ted Zlatanov <tzz@lifelogs.com>:
> >> Again, you're tightly bound to GnuPG.  Does EasyPG support arbitrary,
> >> user-supplied ciphers?  I didn't see that ability.
>
> DU> I doubt that the ability is worth considering.  Who wants to use
> DU> user-supplied ciphers which are appearantly weaker than ones GnuPG
> DU> supports?
>
> The proper question is, why don't you let the users use the ciphers and
> external utilities they want?  You are assuming that every Emacs user
> will a) install GnuPG, and b) find it adequate.  Furthermore, you're
> basing your "apparently weaker" argument on an example XOR
> implementation I supplied to show the API, which is unfair.

In that case, the first thing you should do is to provide real "use
cases" of user-defined ciphers, I think.

Regards,
-- 
Daiki Ueno

Re: encrypt.el in No Gnus 0.7 (was: New Emacs facilities from Gnus)

[Richard Stallman]

There was a disagreement about password.el, but I don't remember
what the issue was.  Can someone please find that thread and tell
me the subject and date, so I can review the mail?

Re: encrypt.el in No Gnus 0.7 (was: New Emacs facilities from Gnus)

[Daiki Ueno]

2007/11/1, Richard Stallman <rms@gnu.org>:
> There was a disagreement about password.el, but I don't remember
> what the issue was.  Can someone please find that thread and tell
> me the subject and date, so I can review the mail?

Perhaps this thread:

Simon Josefsson installed password.el in net/.
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg00702.html

He made a change to read-passwd to depend on password.el.
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01049.html

You said that the change was not fit in subr.el.
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01132.html

Simon backed out the above two changes.
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01377.html

So, if this thread is appropriate one and IIUC, password.el itself was
not disagreed while it was not liked to change read-passwd to cache
passwords.

Regards,
-- 
Daiki Ueno

Re: New Emacs facilities from Gnus

[Simon Josefsson]

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

> * dns-mode.el: Already in Emacs 22 as textmodes/dns-mode.el.

But is it in Emacs 21?  I may be mistaken, but I thought Gnus was
intended to work with Emacs 21, and if dns-mode.el is removed, perhaps
it will break.

> * hashcash.el:

How about moving it to lisp/mail/?

> * hmac-def.el: From FLIM (Faithful Library about Internet Message).
>   Used for sasl-*.el.
> * hmac-md5.el: Ditto.
> * md4.el: Ditto.
> * ntlm.el: Ditto.
>
> hmac-def.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
> hmac-md5.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
> md4.el:;; Author: Taro Kawagishi <tarok@transpulse.org>
> ntlm.el:;; Author: Taro Kawagishi <tarok@transpulse.org>
...
> * sasl.el: Simple Authentication and Security Layer.  From FLIM [1].
> * sasl-cram.el:
> * sasl-digest.el:
> * sasl-ntlm.el:
>
> sasl-cram.el:;; Author: Daiki Ueno <ueno@unixuser.org>
> sasl-digest.el:;; Author: Daiki Ueno <ueno@unixuser.org>
> sasl.el:;; Author: Daiki Ueno <ueno@unixuser.org>
> sasl-ntlm.el:;; Author: Taro Kawagishi <tarok@transpulse.org>

How about lisp/net?

> * password.el:

I don't care strongly about it, but it was created as a consequence of
finding duplicated code in various places that did something similar.  I
think those code duplications are still present.

/Simon

Re: New Emacs facilities from Gnus

[Daiki Ueno]

2007/11/1, Simon Josefsson <simon@josefsson.org>:

> > * password.el:
>
> I don't care strongly about it, but it was created as a consequence of
> finding duplicated code in various places that did something similar.  I
> think those code duplications are still present.

In that case, I'd suggest that the low-level libraries which need
passphrase input should provide a callback mechanism for reading
passphrases.  For instance, though epg.el does not cache passphrase by
itself, application programmers can add their own cache mechanisms in
the caller side as they desire:

(let ((c (epg-make-context)))
  (epg-context-set-passphrase-callback
   c
   (lambda (context handback)  ...passphrase caching code...))
  (epg-encrypt-string c "test" nil))

If all the libraries support this, application programmers can put
these code in the single place, and library programmers will never be
troubled with the default behavior of passphrase caching ;-)

Regards,
-- 
Daiki Ueno

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Thu, Nov 01 2007, Simon Josefsson wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> * dns-mode.el: Already in Emacs 22 as textmodes/dns-mode.el.
>
> But is it in Emacs 21?  I may be mistaken, but I thought Gnus was
> intended to work with Emacs 21, and if dns-mode.el is removed, perhaps
> it will break.

We don't want to remove any file in the standalone Gnus
distribution/repository.  Richard's request is to install the general
purpose facilities that come from Gnus in a more suitable place,
instead of emacs/lisp/gnus/.

>> * hashcash.el:
> How about moving it to lisp/mail/?

Fine with me.

[ FLIM and SASL files ]
> How about lisp/net?

Fine with me.

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

Re: New Emacs facilities from Gnus

[Richard Stallman]

    We don't want to remove any file in the standalone Gnus
    distribution/repository.  Richard's request is to install the general
    purpose facilities that come from Gnus in a more suitable place,
    instead of emacs/lisp/gnus/.

That's part of it.  The crucial point is that Gnus developers
should stop pre-empting the decisions about what packages to install
in Emacs by putting them into Gnus.  They should raise these
questions here, and we should discuss them and decide about those
packages.

If we decide against a package, then the Gnus developers could add
code to work with it, but should not install it in Gnus.

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

    * assistant.el:

    ;;; assistant.el --- guiding users through Emacs setup
    ;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>

    Its purpose is to provide a setup assistant ("setup wizard" in some
    programs).  IIRC, this is not finished yet.

Is it finished to the point of actually being usable?

Re: New Emacs facilities from Gnus

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     ;;; assistant.el --- guiding users through Emacs setup
>     ;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>
>
>     Its purpose is to provide a setup assistant ("setup wizard" in some
>     programs).  IIRC, this is not finished yet.
>
> Is it finished to the point of actually being usable?

It has only been used for toy examples yes, so I'm not actually sure.
I'd say "no".

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

    * ecomplete.el:

    ;;; ecomplete.el --- electric completion of addresses and the like
    ;; Author: Lars Magne Ingebrigtsen <larsi

What does this mean?  How does this feature differ from, or relate to,
the various other Emacs completion facilities?

Re: New Emacs facilities from Gnus

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     ;;; ecomplete.el --- electric completion of addresses and the like
>     ;; Author: Lars Magne Ingebrigtsen <larsi
>
> What does this mean?  How does this feature differ from, or relate to,
> the various other Emacs completion facilities?

It's very different.  It does completion in a manner similar to Firefox.
That is, it displays all the possible matches for the text you've
entered in the minibuffer (ranked based on what you've used most and
most recently), and allows you to choose between these.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New Emacs facilities from Gnus

[Richard Stallman]

    It's very different.  It does completion in a manner similar to Firefox.
    That is, it displays all the possible matches for the text you've
    entered in the minibuffer (ranked based on what you've used most and
    most recently), and allows you to choose between these.

Does this have anything specifically to do with Gnus?

Re: New Emacs facilities from Gnus

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

>     It's very different.  It does completion in a manner similar to Firefox.
>     That is, it displays all the possible matches for the text you've
>     entered in the minibuffer (ranked based on what you've used most and
>     most recently), and allows you to choose between these.
>
> Does this have anything specifically to do with Gnus?

No, not really.  The only user of the package is Message (that I know
of). 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New Emacs facilities from Gnus

[Richard Stallman]

    >     It's very different.  It does completion in a manner similar to Firefox.
    >     That is, it displays all the possible matches for the text you've
    >     entered in the minibuffer (ranked based on what you've used most and
    >     most recently), and allows you to choose between these.
    >
    > Does this have anything specifically to do with Gnus?

    No, not really.  The only user of the package is Message (that I know
    of). 

It sounds like something that could be generally useful.  Does a
package have to be specially written to use this feature, or can it
apply to any and all minibuffer completion operations?

Anyway, it ought to be moved out of `lisp/gnus'.  Could you move it into
the main `lisp' directory?

ecomplete.el (was: New Emacs facilities from Gnus)

[Reiner Steib]

On Fri, Nov 16 2007, Richard Stallman wrote:

> It sounds like something that could be generally useful.  Does a
> package have to be specially written to use this feature, or can it
> apply to any and all minibuffer completion operations?

In message mode, it's used for completion of To, Cc, ... headers,
i.e. not in the minibuffer.

> Anyway, it ought to be moved out of `lisp/gnus'.  Could you move it into
> the main `lisp' directory?

I can do this next week, unless someone beats me to it.

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

Re: ecomplete.el (was: New Emacs facilities from Gnus)

[Richard Stallman]

    > It sounds like something that could be generally useful.  Does a
    > package have to be specially written to use this feature, or can it
    > apply to any and all minibuffer completion operations?

    In message mode, it's used for completion of To, Cc, ... headers,
    i.e. not in the minibuffer.

What does a program have to do to provide this kind of completion?
ecomplete.el doesn't say.  In fact, its functions have no doc strings.

    > Anyway, it ought to be moved out of `lisp/gnus'.  Could you move it into
    > the main `lisp' directory?

    I can do this next week, unless someone beats me to it.

That is the right thing to do, presuming you or someone else
supplies documentation for the package.
There is no sense keeping it anywhere in Emacs
if it has no documentation to explain how to use it.

ecomplete.el (was: New Emacs facilities from Gnus)

[Reiner Steib]

On Thu, Nov 15 2007, Simon Josefsson wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> It's very different.  It does completion in a manner similar to Firefox.
>> That is, it displays all the possible matches for the text you've
>> entered in the minibuffer (ranked based on what you've used most and
>> most recently), and allows you to choose between these.
>
> How do I use it?  I've seen that ecomplete has been used by message mode
> to auto-complete e-mail addresses for some time now, but I have no idea
> how to select one of the matches, or cycle through them.  There doesn't
> seem to be any documentation, and the source didn't do it for me.

I couldn't figure out neither how to select a match.

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

Re: ecomplete.el

[Tassilo Horn]

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

> On Thu, Nov 15 2007, Simon Josefsson wrote:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> It's very different.  It does completion in a manner similar to
>>> Firefox.  That is, it displays all the possible matches for the text
>>> you've entered in the minibuffer (ranked based on what you've used
>>> most and most recently), and allows you to choose between these.
>>
>> How do I use it?  I've seen that ecomplete has been used by message
>> mode to auto-complete e-mail addresses for some time now, but I have
>> no idea how to select one of the matches, or cycle through them.
>> There doesn't seem to be any documentation, and the source didn't do
>> it for me.
>
> I couldn't figure out neither how to select a match.

,----[ (info "(message)Mail Aliases") ]
| The `message-mail-alias-type' variable controls what type of mail alias
| expansion to use.  Currently two forms are supported: `mailabbrev' and
| `ecomplete'.  If this variable is `nil', no mail alias expansion will
| be performed.

[...]

|    If you're using `ecomplete', all addresses from `To' and `Cc'
| headers will automatically be put into the `~/.ecompleterc' file.  When
| you enter text in the `To' and `Cc' headers, `ecomplete' will check out
| the values stored there and "electrically" say what completions are
| possible.  To choose one of these completions, use the `M-n' command to
| move down to the list.  Use `M-n' and `M-p' to move down and up the
| list, and `RET' to choose a completion.
`----


Works like a charm for me.

Bye,
Tassilo

Re: ecomplete.el

[Bastien]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> I couldn't figure out neither how to select a match.
>
> ,----[ (info "(message)Mail Aliases") ]
> | The `message-mail-alias-type' variable controls what type of mail alias
> | expansion to use.  Currently two forms are supported: `mailabbrev' and
> | `ecomplete'.  If this variable is `nil', no mail alias expansion will
> | be performed.
>
> [...]
>
> |    If you're using `ecomplete', all addresses from `To' and `Cc'
> | headers will automatically be put into the `~/.ecompleterc' file.  When
> | you enter text in the `To' and `Cc' headers, `ecomplete' will check out
> | the values stored there and "electrically" say what completions are
> | possible.  To choose one of these completions, use the `M-n' command to
> | move down to the list.  Use `M-n' and `M-p' to move down and up the
> | list, and `RET' to choose a completion.
> `----
>
> Works like a charm for me.

That's actually very nice.  Thanks for the pointer Tassilo!

-- 
Bastien

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

    ;;; hashcash.el --- Add hashcash payments to email
    ;; Maintainer: Paul Foley <mycroft@actrix.gen.nz>

What does this do?  What are hashcash payments?

Will this work with sendmail.el and rmail.el?

Re: New Emacs facilities from Gnus

[Manoj Srivastava]

Hi,
On Sun, 04 Nov 2007 14:56:48 -0500, Richard Stallman <rms@gnu.org> said: 

>     ;;; hashcash.el --- Add hashcash payments to email
>     ;; Maintainer: Paul Foley <mycroft@actrix.gen.nz>

> What does this do?  What are hashcash payments?

        This is a device used for fighting Spam.  The sender creates a
 header in the outgoing mail for each recipient; this hash is
 computationally expensive to create, but easy to veryfy, asnd the
 string used as input contain the destination address and a timestamp,
 so it is not easy to reuse.

        Popular Spam prevention software like spamassassin verifies the
 hash, and if successful, scores the mail as not Spam. It also creates a
 store of hashcash numbers found to prevent replay attacks.

        So, as a sender, I have my computer spend a few seconds while
 sending out mail in return for a higher likelyhood that my email does
 not end up in the spam filter.

        The example given on the hashcash page is:
 % echo -n 0:030626:adam@cypherspace.org:6470e06d773e05a8 | sha1
 00000000c70db7389f241b8f441fcf068aead3f0

        This is a hashcash created for adam@cypherspace.org  on
 03/06/26, which has an 32-bit collision with the all 0 string.


> Will this work with sendmail.el and rmail.el?

        It does work with sendmail.el, as far as I can tell.

        manoj
http://www.hashcash.org/faq/

-- 
It's not that I'm afraid to die. I just don't want to be there when it
happens. Woody Allen
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: New Emacs facilities from Gnus

[Richard Stallman]

Is hashcash.el used for sending, then?
If so, it sounds like something worth moving into lisp/mail.

Does anyone object?

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Mon, Nov 05 2007, Richard Stallman wrote:

> Is hashcash.el used for sending, then?
> If so, it sounds like something worth moving into lisp/mail.
>
> Does anyone object?

Nobody object within 17 days, so I moved it to lisp/mail.

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

Re: New Emacs facilities from Gnus

[Richard Stallman]

Thanks for moving hashcash.el.

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Sun, Nov 04 2007, Richard Stallman wrote:

>     ;;; hashcash.el --- Add hashcash payments to email
>     ;; Maintainer: Paul Foley <mycroft@actrix.gen.nz>
>
> What does this do?  What are hashcash payments?

I have attached some explanatory text from wikipedia below (*).
In (info "(gnus)Hashcash"), there is also some information.

> Will this work with sendmail.el and rmail.el?

Probably it wouldn't be difficult to add it there (maybe in
`sendmail-send-it').

Bye, Reiner.

(*)
,----[ http://en.wikipedia.org/wiki/Hashcash ]
| Hashcash
| From Wikipedia, the free encyclopedia
| 
| Hashcash is a proof-of-work system designed to limit email spam and
| denial of service attacks. It was proposed in March 1997 by Adam
| Back [2].
| [...]
|
| How it works
| 
| Hashcash is a method of adding a textual stamp to the header of an
| email to prove the sender has expended a modest amount of CPU time
| calculating the stamp prior to sending the email. In other words, as
| the sender has taken a certain amount of time to generate the stamp
| and send the email, it is unlikely that they are a spammer. The
| receiver can, at negligible computational cost, verify that the stamp
| is valid. However, the only known way to find a header with the
| necessary properties is brute force, trying random values until the
| answer is found; though testing an individual string is easy, if
| satisfactory answers are rare enough it will require a substantial
| number of tries to find the answer.
| 
| The theory is that spammers, whose business model relies on their
| ability to send large numbers of emails with very little cost per
| message, cannot afford this investment into each individual piece of
| spam they send. Receivers can verify whether a sender made such an
| investment and use the results to help filter email.
| 
| Technical details
| 
| The header line looks something like [3]
| 
|    X-Hashcash: 1:20:060408:adam@cypherspace.org::1QTjaYd7niiQA/sc:ePa
| 
| The header contains: the recipients email address, the date, and
| information proving the required computation has been performed. The
| presence of the recipients email address forces a new header be
| computed for each recipient, the date allows the recipient to record
| headers received recently and make sure the header is unique this
| email.
|
| [...]
`----

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

    * smime-ldap.el:

    ;;; smime-ldap.el --- client interface to LDAP for Emacs
    ;; Author: Oscar Figueiredo <Oscar.Figueiredo@di.epfl.ch>

How does this differ from, or relate to, lisp/net/ldap.el?

Re: New Emacs facilities from Gnus

[Arne Jørgensen]

Richard Stallman <rms@gnu.org> writes:

>     * smime-ldap.el:
>
>     ;;; smime-ldap.el --- client interface to LDAP for Emacs
>     ;; Author: Oscar Figueiredo <Oscar.Figueiredo@di.epfl.ch>
>
> How does this differ from, or relate to, lisp/net/ldap.el?

Two things.

1) It implements Emacs 22's version of ldap-search and
   ldap-search-internal from ldap.el for use of Gnus in Emacs 21.3. The
   changes are made to achieve compatibility with OpenLDAP v2 and to
   make it possible to retrieve LDAP attributes that are tagged ie
   ";binary".

2) It adds a compatibility layer for Xemacs because the ldap-search in
   Emacs and in Xemacs returns its results differently.


Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>

Re: New Emacs facilities from Gnus

[Stefan Monnier]

>> * smime-ldap.el:
>> 
>> ;;; smime-ldap.el --- client interface to LDAP for Emacs
>> ;; Author: Oscar Figueiredo <Oscar.Figueiredo@di.epfl.ch>
>> 
>> How does this differ from, or relate to, lisp/net/ldap.el?

> Two things.

> 1) It implements Emacs 22's version of ldap-search and
>    ldap-search-internal from ldap.el for use of Gnus in Emacs 21.3. The
>    changes are made to achieve compatibility with OpenLDAP v2 and to
>    make it possible to retrieve LDAP attributes that are tagged ie
>    ";binary".

> 2) It adds a compatibility layer for Xemacs because the ldap-search in
>    Emacs and in Xemacs returns its results differently.

So it's a compatibility package?


        Stefan

Re: New Emacs facilities from Gnus

[Richard Stallman]

    > How does this differ from, or relate to, lisp/net/ldap.el?

    Two things.

These "two things" give some information, but I am still not certain
of the answer to my question.

    1) It implements Emacs 22's version of ldap-search and
       ldap-search-internal from ldap.el for use of Gnus in Emacs 21.3. The
       changes are made to achieve compatibility with OpenLDAP v2 and to
       make it possible to retrieve LDAP attributes that are tagged ie
       ";binary".

    2) It adds a compatibility layer for Xemacs because the ldap-search in
       Emacs and in Xemacs returns its results differently.

It sounds like neither of these things is useful in Emacs >= 22.
Does that mean we can simply delete smime-ldap.el from Emacs?

I don't entirely understand "adds a compatibility layer".

Re: New Emacs facilities from Gnus

[Arne Jørgensen]

Richard Stallman <rms@gnu.org> writes:

> It sounds like neither of these things is useful in Emacs >= 22.
> Does that mean we can simply delete smime-ldap.el from Emacs?

Yes. It is not useful in Emacs >= 22 and can be deleted if the patch
below is applied to smime.el.

But the patch should only be applied in Emacs CVS and not in Gnus CVS
(otherwise the stand alone Gnus will not work with Xemacs and Emacs 21).

125c125
< (require 'smime-ldap)
---
> (require 'ldap)
593,594c593,594
<   (let ((ldapresult (smime-ldap-search (concat "mail=" mail)
< 				       host '("userCertificate") nil))
---
>   (let ((ldapresult (cdr (ldap-search (concat "mail=" mail)
> 				      host '("userCertificate") nil)))


Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>

Re: New Emacs facilities from Gnus

[Richard Stallman]

    Yes. It is not useful in Emacs >= 22 and can be deleted if the patch
    below is applied to smime.el.

    But the patch should only be applied in Emacs CVS and not in Gnus CVS
    (otherwise the stand alone Gnus will not work with Xemacs and Emacs 21).

Ok, would someone please do this in the trunk, then ack?
Please also delete smime-ldap.el.

    125c125
    < (require 'smime-ldap)
    ---
    > (require 'ldap)
    593,594c593,594
    <   (let ((ldapresult (smime-ldap-search (concat "mail=" mail)
    < 				       host '("userCertificate") nil))
    ---
    >   (let ((ldapresult (cdr (ldap-search (concat "mail=" mail)
    > 				      host '("userCertificate") nil)))

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Wed, Nov 07 2007, Richard Stallman wrote:

>     Yes. It is not useful in Emacs >= 22 and can be deleted if the patch
>     below is applied to smime.el.
>
>     But the patch should only be applied in Emacs CVS and not in Gnus CVS
>     (otherwise the stand alone Gnus will not work with Xemacs and Emacs 21).
>
> Ok, would someone please do this in the trunk, then ack?
> Please also delete smime-ldap.el.
>
>     125c125
>     < (require 'smime-ldap)
>     ---
>     > (require 'ldap)
>     593,594c593,594
>     <   (let ((ldapresult (smime-ldap-search (concat "mail=" mail)
>     < 				       host '("userCertificate") nil))
>     ---
>     >   (let ((ldapresult (cdr (ldap-search (concat "mail=" mail)
>     > 				      host '("userCertificate") nil)))

Couldn't we use a test to check if the "good" version of `ldap-search'
is available so that the code in both versions (of smime.el?) stays
identical?

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

Re: New Emacs facilities from Gnus

[Stefan Monnier]

> Couldn't we use a test to check if the "good" version of `ldap-search'
> is available so that the code in both versions (of smime.el?) stays
> identical?

Maybe a simpler approach is to change (fboundp 'smime-ldap-search)?


        Stefan

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Wed, Nov 07 2007, Stefan Monnier wrote:

>> Couldn't we use a test to check if the "good" version of `ldap-search'
>> is available so that the code in both versions (of smime.el?) stays
>> identical?
>
> Maybe a simpler approach is to change (fboundp 'smime-ldap-search)?

But (require 'smime-ldap) would fail so the user would get an error.
Or am I missing something?

How about this patch (and deleting `smime-ldap.el' in Emacs)?  Cf. the
tests in `smime-ldap-search'.

--8<---------------cut here---------------start------------->8---
--- smime.el	28 Oct 2007 09:18:28 -0000	1.14
+++ smime.el	7 Nov 2007 18:01:39 -0000
@@ -122,7 +122,6 @@
 ;;; Code:
 
 (require 'dig)
-(require 'smime-ldap)
 (require 'password)
 (eval-when-compile (require 'cl))
 
@@ -590,8 +589,17 @@
 
 (defun smime-cert-by-ldap-1 (mail host)
   "Get cetificate for MAIL from the ldap server at HOST."
-  (let ((ldapresult (smime-ldap-search (concat "mail=" mail)
-				       host '("userCertificate") nil))
+  (let ((ldapresult
+	 (funcall
+	  (if (or (featurep 'xemacs)
+		  ;; For Emacs >= 22 we don't need smime-ldap.el
+		  (>= emacs-major-version 22))
+	      (progn
+		(require 'smime-ldap)
+		'smime-ldap-search)
+	    'ldap-search)
+	  (concat "mail=" mail)
+	  host '("userCertificate") nil))
 	(retbuf (generate-new-buffer (format "*certificate for %s*" mail)))
 	cert)
     (if (and (>= (length ldapresult) 1)

--8<---------------cut here---------------end--------------->8---

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

Re: New Emacs facilities from Gnus

[Stefan Monnier]

> +	  (if (or (featurep 'xemacs)
> +		  ;; For Emacs >= 22 we don't need smime-ldap.el
> +		  (>= emacs-major-version 22))
> +	      (progn
> +		(require 'smime-ldap)
> +		'smime-ldap-search)
> +	    'ldap-search)
> +	  (concat "mail=" mail)
> +	  host '("userCertificate") nil))

Those kinds of test qualify as "yucky" in my book.
I'd rather do

(ignore-errors (require 'smime-ldap)) and then (fboundp 'smime-ldap-search).


        Stefan

Re: New Emacs facilities from Gnus

[Sascha Wilde]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> +	  (if (or (featurep 'xemacs)
>> +		  ;; For Emacs >= 22 we don't need smime-ldap.el
>> +		  (>= emacs-major-version 22))
>> +	      (progn
>> +		(require 'smime-ldap)
[...]
> Those kinds of test qualify as "yucky" in my book.
> I'd rather do
>
> (ignore-errors (require 'smime-ldap)) and then (fboundp 'smime-ldap-search).

Emacs 22 require has an optional argument NOERROR, so 
(require 'smime-ldap nil t) 
would be safe (and one can use the return value).  But I don't know if
it is portable...

cheers
sascha
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Fri, Nov 09 2007, Sascha Wilde wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> +	  (if (or (featurep 'xemacs)
>>> +		  ;; For Emacs >= 22 we don't need smime-ldap.el
>>> +		  (>= emacs-major-version 22))

Correction:
                  (< emacs-major-version 22)

>>> +	      (progn
>>> +		(require 'smime-ldap)
> [...]
>> Those kinds of test qualify as "yucky" in my book.

I guess you mean the version check?  Yes, I don't like it, but I can't
think of a better test in this case.

>> I'd rather do
>>
>> (ignore-errors (require 'smime-ldap)) 

This would unnecessarily load and use smime-ldap in Emacs 22+
e.g. when using the standalone Gnus distribution (or if smime-ldap.el
is present in load-path).

>> and then (fboundp 'smime-ldap-search).

> Emacs 22 require has an optional argument NOERROR, so 
> (require 'smime-ldap nil t) 
> would be safe (and one can use the return value).  But I don't know if
> it is portable...

XEmacs 21.4 doesn't have it, IIRC.

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

Re: New Emacs facilities from Gnus

[Reiner Steib]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 700 bytes --]

On Fri, Nov 09 2007, Reiner Steib wrote:

>> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> +	  (if (or (featurep 'xemacs)
>>>> +		  ;; For Emacs >= 22 we don't need smime-ldap.el
>>>> +		  (>= emacs-major-version 22))
>
> Correction:
> ^[.A^[N                  (< emacs-major-version 22)
>
>>>> +	      (progn
>>>> +		(require 'smime-ldap)
>>> Those kinds of test qualify as "yucky" in my book.
>
> I guess you mean the version check?  Yes, I don't like it, but I can't
> think of a better test in this case.

I have removed `smime-ldap.el' in Emacs trunk and installed my patch.

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

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[CHENG Gao]

*On Mon, 29 Oct 2007 08:49:10 +0100
* Also spracht Reiner Steib <reinersteib+gmane@imap.cc>:

> There are some other non-Gnus specific files which should probably be
> moved from lisp/gnus/ to other directories. [1]
>
> I'll provide a list of new files with some comments. If you need to know
> more about these files, I'd suggest to make a _separate_ reply and cc the
> author or maintainer.
>
> * assistant.el:
>
> ;;; assistant.el --- guiding users through Emacs setup ;; Author: Lars
> Magne Ingebrigtsen <larsi@gnus.org>
>
> Its purpose is to provide a setup assistant ("setup wizard" in some
> programs). IIRC, this is not finished yet.
>
> See etc/gnus/*.ast for some prototype assistant files.
>
> * dns-mode.el: Already in Emacs 22 as textmodes/dns-mode.el.
>
> * ecomplete.el:
>
> ;;; ecomplete.el --- electric completion of addresses and the like ;;
> Author: Lars Magne Ingebrigtsen <larsi
>
> * encrypt.el:
>
> ;;; encrypt.el --- file encryption routines ;; Author: Teodor Zlatanov
> <tzz@lifelogs.com>
>
> * gnus-bookmark.el: Gnus specific.
>
> * hashcash.el:
>
> ;;; hashcash.el --- Add hashcash payments to email ;; Maintainer: Paul
> Foley <mycroft@actrix.gen.nz>
>
> * hmac-def.el: From FLIM (Faithful Library about Internet Message). Used
> for sasl-*.el. * hmac-md5.el: Ditto. * md4.el: Ditto. * ntlm.el: Ditto.
>
> hmac-def.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
> hmac-md5.el:;; Author: Shuhei KOBAYASHI <shuhei@aqua.ocn.ne.jp>
> md4.el:;; Author: Taro Kawagishi <tarok@transpulse.org> ntlm.el:;;
> Author: Taro Kawagishi <tarok@transpulse.org>
>
> * password.el:
>
> ;;; password.el --- Read passwords from user, possibly using a password
> cache. ;; Author: Simon Josefsson <simon@josefsson.org>
>
> ,----[ doc/misc/gnus-news.el ]
> | @item Gnus includes a password cache mechanism in password.el.
> | 
> | It is enabled by default (see @code{password-cache}), with a short
> | timeout of 16 seconds (see @code{password-cache-expiry}). If
> | @acronym{PGG} is used as the @acronym{PGP} back end, the @acronym{PGP}
> | passphrase is managed by this mechanism. Passwords for ManageSieve
> | connections are managed by this mechanism, after querying the user
> | about whether to do so.
> `----
>
> * sasl.el: Simple Authentication and Security Layer. From FLIM [1]. *
> sasl-cram.el: * sasl-digest.el: * sasl-ntlm.el:
>
> sasl-cram.el:;; Author: Daiki Ueno <ueno@unixuser.org> sasl-digest.el:;;
> Author: Daiki Ueno <ueno@unixuser.org> sasl.el:;; Author: Daiki Ueno
> <ueno@unixuser.org> sasl-ntlm.el:;; Author: Taro Kawagishi
> <tarok@transpulse.org>
>
> ,----[ doc/misc/gnus-news.el ]
> | @item Gnus includes the Emacs Lisp @acronym{SASL} library.
> | 
> | This provides a clean @acronym{API} to @acronym{SASL} mechanisms from
> | within Emacs. The user visible aspects of this, compared to the
> | earlier situation, include support for @acronym{DIGEST}-@acronym{MD5}
> | and @acronym{NTLM}. @xref{Top, ,Emacs SASL, sasl, Emacs SASL}.
> `----
>
> * smime-ldap.el:
>
> ;;; smime-ldap.el --- client interface to LDAP for Emacs ;; Author:
> Oscar Figueiredo <Oscar.Figueiredo@di.epfl.ch>
>
> * spam-wash.el: Gnus specific.
>
> Bye, Reiner.

How about the following files:
binhex.el, dig.el, dns.el, m4.el, sha1.el, uudecode.el, utf7.el, yenc.el

And there are tls.el and starttls.el. tls.el is already in Emacs. I
wonder why starttls.el exists along with tls.el. Why not merge them?

-- 
Homo sum, humani being nil a me alienum puto

Re: New Emacs facilities from Gnus

[Reiner Steib]

On Tue, Nov 06 2007, CHENG Gao wrote:

> How about the following files:

This thread was about new files from No Gnus.  The files from your
list have already been included in several years ago.  Maybe they have
already been discussed.  Did you check the list archives
(emacs-devel)?

> binhex.el, 

to lisp/mail?

> dig.el, dns.el, sha1.el, uudecode.el,

maybe to lisp/net?

> m4.el, 

I can't find any file m4.el.

> utf7.el,

See the recent thread in emacs-devel:
<http://thread.gmane.org/gmane.emacs.devel/82303>

> yenc.el

Only useful for news, not for mail, AFAIK.

> And there are tls.el and starttls.el. tls.el is already in Emacs. I
> wonder why starttls.el exists along with tls.el. Why not merge them?

I'd guess that `tls.el' is much more general than `starttls.el'.  The
latter is for IMAP, POP, etc.  But Daiki Ueno or Simon surely can
explain better.  `starttls.el' could be move to the mail directory.

;;; tls.el --- TLS/SSL support via wrapper around GnuTLS
;; This package implements a simple wrapper around "gnutls-cli" to
;; make Emacs support TLS/SSL.

;;; starttls.el --- STARTTLS functions
;; This module defines some utility functions for STARTTLS profiles.
;; [RFC 2595] "Using TLS with IMAP, POP3 and ACAP"
;;      by Chris Newman <chris.newman@innosoft.com> (1999/06)
;; This file now contains a combination of the two previous
;; implementations both called "starttls.el".  The first one is Daiki
;; Ueno's starttls.el which uses his own "starttls" command line tool,
;; and the second one is Simon Josefsson's starttls.el which uses
;; "gnutls-cli" from GNUTLS.

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

Re: New Emacs facilities from Gnus

[CHENG Gao]

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

> On Tue, Nov 06 2007, CHENG Gao wrote:
>
>> How about the following files:
>
> This thread was about new files from No Gnus. The files from your list have already been included in
> several years ago. Maybe they have already been discussed. Did you check the list archives
> (emacs-devel)?
Sorry I dont this. Yes I read it through gmane.emacs.devel but not very
old postings. I just found there are many files not specific to Gnus and
think they can be moved to Emacs as general purpose utils.

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

    How about the following files:
    binhex.el, dig.el, dns.el, m4.el, sha1.el, uudecode.el, utf7.el, yenc.el

Could you describe what these files do?

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

[I sent this message a week ago but did not get a response.
Could we get the discussion moving again?]

    * assistant.el:

    ;;; assistant.el --- guiding users through Emacs setup
    ;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>

    Its purpose is to provide a setup assistant ("setup wizard" in some
    programs).  IIRC, this is not finished yet.

Is it finished to the point of actually being usable?

Re: New Emacs facilities from Gnus

[Ted Zlatanov]

On Sun, 11 Nov 2007 18:53:57 -0500 Richard Stallman <rms@gnu.org> wrote: 

RS> [I sent this message a week ago but did not get a response.
RS> Could we get the discussion moving again?]

RS>     * assistant.el:

RS>     ;;; assistant.el --- guiding users through Emacs setup
RS>     ;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>

RS>     Its purpose is to provide a setup assistant ("setup wizard" in some
RS>     programs).  IIRC, this is not finished yet.

RS> Is it finished to the point of actually being usable?

Not AFAIK.

Ted

Re: New Emacs facilities from Gnus

[Richard Stallman]

    RS>     * assistant.el:

    RS>     ;;; assistant.el --- guiding users through Emacs setup
    RS>     ;; Author: Lars Magne Ingebrigtsen <larsi@gnus.org>

    RS>     Its purpose is to provide a setup assistant ("setup wizard" in some
    RS>     programs).  IIRC, this is not finished yet.

    RS> Is it finished to the point of actually being usable?

    Not AFAIK.

Does anyone disagree?


When finished, will this be specific for Gnus, or a general Emacs facility?

Re: New Emacs facilities from Gnus (was: Gnus in Emacs is updated to No Gnus 0.7)

[Richard Stallman]

[I sent this message a week ago but did not get a response.
Could we get the discussion moving again?]

    * ecomplete.el:

    ;;; ecomplete.el --- electric completion of addresses and the like
    ;; Author: Lars Magne Ingebrigtsen <larsi

What does this mean?  How does this feature differ from, or relate to,
the various other Emacs completion facilities?

Re: Gnus in Emacs is updated to No Gnus 0.7

[Reiner Steib]

On Sun, Oct 28 2007, Miles Bader wrote:

> [If anybody wants a big patch file containing the entire changeset, I
> can send one.]

Could you make put it somewhere on fencepost?

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

Re: Gnus in Emacs is updated to No Gnus 0.7

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> [If anybody wants a big patch file containing the entire changeset, I
>> can send one.]
>
> Could you make put it somewhere on fencepost?

Hi,

There's a patch on fencepost in:

   /home/m/miles/src/emacs/emacs-no-gnus-merge.patch

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.