Moving files from lisp/gnus/ to lisp/net/?

Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

People seem to fear using some files in gnus/ because they think the
files might end up loading all of Gnus.  I believe moving some of the
self contained files in Gnus elsewhere would be good.  This would make
it clear that they aren't an intrinsic part of Gnus.  Not only would
it make it clear for elisp programmers, it would make it clear for us
working on Gnus.  I.e., to make sure we don't use Gnus functions in
some of the files.  I just modified pop3.el to revert one such
example.  It would be bad if many standalone files ended up loading
Gnus out of pure laziness.

Do you agree with the above?  I'd be happy to explain and discuss it
further, if someone disagree.

I propose to move the following files:

lisp/gnus/:
binhex.el
dig.el
hex-util.el
rfc2104.el
pgg-def.el
pgg.el
pgg-gpg.el
pgg-parse.el
pgg-pgp5.el
pgg-pgp.el
pop3.el
sha1.el
sieve.el
sieve-manage.el
sieve-mode.el
starttls.el

into lisp/mail (for pgg*.el, maybe binhex.el) or lisp/net/ (everything
else).

Btw, should I do cvs remove + add, or should someone with repository
access do it?  Moving in the repository is typically bad (it break
historic CVS branches), but I don't know what the tradition here is.

FYI, the small files should be pretty self explanatory, but pgg*.el is
an elisp library for talking to PGP implementations (such as GnuPG).
sieve*.el is a elisp package for talking too ManageSieve servers.

I think it would be particularly bad if people avoided using pgg*.el
or sieve*.el because they think they are strongly connected with Gnus;
they are not.

None of these files use any Gnus functions.

I also propose to add password.el, encrypt.el from Gnus CVS, and
update the netrc.el file to use encrypt.el.  This may be more
controversial, so I'll post encrypt.el in a separate message, to ask
for guidance.

If there is no (major) negative response, I can do the above when I
get back from vacation in a week.  (Of course, someone else could do
it meanwhile...)

Thanks.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

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

Simon Josefsson <jas@extundo.com> writes:

> I also propose to add password.el, encrypt.el from Gnus CVS, and
> update the netrc.el file to use encrypt.el.  This may be more
> controversial, so I'll post encrypt.el in a separate message, to ask
> for guidance.

I didn't realize Ted already posted encrypt.el, so let's move that
discussion to that thread.

Meanwhile, I have installed password.el to lisp/net/, included below.
It is generally useful, and will be used by Gnus in several places
(e.g., sieve*.el).  There may be other places in Emacs that has use
for it as well (telnet? ftp?).

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

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Fri, Oct 15, 2004 at 09:37:01PM +0200, Simon Josefsson wrote:
> > I also propose to add password.el, encrypt.el from Gnus CVS, and
> > update the netrc.el file to use encrypt.el.  This may be more
> > controversial, so I'll post encrypt.el in a separate message, to ask
> > for guidance.
> 
> I didn't realize Ted already posted encrypt.el, so let's move that
> discussion to that thread.

BTW, the Gnus CVS trunk now contains both "encrypt.el" and "gnus-encrypt.el",
which are exactly the same except that the latter uses "gnus-" prefixes for
everything (and has a big commented-out section).

Can't you just delete gnus-encrypt.el?

Thanks,

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

On Fri, 15 Oct 2004, miles@gnu.org wrote:

On Fri, Oct 15, 2004 at 09:37:01PM +0200, Simon Josefsson wrote:
>> > I also propose to add password.el, encrypt.el from Gnus CVS, and
>> > update the netrc.el file to use encrypt.el.  This may be more
>> > controversial, so I'll post encrypt.el in a separate message, to ask
>> > for guidance.
>> 
>> I didn't realize Ted already posted encrypt.el, so let's move that
>> discussion to that thread.
> 
> BTW, the Gnus CVS trunk now contains both "encrypt.el" and "gnus-encrypt.el",
> which are exactly the same except that the latter uses "gnus-" prefixes for
> everything (and has a big commented-out section).
> 
> Can't you just delete gnus-encrypt.el?

Yes, I wanted to give the users a chance to use the old
gnus-encrypt.el in case they have encrypted data.  I just did the
gnus-encrypt.el -> encrypt.el rename today and posted a note to the
Gnus mailing list; my intention was to remove gnus-encrypt.el in a
week.

Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    Meanwhile, I have installed password.el to lisp/net/, included below.

To move a file out of Gnus is not a trivial decision, so
please don't move them before they have been discussed here.

I don't see any password.el in Gnus; is that something you are
moving or something you wrote just now?

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

>     Meanwhile, I have installed password.el to lisp/net/, included below.
>
> To move a file out of Gnus is not a trivial decision, so
> please don't move them before they have been discussed here.

Right.

> I don't see any password.el in Gnus; is that something you are
> moving or something you wrote just now?

It is new.  It will be used by future versions of Gnus, but it is
generally useful.  I think it is better if future network related packages
used it, instead of writing its own similar code (which is what is done
today, I think).

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    It is new.  It will be used by future versions of Gnus, but it is
    generally useful.  I think it is better if future network related packages
    used it, instead of writing its own similar code (which is what is done
    today, I think).

I agree it is useful.  Would you please document it in etc/NEWS and
in the manual?  Every feature installed now need to be documented
immediately.

Should read-passwd be integrated with this new file?

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     It is new.  It will be used by future versions of Gnus, but it is
>     generally useful.  I think it is better if future network related packages
>     used it, instead of writing its own similar code (which is what is done
>     today, I think).
>
> I agree it is useful.  Would you please document it in etc/NEWS 

Done.

> and in the manual?

The "Reading a Password" node in lispref seem to be a good place.  Do
you agree?

> Should read-passwd be integrated with this new file?

Yes, I think that would make sense, assuming that a shorter subr.el is
better.  Unless someone objects, I'll move it.

Btw, what was the reason for renaming read-password to read-passwd?
It seems the earlier name was more consistent with the coding style.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    Yes, I think that would make sense, assuming that a shorter subr.el is
    better.

We should not change subr.el to make it shorter, nor to make it
longer.  That is not the criterion.

We put things in subr.el either because they are too small to want
separate files of their own, or because they are used often enough to
be worth preloading.

I would think that the current definition of read-passwd fits the
first criterion but not the second.  The new definition, depending on
password.el, I think doesn't fit either one; it may as well be
autoloaded from the new file.

I do not remember the reason for the change of name, but maybe
it was for compatibility with something.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> I would think that the current definition of read-passwd fits the
> first criterion but not the second.  The new definition, depending on
> password.el, I think doesn't fit either one; it may as well be
> autoloaded from the new file.

I agree, thanks for explaining.  I have installed an updated node on
the password cache interface, in lispref/minibuf.texi.  Complete text
below.  I'm not a native speaker, so please review and improve it.

20.9 Reading a Password
=======================

To read a password to pass to another program, you can use the function
`read-passwd'.

   Passwords are sometimes needed several times throughout an Emacs
session.  Then it can be useful to avoid having to ask for a password
more than once.  Passwords are entered into the password cache using
the function `password-cache-add'.  To read a password, possibly
retrieving the password from the cache without querying the user, you
can use the function `password-read'.  The two calls can be combined
into the function `password-read-and-add' that read a password and
store it in the cache.

   Typically users do not use the same password for all services.  The
password cache mechanism use a `key' string to differentiate among the
passwords.  The `key' string is typically a fixed string chosen to be
related to what the password is used for.  For example, a password used
when connecting to a IMAP mail server called `mail.example.org', could
use a `key' string of `imap:mail.example.org'.  You can use any string,
as long as it is reasonably unique.

   Passwords in the cache typically expire after a while (controlled by
the variable `password-cache-expiry'), but you can force removal of a
password using the function `password-cache-remove'.  This is useful
when there is a problem with the password, to avoid using the same
incorrect password from the cache in the future.

 -- Function: read-passwd prompt &optional confirm default
     This function reads a password, prompting with PROMPT.  It does
     not echo the password as the user types it; instead, it echoes `.'
     for each character in the password.

     The optional argument CONFIRM, if non-`nil', says to read the
     password twice and insist it must be the same both times.  If it
     isn't the same, the user has to type it over and over until the
     last two times match.

     The optional argument DEFAULT specifies the default password to
     return if the user enters empty input.  If DEFAULT is `nil', then
     `read-passwd' returns the null string in that case.

 -- Function: password-read prompt key
     Read a password from the user, using `read-passwd', prompting with
     PROMPT.  If a password has been stored in the password cache,
     using `password-cache-add' on the same KEY, it is returned
     directly, without querying the user.

 -- Function: password-cache-add key password
     Add a password to the password cache, indexed under the given KEY.
     The password is later retrieved using `password-read' called with
     the same KEY.

 -- Function: password-cache-remove key
     Remove a password from the cache, indexed under the given KEY.

 -- Function: password-read-and-add prompt &optional key
     Read a password, prompting with PROMPT, and possibly add it to the
     cache, indexed using the KEY string.  This is one-call interface
     to `password-read' and `password-cache-add'.

 -- Variable: password-cache-expiry
     This variable specify for how many seconds passwords are retained
     in the password cache before they are expired.  For high security,
     use a low value (below a minute).  For more lax security, use a
     setting of `14400' corresponding to half a work day (4 hours).

 -- Variable: password-cache
     This variable toggle whether or not the password cache is used at
     all.  The default is non-`nil', i.e., to use the cache.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

It occurs to me that paranoid people might be worried about saving
passwords in a cache like this.  What do people know about that issue?

The text added to the manual is clear enough.  I have some issues
about the substance:

     -- Function: read-passwd prompt &optional confirm default
	 This function reads a password, prompting with PROMPT.  It does
	 not echo the password as the user types it; instead, it echoes `.'
	 for each character in the password.

This ought to use the cache now, but the text does not say so.

(Later): It looks like all you did was move read-passwd into
password.el without changing it.  What I suggested was to integrate
read-passwd into this file--which means, make it use the cache.

There is no sense in moving read-passwd into the new file without
making it use the new file's facilities.  That change only causes
password.el to be loaded for programs that don't use the cache.
It provides no benefit.

So if its definition is to remain unchanged, it should stay in subr.el
where it is preloaded.  But I would rather see it move to password.el
and *take advantage of the facilities of password.el*.

Can this be done?

     -- Function: password-read prompt key
	 Read a password from the user, using `read-passwd', prompting with
	 PROMPT.  If a password has been stored in the password cache,
	 using `password-cache-add' on the same KEY, it is returned
	 directly, without querying the user.

Once read-passwd uses the cache, won't password-read be obsolete?

Why have both password-read and password-read-and-add?
Why not always add?  Is the idea that for some purposes
it is ok to cache, but for others it is too risky?

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> It occurs to me that paranoid people might be worried about saving
> passwords in a cache like this.  What do people know about that issue?

Yes, that is a valid concern.  That was one reason I didn't think of
changing the existing read-passwd interface.

Other applications typically ask the user whether they want to
remember the password in memory.  If read-passwd is changed to cache
passwords (however, to use the cache, callers of read-passwd must be
updated, to provide the "key" into the hash table), it could ask the
user this.  Opinions on this welcome.

> The text added to the manual is clear enough.  I have some issues
> about the substance:
>
>      -- Function: read-passwd prompt &optional confirm default
> 	 This function reads a password, prompting with PROMPT.  It does
> 	 not echo the password as the user types it; instead, it echoes `.'
> 	 for each character in the password.
>
> This ought to use the cache now, but the text does not say so.
>
> (Later): It looks like all you did was move read-passwd into
> password.el without changing it.  What I suggested was to integrate
> read-passwd into this file--which means, make it use the cache.

Sorry, I did not get this at first.

> So if its definition is to remain unchanged, it should stay in subr.el
> where it is preloaded.  But I would rather see it move to password.el
> and *take advantage of the facilities of password.el*.
>
> Can this be done?

Yes.  I'll work on it.

>      -- Function: password-read prompt key
> 	 Read a password from the user, using `read-passwd', prompting with
> 	 PROMPT.  If a password has been stored in the password cache,
> 	 using `password-cache-add' on the same KEY, it is returned
> 	 directly, without querying the user.
>
> Once read-passwd uses the cache, won't password-read be obsolete?

Yes.

> Why have both password-read and password-read-and-add?
> Why not always add?  Is the idea that for some purposes
> it is ok to cache, but for others it is too risky?

No, the reason was this: if the user entered an incorrect password, it
should not be cached.  If an incorrect password is cached, the code
might infloop trying the incorrect password automatically over and
over again.  It was considered safer to first read the password, then
try to use it, and if successful then it is cached.

I'm not sure my argument is good, it may be simpler to always cache,
and have the calling code invoke password-cache-remove whenever there
is a password failure.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    Other applications typically ask the user whether they want to
    remember the password in memory.  If read-passwd is changed to cache
    passwords (however, to use the cache, callers of read-passwd must be
    updated, to provide the "key" into the hash table), it could ask the
    user this.  Opinions on this welcome.

Having it always ask would be too annoying, I think.  So that would
need to be a new argument, which means the feature is no benefit
unless we change the callers.

That is the wrong thing to do at present.  So I think we should put
read-passwd back where it was and remove the new file for now.

Looking ahead to the future,

    > Why have both password-read and password-read-and-add?
    > Why not always add?  Is the idea that for some purposes
    > it is ok to cache, but for others it is too risky?

    No, the reason was this: if the user entered an incorrect password, it
    should not be cached.  If an incorrect password is cached, the code
    might infloop trying the incorrect password automatically over and
    over again.  It was considered safer to first read the password, then
    try to use it, and if successful then it is cached.

In that case, password-read-and-add makes no sense, right?
Why add a shortcut that in best practice should not be used?

    I'm not sure my argument is good, it may be simpler to always cache,
    and have the calling code invoke password-cache-remove whenever there
    is a password failure.

That is a reasonable alternative, I guess, but then password-read
should add the password and we should not have password-read-and-add
as a separate entry point.

But it doesn't make sense to discuss this without dealing with the
question of whether caching of correct passwords is desirable.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     Other applications typically ask the user whether they want to
>     remember the password in memory.  If read-passwd is changed to cache
>     passwords (however, to use the cache, callers of read-passwd must be
>     updated, to provide the "key" into the hash table), it could ask the
>     user this.  Opinions on this welcome.
>
> Having it always ask would be too annoying, I think.  So that would
> need to be a new argument, which means the feature is no benefit
> unless we change the callers.
>
> That is the wrong thing to do at present.  So I think we should put
> read-passwd back where it was and remove the new file for now.

I agree, password.el was only something that might go in when we
aren't in a feature freeze.  I have backed out the change.

Since password.el will be used by Gnus CVS, our discussion haven't
been in vain, though, since I will incorporate some of the ideas
discussed here.

> Looking ahead to the future,
>
>     > Why have both password-read and password-read-and-add?
>     > Why not always add?  Is the idea that for some purposes
>     > it is ok to cache, but for others it is too risky?
>
>     No, the reason was this: if the user entered an incorrect password, it
>     should not be cached.  If an incorrect password is cached, the code
>     might infloop trying the incorrect password automatically over and
>     over again.  It was considered safer to first read the password, then
>     try to use it, and if successful then it is cached.
>
> In that case, password-read-and-add makes no sense, right?
> Why add a shortcut that in best practice should not be used?

It was added later on, not by me.  I suppose he who added it might
argue that it is useful, though.  I tend to think that there should
only be one worked out interface.  (I'm not saying the current API,
without p-r-a-a is the best interface, only that it would be better
with only one interface.)

>     I'm not sure my argument is good, it may be simpler to always cache,
>     and have the calling code invoke password-cache-remove whenever there
>     is a password failure.
>
> That is a reasonable alternative, I guess, but then password-read
> should add the password and we should not have password-read-and-add
> as a separate entry point.

I think so too.

> But it doesn't make sense to discuss this without dealing with the
> question of whether caching of correct passwords is desirable.

Perhaps the experience with how password.el is used in Gnus CVS will
help in sorting things out.

Thanks.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

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

> It was added later on, not by me.  I suppose he who added it might
> argue that it is useful, though.  I tend to think that there should
> only be one worked out interface.  (I'm not saying the current API,
> without p-r-a-a is the best interface, only that it would be better
> with only one interface.)

I added it for the purpose of decrypting a file, which is a one-shot
deal.  If it fails, it fails - you don't try to reopen the file as you
would a network connection, and you don't necessarily know that it
failed (for example, the encrypt.el XOR cipher produces garbage with a
bad password but otherwise there's no indication that there was an
error).  The only problem is that the password is then memorized, so
if it was bad it will stay around.

Either I should add an option to ask y/n if the decryption was OK
after the first time a password is entered, or I will give the user a
way to clear a bad password.  Any other suggestions are welcome.
Please note again that we don't necessarily know the decryption
failed.  Maybe we should not memorize encryption passwords at all?
That would be tedious, though, if you encrypt a lot of files with the
same cipher...

Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 29 Oct 2004, jas@extundo.com wrote:
>
>> It was added later on, not by me.  I suppose he who added it might
>> argue that it is useful, though.  I tend to think that there should
>> only be one worked out interface.  (I'm not saying the current API,
>> without p-r-a-a is the best interface, only that it would be better
>> with only one interface.)
>
> I added it for the purpose of decrypting a file, which is a one-shot
> deal.  If it fails, it fails - you don't try to reopen the file as you
> would a network connection, and you don't necessarily know that it
> failed (for example, the encrypt.el XOR cipher produces garbage with a
> bad password but otherwise there's no indication that there was an
> error).  The only problem is that the password is then memorized, so
> if it was bad it will stay around.
>
> Either I should add an option to ask y/n if the decryption was OK
> after the first time a password is entered, or I will give the user a
> way to clear a bad password.  Any other suggestions are welcome.
> Please note again that we don't necessarily know the decryption
> failed.  Maybe we should not memorize encryption passwords at all?
> That would be tedious, though, if you encrypt a lot of files with the
> same cipher...

I understand the problem.  One solution is to simply not use
encryption methods that doesn't provide integrity?  Then the
decryption process would know if the password worked or not.  I
believe that, in general, encryption mechanisms that do not offer
integrity protection are questionable.  The XOR key derivation from
password seem a bit fragile, too.  On the other hand, I realize that
only using GnuPG may create more work for the user.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

On Mon, 01 Nov 2004, jas@extundo.com wrote:

> I understand the problem.  One solution is to simply not use
> encryption methods that doesn't provide integrity?  Then the
> decryption process would know if the password worked or not.

We could do that, but I think it would be a loss to the users.

> I believe that, in general, encryption mechanisms that do not offer
> integrity protection are questionable.  The XOR key derivation from
> password seem a bit fragile, too.  On the other hand, I realize that
> only using GnuPG may create more work for the user.

There are many reasons why the XOR cipher is desirable - not the least
of which is that it depends on nothing and is very fast.  Encryption
is just a deterrent, like any other kind of data security, so it makes
sense to have something trivial in addition to the real methods like
GnuPG.

You are right, however, that GnuPG can indicate that decryption
failed.  So maybe some ciphers should have the property :fail-aware
and the code will do the passwords accordingly.  Do you think this is
the right approach?

Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

> There are many reasons why the XOR cipher is desirable - not the least
> of which is that it depends on nothing and is very fast.  Encryption
> is just a deterrent, like any other kind of data security, so it makes
> sense to have something trivial in addition to the real methods like
> GnuPG.

While I can agree that we shouldn't rule them out, such cyphers should not
constrain the interface too much, because they are not the important case.

> You are right, however, that GnuPG can indicate that decryption
> failed.  So maybe some ciphers should have the property :fail-aware
> and the code will do the passwords accordingly.  Do you think this is
> the right approach?

I'd rather assume they *all* are fail-aware, and for those rare which
aren't, just make them always say "success".

The XOR cypher might be great because it's fast and depends on nothing but
it provides really lousy security in most cases (tho better than ROT13), so
we shouldn't worry too much whether the support for XOR is optimal or not.
OTOH good support for GnuPG is important because it's a tool that's much
more used and practically useful.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

Here's what I said about read-passwd and password.el in 2004.  Setting
aside what I said about the short term, the main issue seems to be
whether to cache passwords.

Simon, what do you think about this now?
What do others think?


First message:

It occurs to me that paranoid people might be worried about saving
passwords in a cache like this.  What do people know about that issue?

The text added to the manual is clear enough.  I have some issues
about the substance:

     -- Function: read-passwd prompt &optional confirm default
	 This function reads a password, prompting with PROMPT.  It does
	 not echo the password as the user types it; instead, it echoes `.'
	 for each character in the password.

This ought to use the cache now, but the text does not say so.

(Later): It looks like all you did was move read-passwd into
password.el without changing it.  What I suggested was to integrate
read-passwd into this file--which means, make it use the cache.

There is no sense in moving read-passwd into the new file without
making it use the new file's facilities.  That change only causes
password.el to be loaded for programs that don't use the cache.
It provides no benefit.

So if its definition is to remain unchanged, it should stay in subr.el
where it is preloaded.  But I would rather see it move to password.el
and *take advantage of the facilities of password.el*.

Can this be done?

     -- Function: password-read prompt key
	 Read a password from the user, using `read-passwd', prompting with
	 PROMPT.  If a password has been stored in the password cache,
	 using `password-cache-add' on the same KEY, it is returned
	 directly, without querying the user.

Once read-passwd uses the cache, won't password-read be obsolete?

Why have both password-read and password-read-and-add?
Why not always add?  Is the idea that for some purposes
it is ok to cache, but for others it is too risky?


Second message:

    Other applications typically ask the user whether they want to
    remember the password in memory.  If read-passwd is changed to cache
    passwords (however, to use the cache, callers of read-passwd must be
    updated, to provide the "key" into the hash table), it could ask the
    user this.  Opinions on this welcome.

Having it always ask would be too annoying, I think.  So that would
need to be a new argument, which means the feature is no benefit
unless we change the callers.

That is the wrong thing to do at present.  So I think we should put
read-passwd back where it was and remove the new file for now.

Looking ahead to the future,

    > Why have both password-read and password-read-and-add?
    > Why not always add?  Is the idea that for some purposes
    > it is ok to cache, but for others it is too risky?

    No, the reason was this: if the user entered an incorrect password, it
    should not be cached.  If an incorrect password is cached, the code
    might infloop trying the incorrect password automatically over and
    over again.  It was considered safer to first read the password, then
    try to use it, and if successful then it is cached.

In that case, password-read-and-add makes no sense, right?
Why add a shortcut that in best practice should not be used?

    I'm not sure my argument is good, it may be simpler to always cache,
    and have the calling code invoke password-cache-remove whenever there
    is a password failure.

That is a reasonable alternative, I guess, but then password-read
should add the password and we should not have password-read-and-add
as a separate entry point.

But it doesn't make sense to discuss this without dealing with the
question of whether caching of correct passwords is desirable.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

There are risks associated with caching passwords (i.e., the password is
stored in memory and may be swapped out to disk), and possibly it should
not be the default.  However, I think the risks are somewhat overblown.
The garbage-collecting nature of elisp exposes this risk anyway.  All
passwords entered into emacs may be swapped out to disk.

There are solutions intended to address the real problem here: GnuPG
uses a helper program pin-entry that asks the user for passwords.  I
believe it can cache passwords too.  However, this is not widely used,
and definitely not used or known except to GnuPG users.  I'm not
convinced it is mature enough to be suggested as a solution for password
input in emacs.  And anyway, you'd still have the gc-problem in emacs if
the password is transfered into an emacs elisp variable.

Another point of view is that several parts of Emacs already contains
code to cache passwords.  Reducing that code duplication is what
triggered me to write password.el.

The existing `read-passwd' API is not suitable for password.el, because
each password needs to be associated with an application-dependent
'key'.  There is no parameter for that in `read-passwd'.  Do you think
it is worth adding one?

Alternatively, and what I consider the best idea (but it was some time
since this was discussed and I may very well have forgotten some
important point): let's make `read-passwd' a more lower-level primitive,
used by `password-read'.  New elisp applications, that want to allow
users to cache passwords, can start to use the `password-read' API.
Existing elisp applications with their own ad-hoc code to cache
passwords could be modified to use password-read.  Users can modify the
caching behaviour by setting password-* variables.

Regarding naming, possibly `password-read-and-cache' should be removed.
The problem with it is that it enters passwords into the cache without
allowing applications to verify that the password is correct.  However,
applications could detect this and use `password-cache-remove', but it
seems less reliable to me.

/Simon

Richard Stallman <rms@gnu.org> writes:

> Here's what I said about read-passwd and password.el in 2004.  Setting
> aside what I said about the short term, the main issue seems to be
> whether to cache passwords.
>
> Simon, what do you think about this now?
> What do others think?
>
>
> First message:
>
> It occurs to me that paranoid people might be worried about saving
> passwords in a cache like this.  What do people know about that issue?
>
> The text added to the manual is clear enough.  I have some issues
> about the substance:
>
>      -- Function: read-passwd prompt &optional confirm default
> 	 This function reads a password, prompting with PROMPT.  It does
> 	 not echo the password as the user types it; instead, it echoes `.'
> 	 for each character in the password.
>
> This ought to use the cache now, but the text does not say so.
>
> (Later): It looks like all you did was move read-passwd into
> password.el without changing it.  What I suggested was to integrate
> read-passwd into this file--which means, make it use the cache.
>
> There is no sense in moving read-passwd into the new file without
> making it use the new file's facilities.  That change only causes
> password.el to be loaded for programs that don't use the cache.
> It provides no benefit.
>
> So if its definition is to remain unchanged, it should stay in subr.el
> where it is preloaded.  But I would rather see it move to password.el
> and *take advantage of the facilities of password.el*.
>
> Can this be done?
>
>      -- Function: password-read prompt key
> 	 Read a password from the user, using `read-passwd', prompting with
> 	 PROMPT.  If a password has been stored in the password cache,
> 	 using `password-cache-add' on the same KEY, it is returned
> 	 directly, without querying the user.
>
> Once read-passwd uses the cache, won't password-read be obsolete?
>
> Why have both password-read and password-read-and-add?
> Why not always add?  Is the idea that for some purposes
> it is ok to cache, but for others it is too risky?
>
>
> Second message:
>
>     Other applications typically ask the user whether they want to
>     remember the password in memory.  If read-passwd is changed to cache
>     passwords (however, to use the cache, callers of read-passwd must be
>     updated, to provide the "key" into the hash table), it could ask the
>     user this.  Opinions on this welcome.
>
> Having it always ask would be too annoying, I think.  So that would
> need to be a new argument, which means the feature is no benefit
> unless we change the callers.
>
> That is the wrong thing to do at present.  So I think we should put
> read-passwd back where it was and remove the new file for now.
>
> Looking ahead to the future,
>
>     > Why have both password-read and password-read-and-add?
>     > Why not always add?  Is the idea that for some purposes
>     > it is ok to cache, but for others it is too risky?
>
>     No, the reason was this: if the user entered an incorrect password, it
>     should not be cached.  If an incorrect password is cached, the code
>     might infloop trying the incorrect password automatically over and
>     over again.  It was considered safer to first read the password, then
>     try to use it, and if successful then it is cached.
>
> In that case, password-read-and-add makes no sense, right?
> Why add a shortcut that in best practice should not be used?
>
>     I'm not sure my argument is good, it may be simpler to always cache,
>     and have the calling code invoke password-cache-remove whenever there
>     is a password failure.
>
> That is a reasonable alternative, I guess, but then password-read
> should add the password and we should not have password-read-and-add
> as a separate entry point.
>
> But it doesn't make sense to discuss this without dealing with the
> question of whether caching of correct passwords is desirable.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    There are solutions intended to address the real problem here: GnuPG
    uses a helper program pin-entry that asks the user for passwords.  I
    believe it can cache passwords too.  However, this is not widely used,
    and definitely not used or known except to GnuPG users.  I'm not
    convinced it is mature enough to be suggested as a solution for password
    input in emacs.  And anyway, you'd still have the gc-problem in emacs if
    the password is transfered into an emacs elisp variable.

Is pin-entry the program that is supposed to avoid the need to enter
passwords thru any other program?  I think we discussed how Emacs
could use pin-entry, right? I think we concluded that this was
possible under a window system but not on a tty; is that correct?

Maybe we should pursue this and look for a complete solution along
these lines.

Is it possible to use pin-entry for applications other than GnuPG?
Could it be the basis of a complete solution?

    The existing `read-passwd' API is not suitable for password.el, because
    each password needs to be associated with an application-dependent
    'key'.  There is no parameter for that in `read-passwd'.  Do you think
    it is worth adding one?

I see no harm in adding one.  Adding it at the end would avoid
incompatibility.

    Alternatively, and what I consider the best idea (but it was some time
    since this was discussed and I may very well have forgotten some
    important point): let's make `read-passwd' a more lower-level primitive,
    used by `password-read'.

All else being equal, I'd rather avoid adding another level of function
calling.  It increases the total complexity, and I don't see any benefit.
What is the benefit here?

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

2007/11/6, Richard Stallman <rms@gnu.org>:

>     The existing `read-passwd' API is not suitable for password.el, because
>     each password needs to be associated with an application-dependent
>     'key'.  There is no parameter for that in `read-passwd'.  Do you think
>     it is worth adding one?
>
> I see no harm in adding one.  Adding it at the end would avoid
> incompatibility.
>
>     Alternatively, and what I consider the best idea (but it was some time
>     since this was discussed and I may very well have forgotten some
>     important point): let's make `read-passwd' a more lower-level primitive,
>     used by `password-read'.
>
> All else being equal, I'd rather avoid adding another level of function
> calling.  It increases the total complexity, and I don't see any benefit.
> What is the benefit here?

Even though read-passwd is not perfectly secure, it is far better than
password caching in elisp.  If read-passwd does password caching by
itself and the docstring says so, thoughtless programmers will tend to
use that feature in every case.  That will cause spreading insecure
code.

So I like the latter idea, or rather to let password-read have longer
name like password-read-and-cache.

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    > All else being equal, I'd rather avoid adding another level of function
    > calling.  It increases the total complexity, and I don't see any benefit.
    > What is the benefit here?

    Even though read-passwd is not perfectly secure, it is far better than
    password caching in elisp.  If read-passwd does password caching by
    itself and the docstring says so, thoughtless programmers will tend to
    use that feature in every case.  That will cause spreading insecure
    code.

I do not understand the argument you are making.  I was talking about
two alternatives for writing the Lisp code: one function and two
functions.  I don't know how to relate what you said to that choice.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

2007/11/7, Richard Stallman <rms@gnu.org>:
>     Even though read-passwd is not perfectly secure, it is far better than
>     password caching in elisp.  If read-passwd does password caching by
>     itself and the docstring says so, thoughtless programmers will tend to
>     use that feature in every case.  That will cause spreading insecure
>     code.
>
> I do not understand the argument you are making.  I was talking about
> two alternatives for writing the Lisp code: one function and two
> functions.  I don't know how to relate what you said to that choice.

I wanted to mean that "two functions" approach is better than "one
function" approach.  The rationales are:

(1) the current read-passwd is reasonably secure (since it clears
passphrase strings read as much as possible).

(2) passphrase caching in elisp inherently has a risk to leak
passphrases to disks.

(3) if read-passwd caches passphrases when the optional argument is
given, some people will misuse that new feature (perhaps by cut&paste
existing code)
even though the docstring of read-passwd explicitly states that behavior.

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    (3) if read-passwd caches passphrases when the optional argument is
    given, some people will misuse that new feature (perhaps by cut&paste
    existing code)
    even though the docstring of read-passwd explicitly states that behavior.

I don't follow.  What is the scenario you are worried about?
What code are they copying and pasting?  And why is misuse
more likely if the new feature is an optional argument
than if it is a separate function?

Fwd: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

I'm sorry for that I sent this message only to Richard, by mistake.

---------- Forwarded message ----------
From: Daiki Ueno <ueno@unixuser.org>
Date: 2007/11/09 9:33
Subject: Re: Moving files from lisp/gnus/ to lisp/net/?
To: rms@gnu.org


2007/11/9, Richard Stallman <rms@gnu.org>:
>     (3) if read-passwd caches passphrases when the optional argument is
>     given, some people will misuse that new feature (perhaps by cut&paste
>     existing code)
>     even though the docstring of read-passwd explicitly states that behavior.
>
> I don't follow.  What is the scenario you are worried about?
> What code are they copying and pasting?  And why is misuse
> more likely if the new feature is an optional argument
> than if it is a separate function?
>
Ok, here is my scenario:

(1) There is a package "foo" which consists of several files.

(2) "foo" manages passwords used within the package with the same key
associated in the cache.  For example both foo-imap.el and foo-smtp.el
in "foo" use read-passwd with the optional argument like this:

  (read-passwd "Password: " "foo")

(3) The author of another package "bar" wants to read password which
is not necessarily cached.  He searches for appropriate code in
several elisp packages including "foo", and finds several uses of
read-passwd:

  foo/foo-imap.el: (read-passwd "Password: " "foo")
  foo/foo-smtp.el: (read-passwd "Password: " "foo")
  baz.el: (read-passwd "Password: ")

The first two lines and the last one looks similar and the author of
"bar" might use the former with a change of the package name "foo" ->
"bar".

On the other hand, if there is a separate function named
password-read-and-cache and "foo" uses this function, the author of
"bar" will find:

  foo/foo-imap.el: (password-read-and-cache "Password: " "foo")
  foo/foo-smtp.el: (password-read-and-cache "Password: " "foo")
  baz.el: (read-passwd "Password: ")

The first two lines and the last one looks different and it is quite
obvious for the author of "bar" that the first two do password caching
and the last one doesn't.

BTW, though it might not match elisp, there is an argument of function
naming in other languages.
http://www.zenspider.com/dl/rubyconf2005/open-uri.pdf

That says "give shorter names to frequently used functions, longer
names to rarely used functions".  My suggestion is based on the fact
that I hope that password caching in elisp will not be used frequently
;-)

Regards,
--
Daiki Ueno


-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

>>>>> In <E1IqbtM-0003DR-P8@fencepost.gnu.org> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:
> So you're saying he would turn on caching without realizing it?

Yes.

>     That says "give shorter names to frequently used functions, longer
>     names to rarely used functions".  My suggestion is based on the fact
>     that I hope that password caching in elisp will not be used frequently

> Ok, you have convinced me.  Let's make it a separate function.

> With that decision made, is the code ready to install?

password.el itself is in lisp/gnus/.  But we need a new function which
does password caching, whose arglist is similar to read-passwd's, and
whose name is longer than `read-passwd'.

What about this patch?

Index: lisp/gnus/password.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/gnus/password.el,v
retrieving revision 1.1
diff -c -r1.1 password.el
*** lisp/gnus/password.el	28 Oct 2007 09:18:25 -0000	1.1
--- lisp/gnus/password.el	10 Nov 2007 04:47:16 -0000
***************
*** 134,139 ****
--- 134,152 ----
    (interactive)
    (fillarray password-data 0))
  
+ ;;;###autoload
+ (defun read-passwd-through-cache (prompt key &optional confirm default)
+   "Read password associated with KEY in password cache.
+ This first looks up the cache by KEY.  If it doesn't hit, this asks
+ user to input, and then adds it to the cache.  The rest of arguments
+ PROMPT, CONFIRM, and DEFAULT are passed to `read-passwd'.
+ 
+ The variable `password-cache' control whether the cache is used."
+   (or (password-read-from-cache key)
+       (let ((password (read-passwd prompt confirm default)))
+ 	(password-cache-add key password)
+ 	password)))
+ 
  (provide 'password)
  
  ;;; arch-tag: ab160494-16c8-4c68-a4a1-73eebf6686e5

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

>>>>> In <af09e08c-8d72-4926-8594-f5d8e07cb502@broken.deisui.org> 
>>>>>	Daiki Ueno <ueno@unixuser.org> wrote:
> password.el itself is in lisp/gnus/.  But we need a new function which
> does password caching, whose arglist is similar to read-passwd's, and
> whose name is longer than `read-passwd'.

> What about this patch?

Sorry for consecutive post but this might be better regarding argument
order.

Index: lisp/gnus/password.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/gnus/password.el,v
retrieving revision 1.1
diff -c -r1.1 password.el
*** lisp/gnus/password.el	28 Oct 2007 09:18:25 -0000	1.1
--- lisp/gnus/password.el	10 Nov 2007 07:03:14 -0000
***************
*** 134,139 ****
--- 134,152 ----
    (interactive)
    (fillarray password-data 0))
  
+ ;;;###autoload
+ (defun read-passwd-through-cache (key prompt &optional confirm default)
+   "Read password associated with KEY in password cache.
+ This first looks up the cache by KEY.  If it doesn't hit, this asks
+ user to input, and then adds it to the cache.  The rest of arguments
+ PROMPT, CONFIRM, and DEFAULT are passed to `read-passwd'.
+ 
+ To remove the password from the cache, `password-cache-remove'."
+   (or (password-read-from-cache key)
+       (let ((password (read-passwd prompt confirm default)))
+ 	(password-cache-add key password)
+ 	password)))
+ 
  (provide 'password)
  
  ;;; arch-tag: ab160494-16c8-4c68-a4a1-73eebf6686e5

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

>> password.el itself is in lisp/gnus/.  But we need a new function which
>> does password caching, whose arglist is similar to read-passwd's, and
>> whose name is longer than `read-passwd'.

>> What about this patch?

> Sorry for consecutive post but this might be better regarding argument
> order.

I think the docstring should make it very clear that the caller should
be careful to remove the password from the cache in case it turns out
not to be right.
Or even make it more clear that this is not the thing to use because the
password should only be added to the cache after checking its validity.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

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

>>> password.el itself is in lisp/gnus/.  But we need a new function which
>>> does password caching, whose arglist is similar to read-passwd's, and
>>> whose name is longer than `read-passwd'.
>
>>> What about this patch?
>
>> Sorry for consecutive post but this might be better regarding argument
>> order.
>
> I think the docstring should make it very clear that the caller should
> be careful to remove the password from the cache in case it turns out
> not to be right.
> Or even make it more clear that this is not the thing to use because the
> password should only be added to the cache after checking its validity.

Agreed.  I perhaps misunderstood Simon's arguments in the first post
correctly.

In that case, I think the most part of the existing API of password.el
is sufficient enough:

- password-read-from-cache KEY
  Obtain passphrase for KEY from time-limited passphrase cache.

- password-cache-add KEY PASSWORD
  Add password to cache.

- password-cache-remove KEY
  Remove password indexed by KEY from password cache.

However, `password-read-and-add' and `password-read' look awkward as
interface function.  Because `password-read-and-add' is not capable of
checking the validity of the password as you say, and `password-read'
has somewhat misleading name to use.  In addition, they does not provide
a way to pass CONFIRM and DEFAULT args to `read-passwd' while they call
`read-passwd' internally.

- password-read-and-add PROMPT &optional KEY
  Read password, for use with KEY, from user, or from cache if wanted.
  Then store the password in the cache.  Uses `password-read' and
  `password-cache-add'.

- password-read PROMPT &optional KEY
  Read password, for use with KEY, from user, or from cache if wanted.

How about just making these two functions obsolete?

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    Simon> Regarding naming, possibly `password-read-and-cache' should be removed.
    Simon> The problem with it is that it enters passwords into the cache without
    Simon> allowing applications to verify that the password is correct.  However,
    Simon> applications could detect this and use `password-cache-remove', but it
    Simon> seems less reliable to me.

    I agree.  Forgetting to remove a bad password is less friendly than
    forgetting to add a good one.

Now that you mention it, I agree: it usually doesn't make sense to add
the password to the cache when reading it.  So I guess we don't really
want `password-read-and-cache'.

I agree that we should also mark `password-read-and-add' as obsolete.

If the only desired operation is to read a password and see if it is
in the cache, then I think we should give `read-passwd' an optional
KEY argument and make it just check the cache, not add.  That won't
lead to the previously described code-copying problem, because the
cache will not have passwords for the new application unless it also
has calls to add to the cache.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

2007/11/12, Richard Stallman <rms@gnu.org>:
> If the only desired operation is to read a password and see if it is
> in the cache, then I think we should give `read-passwd' an optional
> KEY argument and make it just check the cache, not add.  That won't
> lead to the previously described code-copying problem, because the
> cache will not have passwords for the new application unless it also
> has calls to add to the cache.

Exactly.  But I'm still in doubt that it is worth adding an optional
KEY argument to `read-passwd'.  It will indeed reduces the code from:

(let ((password (or (password-read-from-cache key)
		    (read-passwd "Password: " confirm default))))
  ... use PASSWORD, and/or check its validity ...
  (if password-should-be-cached
      (password-cache-add key password)))

to:

(let ((password (read-passwd "Password: " confirm default key)))
  ... use PASSWORD, and/or check its validity ...
  (if password-should-be-cached
      (password-cache-add key password)))

This will help programmers only a little, and speaking of this kind of
"risky" code, we should rather require programmers to type more
letters than ordinary code, I think.

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    Exactly.  But I'm still in doubt that it is worth adding an optional
    KEY argument to `read-passwd'.

Maybe you are right.  I won't insist on changing `read-passwd' if you think
it is cleaner not to.

So how about renaming lisp/gnus/passwd.el to lisp/passwd-cache.el?

Re: Moving files from lisp/gnus/ to lisp/net/?

[Daiki Ueno]

2007/11/13, Richard Stallman <rms@gnu.org>:
> So how about renaming lisp/gnus/passwd.el to lisp/passwd-cache.el?

It looks fine with me, unless changing the basename makes trouble in
synch'ing any packages which use password.el and are also developed
outside of Emacs CVS (Gnus and Tramp?, for instance).

Regards,
-- 
Daiki Ueno

Re: Moving files from lisp/gnus/ to lisp/net/?

[Michael Albinus]

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

> 2007/11/13, Richard Stallman <rms@gnu.org>:
>> So how about renaming lisp/gnus/passwd.el to lisp/passwd-cache.el?
>
> It looks fine with me, unless changing the basename makes trouble in
> synch'ing any packages which use password.el and are also developed
> outside of Emacs CVS (Gnus and Tramp?, for instance).

Tramp could handle this.

> Regards,

Best regards, Michael.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

>>> So how about renaming lisp/gnus/passwd.el to lisp/passwd-cache.el?
>> 
>> It looks fine with me, unless changing the basename makes trouble in
>> synch'ing any packages which use password.el and are also developed
>> outside of Emacs CVS (Gnus and Tramp?, for instance).

I wouldn't oppose such a change, but it seems gratuitous.  "passwd.el"
is a perfectly good name for this package, AFAICT.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Michael Albinus]

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

>>>> So how about renaming lisp/gnus/passwd.el to lisp/passwd-cache.el?
>>> 
>>> It looks fine with me, unless changing the basename makes trouble in
>>> synch'ing any packages which use password.el and are also developed
>>> outside of Emacs CVS (Gnus and Tramp?, for instance).
>
> I wouldn't oppose such a change, but it seems gratuitous.  "passwd.el"
> is a perfectly good name for this package, AFAICT.

That would be a change as well. The file is called "password.el" until now.

>         Stefan

Best regards, Michael.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

>> I wouldn't oppose such a change, but it seems gratuitous.  "passwd.el"
>> is a perfectly good name for this package, AFAICT.

> That would be a change as well. The file is called "password.el" until now.

Sorry, I just took the name from some earlier message.
I meant "password.el is a perfectly good name for this package", then.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    I wouldn't oppose such a change, but it seems gratuitous.  "passwd.el"
    is a perfectly good name for this package, AFAICT.

This package is specifically for password caching.
"passwd.el" implies a general package for handling passwords.
It's not as good a name.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

>     I wouldn't oppose such a change, but it seems gratuitous.  "passwd.el"
>     is a perfectly good name for this package, AFAICT.

> This package is specifically for password caching.
> "passwd.el" implies a general package for handling passwords.
> It's not as good a name.

What else would there be to do with passwords?
If you mean that it lacks "read-passwd", we can move it to password.el.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    > This package is specifically for password caching.
    > "passwd.el" implies a general package for handling passwords.
    > It's not as good a name.

    What else would there be to do with passwords?

Who knows?  Why make an assumption?

    If you mean that it lacks "read-passwd", we can move it to password.el.

That would be undesirable.


Please go ahead with the renaming as I've requested.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

"Daiki Ueno" <ueno@unixuser.org> writes:
> It looks fine with me, unless changing the basename makes trouble in
> synch'ing any packages which use password.el and are also developed
> outside of Emacs CVS (Gnus and Tramp?, for instance).

It doesn't affect syncing with gnus (the basename isn't used in most cases).

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    It looks fine with me, unless changing the basename makes trouble in
    synch'ing any packages which use password.el and are also developed
    outside of Emacs CVS (Gnus and Tramp?, for instance).

I am sure they can cope.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

Your patch to add `read-passwd-through-cache' is good,
but since password.el is a general facility, we should move
the file out of Gnus.  Can you please move it into the main
`lisp' directory, then install your patch?

I prefer PROMPT before KEY.

Please put some text into etc/NEWS and something in the Lisp Manual
about this.  It is important to give advice about good usage
of the facility, not just give the rules for calling it.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Tom Tromey]

>>>>> "Simon" == Simon Josefsson <simon@josefsson.org> writes:

Simon> Another point of view is that several parts of Emacs already contains
Simon> code to cache passwords.  Reducing that code duplication is what
Simon> triggered me to write password.el.

I also wrote something along these lines.  I just never got around to
hooking it up to all the places in Emacs that ask for passwords.
Emacs is about the only major program I use any more that doesn't have
some kind of keyring support...

Simon> The existing `read-passwd' API is not suitable for password.el,
Simon> because each password needs to be associated with an
Simon> application-dependent 'key'.

Yeah.  In my approach, I used an alist for the key, as this fit better
with what the Gnome keyring uses.  I also wrote a little utility
program so that Emacs could easily talk to the keyring... if you want
that, I'm happy to send it along.

Simon> Regarding naming, possibly `password-read-and-cache' should be removed.
Simon> The problem with it is that it enters passwords into the cache without
Simon> allowing applications to verify that the password is correct.  However,
Simon> applications could detect this and use `password-cache-remove', but it
Simon> seems less reliable to me.

I agree.  Forgetting to remove a bad password is less friendly than
forgetting to add a good one.

Tom

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Fri, Oct 15, 2004 at 09:26:59PM +0200, Simon Josefsson wrote:
> People seem to fear using some files in gnus/ because they think the
> files might end up loading all of Gnus.  I believe moving some of the
> self contained files in Gnus elsewhere would be good.  This would make
> it clear that they aren't an intrinsic part of Gnus.

Offhand I think it's a great idea, but a few twists come to mind:

  * What will these file's status in "upstream" Gnus be?  Gnus tries to be
    compatible with older emacs versions, so it seems like you can't just
    remove them from the Gnus distribution, but for this "separation" to have
    any real effect for Gnus developers, it would seem that they shouldn't be
    kept in their current location.

  * As discussed in another thread, Richard has said that files which are not
    under lisp/gnus/, and not "obviously" Gnus-related, should have a
    slightly different status with respect to the Gnus developers -- he
    doesn't want arbitrary changes made to them without more discussion
    (whereas with files under lisp/gnus/, you have a freer hand).

    In the previous thread, I came to the conclusion that this wasn't a big
    deal for th because the files in question are unlikely to see major
    changes on the branch Emacs syncs with (v5-10) anyway, but perhaps some
    sort of more official policy for Gnus upstream is useful (e.g., "Don't
    make major changes to the files in the "blahblah/" directory without
    coordinating it with Emacs developers first").

> Btw, should I do cvs remove + add, or should someone with repository
> access do it?  Moving in the repository is typically bad (it break
> historic CVS branches), but I don't know what the tradition here is.

Moving in the repository is _very_ bad.  Definitely just "remove + add"; you
can include the old location in the CVS log for users to follow.

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> On Fri, Oct 15, 2004 at 09:26:59PM +0200, Simon Josefsson wrote:
>> People seem to fear using some files in gnus/ because they think the
>> files might end up loading all of Gnus.  I believe moving some of the
>> self contained files in Gnus elsewhere would be good.  This would make
>> it clear that they aren't an intrinsic part of Gnus.
>
> Offhand I think it's a great idea, but a few twists come to mind:
>
>   * What will these file's status in "upstream" Gnus be?  Gnus tries to be
>     compatible with older emacs versions, so it seems like you can't just
>     remove them from the Gnus distribution, but for this "separation" to have
>     any real effect for Gnus developers, it would seem that they shouldn't be
>     kept in their current location.

Gnus need them to work.  Perhaps writing a README.MAINTAINER file for
Gnus, that the files should not be modified considerably without
talking to the Emacs maintainers is sufficient?

Part of this effort is also to reduce the number of gratuitous changes
to the files.  The files are supposed to be stable.  If people have to
coordinate the patches, perhaps the quality of the patches that are
added will be higher.  Not that low quality patches has been a
problem, though.

>   * As discussed in another thread, Richard has said that files which are not
>     under lisp/gnus/, and not "obviously" Gnus-related, should have a
>     slightly different status with respect to the Gnus developers -- he
>     doesn't want arbitrary changes made to them without more discussion
>     (whereas with files under lisp/gnus/, you have a freer hand).

Personally, I don't think this is a problem for the files I mentioned.
What do other Gnus developers think?

I hope that I am speaking for most Gnus developers when I say that we
try to make these files standalone from Gnus, and that we encourage
non-Gnus projects to use them.  It seems that we could be more
successful with this, and giving up some control of the files and
moving the into Emacs might achieve that.

If Gnus developers think this is a bad idea, just say the word and
I'll stop.  This merging effort was initiated because I perceived that
this would help achieve the goals I felt were implicit on the Gnus
list.

> Moving in the repository is _very_ bad.  Definitely just "remove + add"; you
> can include the old location in the CVS log for users to follow.

Agreed.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Thien-Thi Nguyen]

Simon Josefsson <jas@extundo.com> writes:

   It seems that we could be more successful with this, and giving
   up some control of the files and moving the into Emacs might
   achieve that.

perhaps it's best just to write a blurb in some STANDALONE file
that explains the consensus, and furthermore lists those files
to be treated in this manner.

location of file is an indirect indicator of intent; explicit
instructions are less likely to be misinterpreted.

thi

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Sat, Oct 16, 2004 at 03:43:04AM -0400, Thien-Thi Nguyen wrote:
> Simon Josefsson <jas@extundo.com> writes:
> 
>    It seems that we could be more successful with this, and giving
>    up some control of the files and moving the into Emacs might
>    achieve that.
> 
> perhaps it's best just to write a blurb in some STANDALONE file
> that explains the consensus, and furthermore lists those files
> to be treated in this manner.
> 
> location of file is an indirect indicator of intent; explicit
> instructions are less likely to be misinterpreted.

Perhaps, but location is far more effective for avoiding mistakes in
day-to-day hacking, because people tend forget random stuff written in readme
files, but the location is in your face everytime you edit the file.

So, in fact _both_ should be done.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

I agree with the general goal, but just like Miles I think we should be
careful with it.  More specifically, I think the change should be done
together with the Gnus team.

One way I see it happen is for the Gnus maintainers to move those file in
their repository to a new directory (call it "util") and treat them as
"files which should be provided by Emacs but which we distribute because
many Emacsen don't have them (yet)".


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

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

> I agree with the general goal, but just like Miles I think we should be
> careful with it.  More specifically, I think the change should be done
> together with the Gnus team.

Right.

> One way I see it happen is for the Gnus maintainers to move those file in
> their repository to a new directory (call it "util") and treat them as
> "files which should be provided by Emacs but which we distribute because
> many Emacsen don't have them (yet)".

We would have to rewrite the Gnus makefiles to make that possible,
which might be harder than it seems.  However, it seems that a Gnus
Maintenance Guide may be written, then we can mention that these files
should only be changed after discussion with the Emacs maintainers.  I
think that would be sufficient.

All the files I mentioned are rather stable, though.  They are changed
from time to time, but the changes are typically small.

Thanks.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

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

> One way I see it happen is for the Gnus maintainers to move those file in
> their repository to a new directory (call it "util") and treat them as
> "files which should be provided by Emacs but which we distribute because
> many Emacsen don't have them (yet)".

I think that'd make sense.  Perhaps even do a tree mimicking the
Emacs layout?  That is, .../lisp/gnus/, .../lisp/mail, .../lisp/net/,
etc. 

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> One way I see it happen is for the Gnus maintainers to move those file in
>> their repository to a new directory (call it "util") and treat them as
>> "files which should be provided by Emacs but which we distribute because
>> many Emacsen don't have them (yet)".
>
> I think that'd make sense.  Perhaps even do a tree mimicking the
> Emacs layout?  That is, .../lisp/gnus/, .../lisp/mail, .../lisp/net/,
> etc. 

Maybe even try to use Autoconf/Automake and its Emacs Lisp rules,
instead of hand written makefiles?  I recall trying it for Gnus when
all lisp files is in one directory, but I have no idea whether it
works when there are files in multiple directories.  I'd imagine the
autoload cookies might be a problem.  Perhaps not worthwhile.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

>> One way I see it happen is for the Gnus maintainers to move those file in
>> their repository to a new directory (call it "util") and treat them as
>> "files which should be provided by Emacs but which we distribute because
>> many Emacsen don't have them (yet)".

> I think that'd make sense.  Perhaps even do a tree mimicking the
> Emacs layout?  That is, .../lisp/gnus/, .../lisp/mail, .../lisp/net/,
> etc.

Sure.

Also it seems that files that are intended to be non-specific to Gnus don't
start with `gnus-', so maybe there's no need to move any file and
file-name-prefix can be used instead.

I don't really care how it's done, so long as it's clear enough that there
won't be too many conflicts where the file changed on the Gnus (resp Emacs)
side and it creates problems on the Emacs (resp Gnus) side.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> I think that'd make sense.  Perhaps even do a tree mimicking the
> Emacs layout?  That is, .../lisp/gnus/, .../lisp/mail, .../lisp/net/,
> etc. 

I think this would be very nice and make relationship-with-Emacs issues
easier to handle.  The "status" of a file would be obvious just from its
name, and if someone wanted to locate the same file in an Emacs tree,
it would be completely obvious where it is. :-)

In addition, it would help work around a mis-feature of arch that
sometimes bites me when syncing between Emacs and Gnus:  changesets
including new files create the files using an absolute path-name (not
parent-directory-id+name), so I've got to manually fix them up (move the
new file) if applying the changeset to a different directory structure.
[Arch mis-features aren't a very good a reason to change Gnus of course,
but thought I'd mention it.]

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    including new files create the files using an absolute path-name

In GNU the convention is not to use the term "pathname".

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> I think this would be very nice and make relationship-with-Emacs issues
> easier to handle.  The "status" of a file would be obvious just from its
> name, and if someone wanted to locate the same file in an Emacs tree,
> it would be completely obvious where it is. :-)

Yup.  And it should be simple enough to move the files around in the
Gnus CVS repository without losing any CVS history if I do it by hand
and is, er, careful.  I think.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Wed, Oct 20, 2004 at 12:27:58PM +0200, Lars Magne Ingebrigtsen wrote:
> And it should be simple enough to move the files around in the
> Gnus CVS repository without losing any CVS history if I do it by hand
> and is, er, careful.  I think.

I think this is generally considered a very bad thing to do.  It's much safer
(if less exciting) to just do the old cvs add+rm thing, and make the first
commit log in the new location "renamed from foo".

The reason it's bad, as I understand it, is that it essentially changes
history; I'm not entirely sure of the all the user-visible repercussions, but
I'm not sure I want to find out the hard way...

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ralf Angeli]

* Miles Bader (2004-10-20) writes:

> On Wed, Oct 20, 2004 at 12:27:58PM +0200, Lars Magne Ingebrigtsen wrote:
>> And it should be simple enough to move the files around in the
>> Gnus CVS repository without losing any CVS history if I do it by hand
>> and is, er, careful.  I think.
>
> I think this is generally considered a very bad thing to do.  It's much safer
> (if less exciting) to just do the old cvs add+rm thing, and make the first
> commit log in the new location "renamed from foo".
>
> The reason it's bad, as I understand it, is that it essentially changes
> history; I'm not entirely sure of the all the user-visible repercussions, but
> I'm not sure I want to find out the hard way...

Why don't you just dump CVS and switch to a different version
management system which supports these kinds of operation?

When preview-latex will get integrated in AUCTeX we will probably have
to move and rename many files as well and it is a pity that we are
stuck with CVS due to Savannah not providing alternatives.

-- 
Ralf

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ralf Angeli]

* Ralf Angeli (2004-10-20) writes:

> Why don't you just dump CVS and switch to a different version
> management system which supports these kinds of operation?
>
> When preview-latex will get integrated in AUCTeX we will probably have
> to move and rename many files as well and it is a pity that we are
> stuck with CVS due to Savannah not providing alternatives.

In order to avoid this message being rated as a troll, I'd like to add
that dumping CVS of course is currently not feasible for Emacs as its
main focus of development is the upcoming release.  I was just carried
away by people all around me complaining about CVS.  But maybe one can
keep it in mind for the time after the release.

-- 
Ralf

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Ralf Angeli <angeli@iwi.uni-sb.de> writes:
>> The reason it's bad, as I understand it, is that it essentially changes
>> history; I'm not entirely sure of the all the user-visible repercussions, but
>> I'm not sure I want to find out the hard way...
>
> Why don't you just dump CVS and switch to a different version
> management system which supports these kinds of operation?

Well, personally I use arch, which of course does support these operations. :-)

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> I think this is generally considered a very bad thing to do.  It's much safer
> (if less exciting) to just do the old cvs add+rm thing, and make the first
> commit log in the new location "renamed from foo".

But then we lose the log.

> The reason it's bad, as I understand it, is that it essentially changes
> history; I'm not entirely sure of the all the user-visible repercussions, but
> I'm not sure I want to find out the hard way...

Hm...  I don't quite follow you.  The CVS tree is (almost) just a
bunch of ,v files.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Miles Bader <miles@gnu.org> writes:
> > I think this is generally considered a very bad thing to do.  It's
> >much safer (if less exciting) to just do the old cvs add+rm thing,
> >and make the first commit log in the new location "renamed from foo".
> 
> But then we lose the log.
> 
> > The reason it's bad, as I understand it, is that it essentially
> >changes history; I'm not entirely sure of the all the user-visible
> >repercussions, but I'm not sure I want to find out the hard way...
> 
> Hm...  I don't quite follow you.  The CVS tree is (almost) just a
> bunch of ,v files.

Miles's point is that by moving (or copying) a ,v file from one place
to another, we create a history in the new place that was not actually
there in reality.  For example, if there is a tag V1_RELEASE on a
revision in the ,v file, then someone attempting to check out the tree
as of the tag V1_RELEASE will get a file in a location that did
actually exist at the time the V1_RELEASE tag was made.  

(And if the ,v file was moved, instead of copied, the V1_RELEASE
checkout will fail to contain a file that it should contain!)

The usual solution is this:

   1. Manually *copy* the ,v file from the old place to the new place.

   2. Use 'cvs rm' to "remove" it from the old place (actually just
      marks the head revision as dead and puts the ,v file into CVS's
      Attic, thus preserving history)

That's a compromise.  It creates some new false history, but at least
it preserves all of the old history.  Old tags and branches will have
all the files they should have, they'll just have a bit more besides.

-Karl

Re: Moving files from lisp/gnus/ to lisp/net/?

[David Kastrup]

Karl Fogel <kfogel@floss.red-bean.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Miles Bader <miles@gnu.org> writes:
>> > I think this is generally considered a very bad thing to do.  It's
>> >much safer (if less exciting) to just do the old cvs add+rm thing,
>> >and make the first commit log in the new location "renamed from foo".
>> 
>> But then we lose the log.
>
> The usual solution is this:
>
>    1. Manually *copy* the ,v file from the old place to the new place.
>
>    2. Use 'cvs rm' to "remove" it from the old place (actually just
>       marks the head revision as dead and puts the ,v file into CVS's
>       Attic, thus preserving history)
>
> That's a compromise.

It's still junk.

> It creates some new false history, but at least it preserves all of
> the old history.

You can do that by doing the checkin with the _complete_ old log as a
log message.

> Old tags and branches will have all the files they should have,
> they'll just have a bit more besides.

I don't see what the problem with just checking the whole old log into
the new file's log is.  It does not create a false history, and it
works fine.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan Monnier]

> You can do that by doing the checkin with the _complete_ old log as a
> log message.

The log is already available in the ChangeLog file, so it's clearly not
the problem.  The interesting bits of info are the actual diffs, so you can
do `cvs annotate' and things like that.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[David Kastrup]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Miles Bader <miles@gnu.org> writes:
>
>> I think this is generally considered a very bad thing to do.  It's
>> much safer (if less exciting) to just do the old cvs add+rm thing,
>> and make the first commit log in the new location "renamed from
>> foo".
>
> But then we lose the log.

Guess what I check in as a long long log message when moving a file
via add+rm in CVS.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> I think this is generally considered a very bad thing to do.  It's much safer
>> (if less exciting) to just do the old cvs add+rm thing, and make the first
>> commit log in the new location "renamed from foo".
>
> But then we lose the log.

Not really -- it's still there in the old deleted file.  My practice is
simply to put in a pointer to the old file as the first commit message
in the new file, so that someone interested in pre-rename history can
look there, e.g.:

    cvs add foo; cvs commit -m"Renamed from bar" foo

Alternatively, you can do as David suggested and simply use the entire
old log as the initial commit message.

Personally I don't think it's worth the bother -- CVS logs are handy on
occasion, but they're not _that_ commonly used; if somebody has to
expend a slight bit of extra effort to look at old logs (e.g., follow
the pointer to the old name), it's not a tragedy.  What's most important
is that the information _is_ still there.

Furthermore, as Stefan pointed out, CVS logs are typically not as
necessary in GNU projects because the info is usually already there in
the ChangeLogs (often in a more useful form).

>> The reason it's bad, as I understand it, is that it essentially changes
>> history; I'm not entirely sure of the all the user-visible repercussions, but
>> I'm not sure I want to find out the hard way...
>
> Hm...  I don't quite follow you.  The CVS tree is (almost) just a
> bunch of ,v files.

The problem is that you're changing history:  By renaming the ,v file,
in effective you retroactively rename the file in old versions too.  So
sombody that tries to check out an old version using a tag (or -D...)
will see the old version _with the more recent renames applied_.

This loses for a few reasons:  old Makefiles won't work correctly, diffs
between these "retroactively updated" old versions and newer (post
rename) versions won't actually reflect the "real" difference, possibly
causing great confusion in merging, etc.

It may be that in practice the bad effects are "acceptable" -- maybe
nobody at all cares about old versions -- but it's really hard to tell
in advance, and if it turns out later there _is_ a problem, well, then
what?

It's all around safer to use the boring and clunky rm+add method.  It is
less likely to yield surprises, and I think where source control is
concerned, surprises are usually not what you want ... :-)

[From my arch-gateway perspective, I presume that if you do the rename
 on both the v5-10 branch and the trunk simultaneously, the user-visible
 effect (from "cvs update") will be the same:  the old names will
 disappear and will seem to be added under the new names.

 But ... I don't really know, and thus and somewhat worried.]

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Furthermore, as Stefan pointed out, CVS logs are typically not as
> necessary in GNU projects because the info is usually already there in
> the ChangeLogs (often in a more useful form).

Actually, it's not the logs by themselves that I use -- it's the
ability to see "oh, that person checked in that thing; I wonder what
the diff is".  And the answer is just a `C-u C-x v =' away...

By doing rm/add we'd lose that.

> The problem is that you're changing history:  By renaming the ,v file,
> in effective you retroactively rename the file in old versions too.  So
> sombody that tries to check out an old version using a tag (or -D...)
> will see the old version _with the more recent renames applied_.

Ah; I hadn't thought about that...  that does seem like a
inconvenience.  Hm...

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Actually, it's not the logs by themselves that I use -- it's the
> ability to see "oh, that person checked in that thing; I wonder what
> the diff is".  And the answer is just a `C-u C-x v =' away...
>
> By doing rm/add we'd lose that.

Well, you wouldn't really lose it, just make it a bit less convenient --
the info is still there.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Moving files from lisp/gnus/ to lisp/net/?

[Kim F. Storm]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>> Furthermore, as Stefan pointed out, CVS logs are typically not as
>> necessary in GNU projects because the info is usually already there in
>> the ChangeLogs (often in a more useful form).
>
> Actually, it's not the logs by themselves that I use -- it's the
> ability to see "oh, that person checked in that thing; I wonder what
> the diff is".  And the answer is just a `C-u C-x v =' away...
>
> By doing rm/add we'd lose that.
>
>> The problem is that you're changing history:  By renaming the ,v file,
>> in effective you retroactively rename the file in old versions too.  So
>> sombody that tries to check out an old version using a tag (or -D...)
>> will see the old version _with the more recent renames applied_.
>
> Ah; I hadn't thought about that...  that does seem like a
> inconvenience.  Hm...
>

Here's a way to make it work with CVS:

COPY the ,v files to the new place.
For each ACTIVE/DEVELOPMENT branch, do cvs rm in the old place.
For each PASSIVE/MAINTENANCE branch, do cvs rm in the NEW place.


Then when you checkout from trunk or ACTIVE branch, you get the
files in the NEW place (with all the history).

If you checkout on a PASSIVE/MAINTENANCE branch, or an older version
on the trunk, you get the files in the OLD place (with all the
history) AND in the NEW place (with all the history).

In the latter case, you can just ignore the copy in the NEW place
while working in the OLD place -- or ignore the OLD copy if you
are working in the NEW place (on trunk).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

storm@cua.dk (Kim F. Storm) writes:

> Here's a way to make it work with CVS:
>
> COPY the ,v files to the new place.
> For each ACTIVE/DEVELOPMENT branch, do cvs rm in the old place.
> For each PASSIVE/MAINTENANCE branch, do cvs rm in the NEW place.
>
> Then when you checkout from trunk or ACTIVE branch, you get the
> files in the NEW place (with all the history).
>
> If you checkout on a PASSIVE/MAINTENANCE branch, or an older version
> on the trunk, you get the files in the OLD place (with all the
> history) AND in the NEW place (with all the history).
>
> In the latter case, you can just ignore the copy in the NEW place
> while working in the OLD place -- or ignore the OLD copy if you
> are working in the NEW place (on trunk).

Hm.  That would work.  But perhaps the best solution is to not move
any files after all.  :-)

If we had a specific and set mapping maintained in a file that said
where each file is supposed to go, then perhaps Miles would be able
to sort things out automatically? 

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Hm.  That would work.  But perhaps the best solution is to not move
> any files after all.  :-)

No, I think the files should be moved; the whole "but what about the
history?" issue is IMHO, vastly overrated -- it's a minor bump in the
road (if even that) that will make future operations smoother.

Remember, the _info is still there_, just slightly more annoying to get
at.  In my experience, looking at history is (1) not all that frequent
an event, and (2) almost always involves the last few file revisions;
point (2) is important because it means for commonly changed files, the
bump caused by file moving will cease to be an issue after a short while
(and for _un_-commonly changed files, well, they're not being changed
very often, so aren't something to worry about very much).

Moving the files will simplify coordination with Emacs, and not just
with regard to the source-code "syncing" process: more importantly, it
will clearly communicate to Gnus developers the status of a file they're
working on, and make its relationship with Emacs obvious.

Morever I think Gnus is large enough that some more directory structure
is a good thing even without Emacs coordination to worry about.

> If we had a specific and set mapping maintained in a file that said
> where each file is supposed to go, then perhaps Miles would be able
> to sort things out automatically? 

Maintaining a mapping between emacs locations and Gnus locations is not
generally a problem for me -- arch applies changesets according to
file-id, not name.

There is a slight benefit to having similar directory structures when
files are added/removed, as I probably don't have to worry about
adjusting the names in that case.  However this is a relatively rare
event.

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Hm.  That would work.  But perhaps the best solution is to not move
>> any files after all.  :-)
>
> No, I think the files should be moved; the whole "but what about the
> history?" issue is IMHO, vastly overrated -- it's a minor bump in the
> road (if even that) that will make future operations smoother.
>
> Remember, the _info is still there_, just slightly more annoying to get
> at.  In my experience, looking at history is (1) not all that frequent
> an event, and (2) almost always involves the last few file revisions;
> point (2) is important because it means for commonly changed files, the
> bump caused by file moving will cease to be an issue after a short while
> (and for _un_-commonly changed files, well, they're not being changed
> very often, so aren't something to worry about very much).
>
> Moving the files will simplify coordination with Emacs, and not just
> with regard to the source-code "syncing" process: more importantly, it
> will clearly communicate to Gnus developers the status of a file they're
> working on, and make its relationship with Emacs obvious.
>
> Morever I think Gnus is large enough that some more directory structure
> is a good thing even without Emacs coordination to worry about.

One potential problem with a multi-directory structure is how to build
Gnus.  I'm not that familiar with the current code to build Gnus, but
it is not as simple as 'emacs -f byte-compile-file foo.el' on each
file.  Someone will have to experiment with getting a multi-directory
structure into a buildable state.

There is also the problem if getting users to modify their load-path's
to accommodate the new Gnus layout.

I wouldn't mind if the files stay as they are in Gnus CVS.  It seems
the gains of a directory split are somewhat vague, and it isn't clear
to me that a README.CVS wouldn't suffice.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> One potential problem with a multi-directory structure is how to build
> Gnus.  I'm not that familiar with the current code to build Gnus, but
> it is not as simple as 'emacs -f byte-compile-file foo.el' on each
> file.  Someone will have to experiment with getting a multi-directory
> structure into a buildable state.

I think getting a buildable Gnus package won't be all that much
work... 

> There is also the problem if getting users to modify their load-path's
> to accommodate the new Gnus layout.

... but this is a more serious problem.  Or does Emacs look into
sub-directories of load-path these days?

Of course, one could do some load-path trickery in gnus.el -- mangle
load-path when loading that file to reflect the new layout.  Which may
be slightly naughty.  (This is for Gnus distributed separately only;
not in Emacs, of course.)

> I wouldn't mind if the files stay as they are in Gnus CVS.  It seems
> the gains of a directory split are somewhat vague, and it isn't clear
> to me that a README.CVS wouldn't suffice.

Of the reasons Miles listed, I think the, er, "mental hygiene" one
was the most compelling.  When you know that file X is supposed to be
used independently of Gnus, you're more careful about adding the
wrong kinds of dependencies.

And that might be easier with separate directories, but it's not
necessary, though.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Mon, Oct 25, 2004 at 07:46:19PM +0200, Lars Magne Ingebrigtsen wrote:
> > There is also the problem if getting users to modify their load-path's
> > to accommodate the new Gnus layout.
> 
> ... but this is a more serious problem.  Or does Emacs look into
> sub-directories of load-path these days?
> 
> Of course, one could do some load-path trickery in gnus.el -- mangle
> load-path when loading that file to reflect the new layout.  Which may
> be slightly naughty.  (This is for Gnus distributed separately only;
> not in Emacs, of course.)

The install directory layout need not mirror the source layout.  Why not just
_install_ things as gnus has always done -- into one directory?

[AFAIK, to get subdir loading to work you appropriate "subdirs.el" files in
place; Gnus could have one in the source tree to accomodate loading from
there.]

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> The install directory layout need not mirror the source layout.  Why
> not just _install_ things as gnus has always done -- into one
> directory?

The Gnus distribution has traditionally not been meant to be
installed -- it's compiled and run where it's unpacked.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> The install directory layout need not mirror the source layout.  Why
>> not just _install_ things as gnus has always done -- into one
>> directory?
>
> The Gnus distribution has traditionally not been meant to be
> installed -- it's compiled and run where it's unpacked.

Er, ok, whatever[*]; but then a subdirs.el file should work.

I wasn't sure how well subdirs.el would work for the install directory
because Gnus usually uses the top-level dir, and coordinating that
between multiple installed package may not be easy.  However for the
source directory it should be no problem.

-Miles

[*] I've always installed Gnus, but maybe it's too much bother for
    someone doing Gnus development.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Kai Grossjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> There is also the problem if getting users to modify their load-path's
>> to accommodate the new Gnus layout.
>
> ... but this is a more serious problem.  Or does Emacs look into
> sub-directories of load-path these days?

Well, gnus-load.el could do all the tweaking that's necessary.  One
could put this file into the lisp directory whereas everything else
goes in lisp/foo.  WDYT?

Kai

Re: Moving files from lisp/gnus/ to lisp/net/?

[Lars Magne Ingebrigtsen]

Kai Grossjohann <kai@emptydomain.de> writes:

> Well, gnus-load.el could do all the tweaking that's necessary.  One
> could put this file into the lisp directory whereas everything else
> goes in lisp/foo.  WDYT?

Yes, that would work.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    People seem to fear using some files in gnus/ because they think the
    files might end up loading all of Gnus.  I believe moving some of the
    self contained files in Gnus elsewhere would be good.  This would make
    it clear that they aren't an intrinsic part of Gnus.  Not only would
    it make it clear for elisp programmers, it would make it clear for us
    working on Gnus.  I.e., to make sure we don't use Gnus functions in
    some of the files.  I just modified pop3.el to revert one such
    example.  It would be bad if many standalone files ended up loading
    Gnus out of pure laziness.

I agree completely.

It makes a big difference for Emacs maintenance whether a file is part
of Gnus or not.  If it is part of Gnus, it is maintained by the Gnus
developers, so they might expect to be able to change it without
looking at how the rest of Emacs uses it.

    I propose to move the following files:

    lisp/gnus/:
    binhex.el
    dig.el
    hex-util.el
    rfc2104.el
    pgg-def.el
    pgg.el
    pgg-gpg.el
    pgg-parse.el
    pgg-pgp5.el
    pgg-pgp.el
    pop3.el
    sha1.el
    sieve.el
    sieve-manage.el
    sieve-mode.el
    starttls.el

We need to consider them one by one, so please don't raise
them as a big group.  Please propose one file or a few related
files at a time, and we will think of them.

Right now let's consider only those that there is a specific reason
to move right now.

      * What will these file's status in "upstream" Gnus be?  Gnus tries to be
	compatible with older emacs versions, so it seems like you can't just
	remove them from the Gnus distribution, but for this "separation" to have
	any real effect for Gnus developers, it would seem that they shouldn't be
	kept in their current location.

If the Gnus developers want to keep including some version of these
files, such as for compatibility purposes, they can.  But they should
not install those files into the Emacs repository any more.  And they
should probably arrange that the separately-distributed Gnus won't use
the Gnus versions of those files when running in an Emacs version that
already has the facility built in.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

On Sat, 16 Oct 2004, rms@gnu.org wrote:

>     I propose to move the following files:
> 
>     lisp/gnus/:
[...]

Can we please add:

netrc.el: parsing of authinfo-style files for storing passwords for
network services

> If the Gnus developers want to keep including some version of these
> files, such as for compatibility purposes, they can.  But they should
> not install those files into the Emacs repository any more.  And they
> should probably arrange that the separately-distributed Gnus won't use
> the Gnus versions of those files when running in an Emacs version that
> already has the facility built in.

The problem is that Gnus should run in older versions of Emacs as
well, when installed by itself.  This may become a big problem
because many users simply can't upgrade.  I'm not sure what to do.

Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Reiner Steib]

On Mon, Oct 18 2004, Ted Zlatanov wrote:

> Can we please add:
>
> netrc.el: parsing of authinfo-style files for storing passwords for
> network services

netrc.el already is in emacs/net/.

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

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

On Mon, 18 Oct 2004, reinersteib+gmane@imap.cc wrote:

On Mon, Oct 18 2004, Ted Zlatanov wrote:
> 
>> Can we please add:
>>
>> netrc.el: parsing of authinfo-style files for storing passwords for
>> network services
> 
> netrc.el already is in emacs/net/.

Can it please get synchronized with the Gnus netrc.el, which supports
encrypt.el?  encrypt.el will also have to be imported.

Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Can it please get synchronized with the Gnus netrc.el, which supports
> encrypt.el?  encrypt.el will also have to be imported.

netrc.el should already be synchronized between the Gnus v5-10 branch
and Emacs (I notice there are some minor differences at the moment, but
at least future changes should be propagated).  Emacs/v5-10 changes are
also propagated to Gnus trunk (but not the reverse).

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Can it please get synchronized with the Gnus netrc.el, which supports
>> encrypt.el?  encrypt.el will also have to be imported.
>
> netrc.el should already be synchronized between the Gnus v5-10 branch
> and Emacs (I notice there are some minor differences at the moment, but
> at least future changes should be propagated).  Emacs/v5-10 changes are
> also propagated to Gnus trunk (but not the reverse).

I'm not sure it is a good idea to add encrypt.el and the related fixes
in netrc.el, pgg*, and other files to Gnus 5.10.  They are not really
tested in deployed user situations.  However, I believe it make sense
to add them both to Gnus CVS HEAD and Emacs CVS HEAD.

Perhaps it is possible to set up a synchronization gateway between
Gnus CVS HEAD and Emacs CVS HEAD for some files?  I think this would
make more sense, both in the short term and the long term.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Miles Bader]

On Sun, Oct 24, 2004 at 02:13:55PM +0200, Simon Josefsson wrote:
> I'm not sure it is a good idea to add encrypt.el and the related fixes
> in netrc.el, pgg*, and other files to Gnus 5.10.  They are not really
> tested in deployed user situations.  However, I believe it make sense
> to add them both to Gnus CVS HEAD and Emacs CVS HEAD.
> 
> Perhaps it is possible to set up a synchronization gateway between
> Gnus CVS HEAD and Emacs CVS HEAD for some files?  I think this would
> make more sense, both in the short term and the long term.

That sounds far too complicated.

I don't think Emacs changes are generally much of a threat, so I'd keep
things as they are unless it actually proves to be a problem.

-Miles
-- 
I'd rather be consing.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> On Sun, Oct 24, 2004 at 02:13:55PM +0200, Simon Josefsson wrote:
>> I'm not sure it is a good idea to add encrypt.el and the related fixes
>> in netrc.el, pgg*, and other files to Gnus 5.10.  They are not really
>> tested in deployed user situations.  However, I believe it make sense
>> to add them both to Gnus CVS HEAD and Emacs CVS HEAD.
>> 
>> Perhaps it is possible to set up a synchronization gateway between
>> Gnus CVS HEAD and Emacs CVS HEAD for some files?  I think this would
>> make more sense, both in the short term and the long term.
>
> That sounds far too complicated.
>
> I don't think Emacs changes are generally much of a threat, so I'd keep
> things as they are unless it actually proves to be a problem.

Installing password.el will hopefully lead to several changes in Gnus.
We could make imap.el, sieve*.el, pgg*.el, nntp.el, pop3.el (?),
canlock (?), smime.el (?), webmail.el (?), mail-source.el (?), all use
the new password interface in password.el.

It is stretching to definition of "bug fixes" to apply the same
changes to Gnus 5.10.

However, maybe you are right, and we should not update Gnus in Emacs
to use password.el just yet.  Instead, we should fix this in Gnus CVS
HEAD, and then Emacs CVS wait for Gnus 5.13 to get the stable version
of these patches.

On the third hand, perhaps Gnus 5.13 will happen before the next major
Emacs release?  I'm not sure what the plan is.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan]

> On the third hand, perhaps Gnus 5.13 will happen before the next major
> Emacs release?  I'm not sure what the plan is.

True: if we keep making changes to the code, it'll never get released.
So I suggest we stick to the "code freeze" and we don't try to change
Emacs-CVS right now to use passwd.el and encrypt.el.  Adding passwd.el and
encrypt.el sounds like a good idea, but changing the other files to use them
is not.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Stefan <monnier@iro.umontreal.ca> writes:

>> On the third hand, perhaps Gnus 5.13 will happen before the next major
>> Emacs release?  I'm not sure what the plan is.
>
> True: if we keep making changes to the code, it'll never get released.
> So I suggest we stick to the "code freeze" and we don't try to change
> Emacs-CVS right now to use passwd.el and encrypt.el.  Adding passwd.el and
> encrypt.el sounds like a good idea, but changing the other files to use them
> is not.

I agree, if you mean that we shouldn't change _Gnus related_ files, in
Emacs, to use password.el.  Those changes could go into Gnus CVS.  I
think it may be useful to change some other Emacs packages, like
telnet.el, though.  I don't use telnet.el, but perhaps there are other
packages I use that currently have some ad-hoc password handling code.

Incidentally, I realized that password.el could be enhanced with
support for netrc.el (i.e., passwords stored in ~/.authinfo), or even
storing passwords via customize (in ~/.emacs).

Re: Moving files from lisp/gnus/ to lisp/net/?

[Stefan]

> I agree, if you mean that we shouldn't change _Gnus related_ files, in
> Emacs, to use password.el.  Those changes could go into Gnus CVS.  I
> think it may be useful to change some other Emacs packages, like
> telnet.el, though.  I don't use telnet.el, but perhaps there are other
> packages I use that currently have some ad-hoc password handling code.

Changing telnet.el and/or other packages can wait to after the release.
There's no hurry.  I think the main point is to provide the framework
(i.e. password.el) so that other code can begin to use it.

> Incidentally, I realized that password.el could be enhanced with
> support for netrc.el (i.e., passwords stored in ~/.authinfo), or even
> storing passwords via customize (in ~/.emacs).

Sure.  We're in feature freeze, tho, so better stop thinking about how
things could be further changed and start thinking about how to get the
manual and the remaining bugs fixed, instead.
Otherwise we'll never reach a release.


        Stefan

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Stefan <monnier@iro.umontreal.ca> writes:

>> Incidentally, I realized that password.el could be enhanced with
>> support for netrc.el (i.e., passwords stored in ~/.authinfo), or even
>> storing passwords via customize (in ~/.emacs).
>
> Sure.  We're in feature freeze

I'm not sure if I knew that.  Is there some way to find out, if I
forget again?

If I knew that, I'm not sure if I would have proposed moving files
from lisp/gnus/.  It seem like that is something that could also wait
until after the release.  Moving the files might just take time away
from more important things.

> tho, so better stop thinking about how things could be further
> changed and start thinking about how to get the manual and the
> remaining bugs fixed, instead.  Otherwise we'll never reach a
> release.

Right.  I'll move read-passwd to password.el and document it now.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    I agree, if you mean that we shouldn't change _Gnus related_ files, in
    Emacs, to use password.el.  Those changes could go into Gnus CVS.  I
    think it may be useful to change some other Emacs packages, like
    telnet.el, though.

If we make read-passwd use password.el, then the other parts of
Emacs will use it without being individually changed.

If everything else in Emacs uses password.el, we should probably
change Gnus in Emacs to use password.el too.  Why should it be
the only thing left out?

This isn't the time for new features, and perhaps is not the right
time for this (though installing this file is not quite a new
feature).  However, now that the file is installed, we may as well
make read-passwd use it.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     I agree, if you mean that we shouldn't change _Gnus related_ files, in
>     Emacs, to use password.el.  Those changes could go into Gnus CVS.  I
>     think it may be useful to change some other Emacs packages, like
>     telnet.el, though.
>
> If we make read-passwd use password.el, then the other parts of
> Emacs will use it without being individually changed.
>
> If everything else in Emacs uses password.el, we should probably
> change Gnus in Emacs to use password.el too.  Why should it be
> the only thing left out?
>
> This isn't the time for new features, and perhaps is not the right
> time for this (though installing this file is not quite a new
> feature).  However, now that the file is installed, we may as well
> make read-passwd use it.

By "make read-passwd use it", do you mean that read-passwd itself
should be extended to support the caching mechanism?  Right now,
read-passwd has not been changed; instead password-read act as a
wrapper around read-passwd that add the cache mechanism.  But it may
be cleaner to add a new optional parameter to read-passwd, so the
cache is integrated better, and there are fewer interfaces.

Earlier, I got the impression that we should move read-passwd from
subr.el to password.el, not change it, which is what I did.

I think I agree with Stefan that changing too many places in Emacs to
use password.el is a bit late.  If I knew we were in a feature freeze,
I wouldn't have proposed these things.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    > If the Gnus developers want to keep including some version of these
    > files, such as for compatibility purposes, they can.  But they should
    > not install those files into the Emacs repository any more.  And they
    > should probably arrange that the separately-distributed Gnus won't use
    > the Gnus versions of those files when running in an Emacs version that
    > already has the facility built in.

    The problem is that Gnus should run in older versions of Emacs as
    well, when installed by itself.  This may become a big problem
    because many users simply can't upgrade.  I'm not sure what to do.

Gnus is mainly useful to the GNU Project is as a part of Emacs.
Support for using new versions of Gnus in old Emacs versions is nice
if you want to do it, but it's not essential for Gnu.

I don' think this is a hard problem to solve, once you put your mind
to it.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Ted Zlatanov]

On Tue, 19 Oct 2004, rms@gnu.org wrote:

> Gnus is mainly useful to the GNU Project is as a part of Emacs.
> Support for using new versions of Gnus in old Emacs versions is nice
> if you want to do it, but it's not essential for Gnu.

What is considered "old"?  21.2 and lower?  21.1 and lower?

Also I know a lot of effort goes into making Gnus compatible with
XEmacs.  Is that consistent with your views?

> I don' think this is a hard problem to solve, once you put your mind
> to it.

If there's a cutoff, sure.  Testing on multiple Emacs versions is the
real pain, I think the users mostly do it for us.

Thanks
Ted

Re: Moving files from lisp/gnus/ to lisp/net/?

[Richard Stallman]

    > Gnus is mainly useful to the GNU Project is as a part of Emacs.
    > Support for using new versions of Gnus in old Emacs versions is nice
    > if you want to do it, but it's not essential for Gnu.

    What is considered "old"?  21.2 and lower?  21.1 and lower?

Anything other than the next Emacs release counts as "old".

    Also I know a lot of effort goes into making Gnus compatible with
    XEmacs.  Is that consistent with your views?

That isn't work that the GNU Project needs, but you can do it if you
like.

Re: Moving files from lisp/gnus/ to lisp/net/?

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     People seem to fear using some files in gnus/ because they think the
>     files might end up loading all of Gnus.  I believe moving some of the
>     self contained files in Gnus elsewhere would be good.  This would make
>     it clear that they aren't an intrinsic part of Gnus.  Not only would
>     it make it clear for elisp programmers, it would make it clear for us
>     working on Gnus.  I.e., to make sure we don't use Gnus functions in
>     some of the files.  I just modified pop3.el to revert one such
>     example.  It would be bad if many standalone files ended up loading
>     Gnus out of pure laziness.
>
> I agree completely.
>
> It makes a big difference for Emacs maintenance whether a file is part
> of Gnus or not.  If it is part of Gnus, it is maintained by the Gnus
> developers, so they might expect to be able to change it without
> looking at how the rest of Emacs uses it.

My impression is that Gnus developers do not need to be able to do
this now, with the new Emacs CVS and emacs-devel list.  And by
synchronizing the files better, it would be possible to avoid
accidental changes.  If anything, moving the files would make it more
likely that changes are reviewed by Emacs developers, which could
avoid some problems in the future.

> We need to consider them one by one, so please don't raise
> them as a big group.  Please propose one file or a few related
> files at a time, and we will think of them.
>
> Right now let's consider only those that there is a specific reason
> to move right now.

OK, I'll think about each file individually.

Move sha1.el and hex-util.el from lisp/gnus/ to lisp/net/ (was: Re: Moving files from lisp/gnus/ to lisp/net/?)

[Simon Josefsson]

The first file is sha1.el.  It is an implementation of an algorithm
very similar to MD5, which is part of Emacs (in C).  It is generally
useful, and not Gnus specific in any way.  The API is stable, the only
API change that I can locate, since the file was created in 1999, was
a new optional parameter to some functions.

The file sha1.el needs hex-util.el, which is a small file to hex
encode strings.  It is similar to base64-*.  If it is possible to do
the same using other functions in Emacs, that may be better.  Please
look at the file and tell.  But it is a small files, that could be
useful elsewhere as well.

Both can be documented in LispRef, it seems.  For SHA1, I can copy the
MD5 node, and for hex-util, I can create something inspired by the
base64 node.

Alternatively, the functions could be documented in emacs-mime.texi's
"Basic Functions".  It document many similar packages already.  I
suggested documenting the new mail-utils functions, proposed in
another thread, in the same manual.  The name "Emacs-MIME" is
confusing though, "Emacs Lisp Mail Handling" or similar would be more
appropriate.

Documenting Mail Handling related functions in emacs-mime.texi instead
of lispref might be good if people think lispref is too large.  I
suspect people interested in mail utilities will be able to find a
different manual.  There could be links from lispref to emacs-mime as
well.

Re: Move sha1.el and hex-util.el from lisp/gnus/ to lisp/net/ (was: Re: Moving files from lisp/gnus/ to lisp/net/?)

[Richard Stallman]

I think moving sha1.el is a good idea.  It may as well be documented
near were MD5 is documented.

    The file sha1.el needs hex-util.el, which is a small file to hex
    encode strings.

These functions don't seem useful enough to make generally available,
but you could rename them and include them in sha1.el.

Re: Move sha1.el and hex-util.el from lisp/gnus/ to lisp/net/

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> I think moving sha1.el is a good idea.  It may as well be documented
> near were MD5 is documented.

OK.

>     The file sha1.el needs hex-util.el, which is a small file to hex
>     encode strings.
>
> These functions don't seem useful enough to make generally available,
> but you could rename them and include them in sha1.el.

The functions in hex-util.el are used by hmac-md5.el, sasl-cram.el,
sasl-digest.el, and sha1.el in Gnus CVS.  Further, at least rfc2104.el
contain re-implementation of the functionality in hex-util.el.
Changing the calls in hmac-md5.el and sasl*.el to call sha1 functions
seem wrong.

Is there a "hex" coding system, or some more native way to hex encode
some data?

If not, I believe hex-util.el do make sense.