Gnus branch

Gnus branch

[Stefan Monnier]

I find the separate branch for Gnus to be inconvenient.  Since it seems the
code already works well as it is, I think it makes more sense to move it to
the trunk right away and to then do "merge left over changes" on the trunk
rather than on the branch.  This way more people will test the new code
earlier and we can keep the branch as a pseudo "vendor branch" (where we
only import unmolested code straight from the Gnus repository but where we
never commit ourselves).

I.e. I suggest we:

    cd emacs/lisp/gnus
    cvs update -A
    cvs tag before-gnus-5_10-switch
    cvs update -j gnus-5_10-branch
    cvs commit -m 'switch to v5_10'

The `tag' command is not srictly necessary since the gnus-5_10-branchpoint
tag is equivalent.  And since no activity took place on the trunk of the
gnus code since the creation of the branch, the `update -j' doesn't generate
any conflict.


        Stefan

Re: Gnus branch

[David Kastrup]

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

> I find the separate branch for Gnus to be inconvenient.  Since it
> seems the code already works well as it is, I think it makes more
> sense to move it to the trunk right away and to then do "merge left
> over changes" on the trunk rather than on the branch.

The idea was not to lose changes that occured in the trunk, right?  If
that more or less is given, then I say, go ahead.  I think the sooner
many testers get their hands on the new Gnus, the better.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Gnus branch

[Richard Stallman]

    The idea was not to lose changes that occured in the trunk, right?

Yes.  The useful changes in the trunk were going to be merged into the
branch.

When that is done, we want to move the new Gnus into trunk.  Is it
done?

Re: Gnus branch

[Reiner Steib]

On Sat, Aug 14 2004, Richard Stallman wrote:

>     The idea was not to lose changes that occured in the trunk, right?
>
> Yes.  The useful changes in the trunk were going to be merged into the
> branch.
>
> When that is done, we want to move the new Gnus into trunk.  Is it
> done?

I have installed your change (mark `mailcap-mime-data' as risky) in
the branch and in the Gnus repository (trunk and v5_10 branch).
Some other (maybe) important changes (by Stefan Monnier, Juanma
Barranquero, Kim F. Storm, Sam Steingold, ...) have not been installed
yet.  (When this is done, I'll import those changes back to the Gnus
repository, too.)

I'm not sure how to handle the ChangeLog entries from Emacs/trunk:

lisp/gnus/ChangeLog has entries from 2004-06-29 back to 1998-08-29.
Most of those are no longer relevant after the import of Gnus v5_10
branch.  Even worse, after installing the ChangeLog entries from Gnus
v5_10 branch (which has to be done), we would have non-monotonic
entries.  Is it okay to move the Emacs/trunk entries to
lisp/gnus/ChangeLog.2 (or should they be removed)?  In
lisp/gnus/ChangeLog, we'd only have the entries belonging to Oort
Gnus aka Gnus 5.10.

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

Re: Gnus branch

[Richard Stallman]

    I'm not sure how to handle the ChangeLog entries from Emacs/trunk:

Assuming that all the changes that we want are in the branch now,
and that the ChangeLog file in that branch describes those changes,
you should copy the ChangeLog file unmodified into the trunk
just as you copy the source files unmodified into the trunk.

However, it sounds like you're saying we have not yet reached that point:

    Some other (maybe) important changes (by Stefan Monnier, Juanma
    Barranquero, Kim F. Storm, Sam Steingold, ...) have not been installed
    yet.

Can you identify these changes and merge the ones we need
into the branch?

Re: Gnus branch

[Stefan Monnier]

>     I'm not sure how to handle the ChangeLog entries from Emacs/trunk:
> Assuming that all the changes that we want are in the branch now,
> and that the ChangeLog file in that branch describes those changes,
> you should copy the ChangeLog file unmodified into the trunk
> just as you copy the source files unmodified into the trunk.

> However, it sounds like you're saying we have not yet reached that point:

>     Some other (maybe) important changes (by Stefan Monnier, Juanma
>     Barranquero, Kim F. Storm, Sam Steingold, ...) have not been installed
>     yet.

> Can you identify these changes and merge the ones we need
> into the branch?

Just to clarify: my suggestion is to first merge the gnus branch on the
trunk and then re-install the local changes that haven't made their way to
the Gnus repository yet.

For clarity of the history (i.e. to make future integration easier) it is
important to have a Gnus branch that only contains code that comes from the
Gnus repository.  So we should either create a second Gnus branch (one for
importing from the repository and a temporary one to do the current
integration work before committing it to the trunk) or instead to just do
the integration work directly on the trunk, which is easier.


        Stefan

Re: Gnus branch

[Richard Stallman]

    Just to clarify: my suggestion is to first merge the gnus branch on the
    trunk and then re-install the local changes that haven't made their way to
    the Gnus repository yet.

This would be a recipe for losing changes.  What I have asked
people to do, and what Reiner offered to do, is to merge our
changes into Gnus in the branch, and only afterward put this
into the trunk.

I do not want our changes to be at any moment lost from the trunk.

Re: Gnus branch

[Reiner Steib]

On Fri, Aug 13 2004, Stefan Monnier wrote:

> I find the separate branch for Gnus to be inconvenient.  [...]
>
> I.e. I suggest we:
>
>     cd emacs/lisp/gnus
[...]
>     cvs update -j gnus-5_10-branch
>     cvs commit -m 'switch to v5_10'

Note that there were also changes in other directories: At least in
lisp/net/, etc/, man/ and the corresponding ChangeLog files.

Bye, Reiner.

P.S.: I already replied to this, but the article
      (<v9llgalpe0.fsf@marauder.physik.uni-ulm.de>) didn't make it to
      the list, AFAICS.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: Gnus branch

[Reiner Steib]

[ I already replied to parts of this article, but my reply
  <v9ekm2n5jp.fsf@marauder.physik.uni-ulm.de> didn't make it to the
  list, AFAICS, but Richard has received it. ]

On Thu, Aug 19 2004, Richard Stallman wrote:

>     I'm not sure how to handle the ChangeLog entries from Emacs/trunk:
>
> Assuming that all the changes that we want are in the branch now,
> and that the ChangeLog file in that branch describes those changes,

I meant the entries for Gnus in the Emacs repository after the import
from the Gnus repository upto the creation of the gnus-5_10-branch.

Richard's answer was:

| You can postdate them to after the date of the Gnus changes that you
| got from the Gnus repository.

Okay.  I will do so.

> you should copy the ChangeLog file unmodified into the trunk
> just as you copy the source files unmodified into the trunk.
>
> However, it sounds like you're saying we have not yet reached that point:

Correct.

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

Re: Gnus branch

[Reiner Steib]

On Thu, Aug 19 2004, Richard Stallman wrote:

>     Some other (maybe) important changes (by Stefan Monnier, Juanma
>     Barranquero, Kim F. Storm, Sam Steingold, ...) have not been installed
>     yet.
>
> Can you identify these changes and merge the ones we need
> into the branch?

I have merged the changes of Sam Steingold into the branch.  Then I
looked at the patches of other (i.e. not Stefan, Juanma, Kim and
Andreas Schwab) people that don't have write access to the Gnus
repository.  Those changes seem to be included in Gnus already.  It
seems that ShengHuo ZHU (and maybe others?) has merged all changes
before 2003-02 already into the Gnus repository.

I have added a file lisp/gnus/TODO to the Gnus branch that contains
the ChangeLog entries from now back to 2003-02.  The TODO file should
help us to keep track of what changes are still "open".

I would like to ask Stefan[1], Juanma, Kim and Andreas to check their
changes and make a little note in the lisp/gnus/TODO file about the
status ("applied", "already fixed", ...) of the change in that file.

When applying a change, please add a note _temporary_ "[Emacs/trunk
YYYY-MM-DD]" into the gnus/ChangeLog file.  I think we can keep track
of the merging easier.  Before merging the Gnus branch back to the
trunk, we will remove these notes.

[1] Stefan, I tried to merge your "Use inhibit-read-only instead of
buffer-read-only." patch (2004-03-22) into `gnus-art.el'.  Many hunks
failed and in the file on the trunk, there are still some let-bound
buffer-read-only variables.  I suppose you did replace
"(buffer-read-only nil)" by "(inhibit-read-only t)" and missed some
stuff like...

  (let ((inhibit-point-motion-hooks t)
	buffer-read-only)
    ...)

I tried to treat those, too.  I hope that I did the right thing and
I'd be happy if you could check if I did it correctly.

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

Re: Gnus branch

[Reiner Steib]

On Mon, Aug 23 2004, Richard Stallman wrote:

>     Note that there were also changes in other directories: At least in
>     lisp/net/, etc/, man/ and the corresponding ChangeLog files.
>
> I am not sure what this means--could you explain?  WHERE are there
> these changes?  In the gnus-5_10-branch?

Yes, in the gnus-5_10-branch.

In detail...

* ./etc:

  NEWS, GNUS-NEWS, gnus.xpm, gnus-pointer.xbm, gnus-pointer.xpm

* ./man:

  emacs-mime.texi, gnus-faq.texi, gnus.texi, message.texi, pgg.texi,
  sieve.texi

  Makefile.in, makefile.w32-in

* ./lisp:

  net/tls.el, calendar/time-date.el

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

Re: Gnus branch

[Richard Stallman]

Merging the changes outside the gnus subdirectory is a separate
operation.  The way to do that is by merging the Gnus changes into the
trunk.  You could start that at any time, as long as the changes won't
break the old Gnus.

Re: Gnus branch

[Reiner Steib]

On Tue, Aug 24 2004, Richard Stallman wrote:

> Merging the changes outside the gnus subdirectory is a separate
> operation.  The way to do that is by merging the Gnus changes into the
> trunk.  You could start that at any time, as long as the changes won't
> break the old Gnus.

Adding the Gnus related man/*.texi files (and the related changes in
Makefile.in/makefile.w32-in) to the trunk would lead to
inconsistencies.  The documentation would not correspond to the Gnus
code on the trunk.  I don't think this is a good idea.
Similar for etc/*NEWS.

The changes in net/tls.el and calendar/time-date.el are minor and can
safely be installed on the trunk.

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

Re: Gnus branch

[Richard Stallman]

    Adding the Gnus related man/*.texi files (and the related changes in
    Makefile.in/makefile.w32-in) to the trunk would lead to
    inconsistencies.  The documentation would not correspond to the Gnus
    code on the trunk.  I don't think this is a good idea.
    Similar for etc/*NEWS.

I don't think it is a problem to have those inconsistencies temporarily,
but you can also wait and do these after the new Gnus files go in.

The point is that these files need to be merged *into* the trunk.

Re: Gnus branch

[Reiner Steib]

On Thu, Aug 19 2004, Richard Stallman wrote:

>     Some other (maybe) important changes (by Stefan Monnier, Juanma
>     Barranquero, Kim F. Storm, Sam Steingold, ...) have not been installed
>     yet.
>
> Can you identify these changes and merge the ones we need
> into the branch?

I went through the ChangeLog and I have installed the remaining
changes from the Emacs trunk into the Gnus branch in the meantime.  By
merging the gnus-5_10-branch into the trunk now, we won't lose any
relevant changes from the Emacs trunk to the best of my knowledge.

If you agree, I could merge the gnus-5_10-branch to the trunk in the
next days.

If someone who is more familiar with CVS branches and merging, he can
do it instead of me (don't forget the files outside of lisp/gnus[1]).
Else, I will try to follow Stefan's suggestion:

    cd emacs/lisp/gnus
    cvs update -A
    cvs tag before-gnus-5_10-switch
    cvs update -j gnus-5_10-branch
    cvs commit -m 'switch to v5_10'

(... and similar for the other directories.)

Bye, Reiner.

[1] See http://article.gmane.org/gmane.emacs.devel/26426
    <news:v98yc6ouy0.fsf@marauder.physik.uni-ulm.de>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus branch

[Katsumi Yamaoka]

>>>>> In <v93c24e1ky.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

> If you agree, I could merge the gnus-5_10-branch to the trunk in the
> next days.

Could you please apply the patch which I made only in cvs.gnus.org
into the gnus-5_10-branch before merging it into the trunk?
The precise patch is here:

http://www.jpl.org/ftp/pub/tmp/gnus-5_10-branch.patch.gz
 or ftp://ftp.jpl.org/pub/tmp/gnus-5_10-branch.patch.gz

The patch will be applied to the following modules:

lisp/gnus/ChangeLog
lisp/gnus/gnus-agent.el
lisp/gnus/gnus-art.el
lisp/gnus/gnus-cite.el
lisp/gnus/gnus-cus.el
lisp/gnus/gnus-eform.el
lisp/gnus/gnus-group.el
lisp/gnus/gnus-msg.el
lisp/gnus/gnus-score.el
lisp/gnus/gnus-spec.el
lisp/gnus/gnus-sum.el
lisp/gnus/gnus-util.el
lisp/gnus/gnus.el
lisp/gnus/mail-source.el
lisp/gnus/message.el
lisp/gnus/mm-decode.el
lisp/gnus/mm-encode.el
lisp/gnus/mm-util.el
lisp/gnus/mm-view.el
lisp/gnus/nndoc.el
lisp/gnus/nnmail.el
lisp/gnus/score-mode.el
lisp/gnus/webmail.el
man/ChangeLog
man/emacs-mime.texi
man/gnus.texi

Thanks in advance.

Re: Gnus branch

[Richard Stallman]

    I went through the ChangeLog and I have installed the remaining
    changes from the Emacs trunk into the Gnus branch in the meantime.  By
    merging the gnus-5_10-branch into the trunk now, we won't lose any
    relevant changes from the Emacs trunk to the best of my knowledge.

    If you agree, I could merge the gnus-5_10-branch to the trunk in the
    next days.

Ok, please do.

Re: Gnus branch

[Miles Bader]

On Mon, Aug 30, 2004 at 11:51:57PM +0200, Reiner Steib wrote:
> If you agree, I could merge the gnus-5_10-branch to the trunk in the
> next days.

Actually could you let me do it?

Thanks,

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

Re: Gnus branch

[Katsumi Yamaoka]

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

>>>>> In <b9yhdqktcjk.fsf@jpl.org> Katsumi Yamaoka wrote:

>>>>>> In <v93c24e1ky.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

>> If you agree, I could merge the gnus-5_10-branch to the trunk in the
>> next days.

> Could you please apply the patch which I made only in cvs.gnus.org
> into the gnus-5_10-branch before merging it into the trunk?

Thank you very much for the work!

I'm sorry to bother you, but could you apply one more patch?
It is surely a bugfix, which is already in No Gnus.  You may do
it after moving to the trunk of course.  Here it is:

(Although I'm not familiar with spam-stat.el, it seems the
ChangeLog in No Gnus suggests other bug fixes are there.)

2004-01-24  Hiroshi Fujishima <pooh@nature.tsukuba.ac.jp>  (tiny change)

	* spam-stat.el (spam-stat-reduce-size): Set spam-stat-dirty.
	(spam-stat-save): Accept prefix argument.


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

*** spam-stat.el~	Thu Jul 22 16:45:51 2004
--- spam-stat.el	Tue Aug 31 09:06:34 2004
***************
*** 1,6 ****
  ;;; spam-stat.el --- detecting spam based on statistics
  
! ;; Copyright (C) 2002, 2003 Free Software Foundation, Inc.
  
  ;; Author: Alex Schroeder <alex@gnu.org>
  ;; Keywords: network
--- 1,6 ----
  ;;; spam-stat.el --- detecting spam based on statistics
  
! ;; Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc.
  
  ;; Author: Alex Schroeder <alex@gnu.org>
  ;; Keywords: network
***************
*** 396,403 ****
  ;; Saving and Loading
  
  (defun spam-stat-save (&optional force)
!   "Save the `spam-stat' hash table as lisp file."
!   (interactive)
    (when (or force spam-stat-dirty)
      (with-temp-buffer
        (let ((standard-output (current-buffer))
--- 396,404 ----
  ;; Saving and Loading
  
  (defun spam-stat-save (&optional force)
!   "Save the `spam-stat' hash table as lisp file.
! With a prefix argument save unconditionally."
!   (interactive "P")
    (when (or force spam-stat-dirty)
      (with-temp-buffer
        (let ((standard-output (current-buffer))
***************
*** 571,577 ****
  			 (spam-stat-bad entry))
  		      count)
  	       (remhash key spam-stat)))
! 	   spam-stat))
  
  (defun spam-stat-install-hooks-function ()
    "Install the spam-stat function hooks"
--- 572,579 ----
  			 (spam-stat-bad entry))
  		      count)
  	       (remhash key spam-stat)))
! 	   spam-stat)
!   (setq spam-stat-dirty t))
  
  (defun spam-stat-install-hooks-function ()
    "Install the spam-stat function hooks"

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


Thanks in advance.

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

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

Re: Gnus branch

[Reiner Steib]

On Wed, Sep 01 2004, Richard Stallman wrote:

>     I went through the ChangeLog and I have installed the remaining
>     changes from the Emacs trunk into the Gnus branch in the meantime.  By
>     merging the gnus-5_10-branch into the trunk now, we won't lose any
>     relevant changes from the Emacs trunk to the best of my knowledge.
>
>     If you agree, I could merge the gnus-5_10-branch to the trunk in the
>     next days.
>
> Ok, please do.

On Wed, Sep 01 2004, Miles Bader wrote:

> Actually could you let me do it?

Sure!

Could you also sync future changes from the Gnus repository (v5-10
branch) to Emacs' trunk (and back)?  IIRC, you mentioned previously
that this could be done quite conveniently using your arch
repositories.

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

Gnus 5.10 is now on the trunk

[Miles Bader]

Be warned...

The before/after tags are: before-merge-gnus-5_10 and after-merge-gnus-5_10.
Note that before-merge-gnus-5_10 is slightly incorrect due to CVS's lovely
non-atomic behavior.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Gnus 5.10 is now on the trunk

[Reiner Steib]

On Sat, Sep 04 2004, Miles Bader wrote:

[ Gnus 5.10 is now on the trunk ]

Thanks!

Do you plan to sync further changes from Gnus v5-10 branch to the
trunk (semi-) automatically via arch?

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

Re: Gnus 5.10 is now on the trunk

[Miles Bader]

On Sun, Sep 05, 2004 at 07:45:36PM +0200, Reiner Steib wrote:
> Do you plan to sync further changes from Gnus v5-10 branch to the
> trunk (semi-) automatically via arch?

Yes; I've already merged the remaining changes from the Gnus v5-10 branch.

Merging any future changes from the Gnus v5-10 branch should be very easy
using arch (because the Gnus tree is largly a subset of the Emacs tree, so
Gnus changesets largely just apply directly), so I will keep an eye out for
those, and apply them to Emacs too.

I wonder about merging future Emacs Gnus changes into the Gnus tree though --
is there a plan for handling this?  Since they're fairly rare it would be
nice to have a policy in place to avoid the mess of the previous merge.

Thanks,

-Miles
-- 
Run away!  Run away!

Re: Gnus 5.10 is now on the trunk

[Sam Steingold]

I noticed that the gnus mode line now has a blank 2x2 square instead of
the 1x1 gnus logo image (this also has a side effect of making the mode
line height 2).

does anyone else see that?

(woe32, msvc)

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
MS Windows: error: the operation completed successfully.

Re: Gnus 5.10 is now on the trunk

[Miles Bader]

Sam Steingold <sds@gnu.org> writes:
> I noticed that the gnus mode line now has a blank 2x2 square instead of
> the 1x1 gnus logo image (this also has a side effect of making the mode
> line height 2).
>
> does anyone else see that?

I haven't yet switched over to the trunk version of Gnus (I briefly
tested that the trunk merge at least started properly, but only in a
non-X version of Emacs), however the mode-line logo does work properly
in the independently packaged Gnus 5.10.6.

One thing that comes to mind is that the Gnus image files were moved
from etc/ to lisp/gnus/, and it's possible that some code is still
looking for them in the old location.

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

Re: Gnus 5.10 is now on the trunk

[Reiner Steib]

On Mon, Sep 06 2004, Miles Bader wrote:

> Sam Steingold <sds@gnu.org> writes:
>> I noticed that the gnus mode line now has a blank 2x2 square instead of
>> the 1x1 gnus logo image (this also has a side effect of making the mode
>> line height 2).
>>
>> does anyone else see that?

I don't see it here.  What is the value of
`gnus-mode-line-image-cache' on your system?

> One thing that comes to mind is that the Gnus image files were moved
> from etc/ to lisp/gnus/, and it's possible that some code is still
> looking for them in the old location.

I have placed the new (or changed) images in lisp/gnus/.  This is the
location where most images lived before the merge (i.e. in Gnus 5.9).

But I think it would be better to move the files lisp/gnus/*.[px][bp]m
to etc/gnus/ [1] and etc/smilies/ [2].  Currently, the smilies images
aren't found.

Bye, Reiner.

[1] See `smiley-regexp-alist'.

[2] Files for the tool-bars and maybe more.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Gnus 5.10 is now on the trunk

[Sam Steingold]

> * Reiner Steib <4.hpr.03.e.f@aheshrefcnz.qr> [2004-09-06 19:58:29 +0200]:
>
> On Mon, Sep 06 2004, Miles Bader wrote:
>
>> Sam Steingold <sds@gnu.org> writes:
>>> I noticed that the gnus mode line now has a blank 2x2 square instead of
>>> the 1x1 gnus logo image (this also has a side effect of making the mode
>>> line height 2).
>>>
>>> does anyone else see that?
>
> I don't see it here.  What is the value of
> `gnus-mode-line-image-cache' on your system?

gnus-mode-line-image-cache
(image :type xbm :file "d:/gnu/emacs/etc/gnus-pointer.xbm" :ascent center)
indeed the above file is not there (this is a CVS head).
so, I now understand why the box is empty.

why is it 2x2?

Thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Parachute for sale, used once, never opened, small stain.

Re: Gnus 5.10 is now on the trunk

[Miles Bader]

On Mon, Sep 06, 2004 at 07:58:29PM +0200, Reiner Steib wrote:
> > One thing that comes to mind is that the Gnus image files were moved
> > from etc/ to lisp/gnus/, and it's possible that some code is still
> > looking for them in the old location.
> 
> I have placed the new (or changed) images in lisp/gnus/.  This is the
> location where most images lived before the merge (i.e. in Gnus 5.9).
> 
> But I think it would be better to move the files lisp/gnus/*.[px][bp]m
> to etc/gnus/ [1] and etc/smilies/ [2].  Currently, the smilies images
> aren't found.

We should come up with some sort of consistent rule for where lisp-package
image files go -- currently it seems kinda random: some packages
(e.g. toolbar) put their images in the lisp directory with the code, some
(previously gnus, and currently only "tree-widget") put them in etc/.

If they're to go in etc/, it would be nice if they went in to a sub-hierarchy
that strictly mirrored the correspodning lisp dirs, to make them easier to
find (for a hacker, not for the code :-).

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: Gnus 5.10 is now on the trunk

[Richard Stallman]

    Do you plan to sync further changes from Gnus v5-10 branch to the
    trunk (semi-) automatically via arch?

I see no need to continue installing any changes in the Emacs branch
for Gnus v5-10.  Now that the latest Gnus is installed in the Emacs
trunk, any further Gnus changes ought to be installed directly in the
Emacs trunk.  The branch has served its purpose.

Or perhaps have I misunderstood your question?

Miles wrote:

    I wonder about merging future Emacs Gnus changes into the Gnus
    tree though -- is there a plan for handling this?  Since they're
    fairly rare it would be nice to have a policy in place to avoid
    the mess of the previous merge.

Can someone who works on Gnus development undertake this
responsibility?

Re: Gnus 5.10 is now on the trunk

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     Do you plan to sync further changes from Gnus v5-10 branch to the
>     trunk (semi-) automatically via arch?
>
> I see no need to continue installing any changes in the Emacs branch
> for Gnus v5-10.  Now that the latest Gnus is installed in the Emacs
> trunk, any further Gnus changes ought to be installed directly in the
> Emacs trunk.  The branch has served its purpose.

Right, that's what I meant; I think by `Gnus v5-10 branch,' Reiner was
referring to the branch in the Gnus CVS tree, not the Emacs CVS branch
used for this merge -- the version merged into emacs is not the Gnus
CVS trunk, but rather the latest stable branch of Gnus.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Gnus 5.10 is now on the trunk

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Miles wrote:
>
>     I wonder about merging future Emacs Gnus changes into the Gnus
>     tree though -- is there a plan for handling this?  Since they're
>     fairly rare it would be nice to have a policy in place to avoid
>     the mess of the previous merge.
>
> Can someone who works on Gnus development undertake this
> responsibility?

I was thinking about setting up something that notices Gnus-related
changes from the Emacs cvs diff mailing list and would forward those
changes to the Gnus mailing list, or the like.  That should ensure
that Gnus maintainers would take note of the changes.

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

Re: Gnus 5.10 is now on the trunk

[Kim F. Storm]

The following gnus related variables do not have a :group (or
:variable-group) declaration, so they end up in the 'nil' group:

gnus-parameter-to-address-alist
gnus-parameter-go-list-alist
gnus-parameter-subscribed-alist
gnus-parameter-large-newsgroup-initial-alist
mml-signencrypt-style-alist
nntp-authinfo-file
mml2015-unabbrev-trust-alist

Can you pls. advise which group each of these belong to ?

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

Re: Gnus 5.10 is now on the trunk

[Richard Stallman]

    I was thinking about setting up something that notices Gnus-related
    changes from the Emacs cvs diff mailing list and would forward those
    changes to the Gnus mailing list, or the like.  That should ensure
    that Gnus maintainers would take note of the changes.

That would work, and I could ask our sysadmins to set it up.

Another method you could employ is to maintain your own a checkout of
our repository, have a demon update it every day, and diff it against
the previous version.  One advantage of this is that you can set it up
on any machine, without needing our sysadmins to do it.

Re: Gnus 5.10 is now on the trunk

[Richard Stallman]

    Right, that's what I meant; I think by `Gnus v5-10 branch,' Reiner was
    referring to the branch in the Gnus CVS tree, not the Emacs CVS branch
    used for this merge -- the version merged into emacs is not the Gnus
    CVS trunk, but rather the latest stable branch of Gnus.

I think the Gnus developers should install into Emacs whatever fixes
they make.

Re: Gnus 5.10 is now on the trunk

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> Another method you could employ is to maintain your own a checkout of
> our repository, have a demon update it every day, and diff it against
> the previous version.  One advantage of this is that you can set it up
> on any machine, without needing our sysadmins to do it.

Yes, that's probably the best.  Or I could add some sort of filter
to Gmane, which gets the Emacs CVS diffs...

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

defcustoms without group declaration (was: Gnus 5.10 is now on the trunk)

[Reiner Steib]

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

[ Including <ding@gnus.org> ]

On Tue, Sep 07 2004, Kim F. Storm wrote:

> The following gnus related variables do not have a :group (or
> :variable-group) declaration, so they end up in the 'nil' group:
>
> gnus-parameter-to-address-alist
> gnus-parameter-go-list-alist
> gnus-parameter-subscribed-alist
> gnus-parameter-large-newsgroup-initial-alist
> mml-signencrypt-style-alist
> nntp-authinfo-file
> mml2015-unabbrev-trust-alist
>
> Can you pls. advise which group each of these belong to ?

Thanks for pointing this out.  I have commit the attached patch.  If
someone has a better suggestion, please speak up.


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

cvs diff: Diffing .
Index: ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/ChangeLog,v
retrieving revision 1.253
diff -u -r1.253 ChangeLog
--- ChangeLog	7 Sep 2004 03:47:58 -0000	1.253
+++ ChangeLog	8 Sep 2004 18:17:09 -0000
@@ -1,3 +1,19 @@
+2004-09-08  Reiner Steib  <Reiner.Steib@gmx.de>
+
+	* nntp.el (nntp): New customization group.
+	(nntp-authinfo-file): Added customization group.
+
+	* mml2015.el (mml2015-unabbrev-trust-alist): Added customization
+	group.
+
+	* mml-sec.el (mml-signencrypt-style-alist): Ditto.
+
+	* gnus.el (to-address, to-list, subscribed)
+	(large-newsgroup-initial): Ditto.
+
+	* flow-fill.el (fill-flowed-display-column)
+	(fill-flowed-encode-column): Ditto.
+
 2004-09-06  Stefan  <monnier@iro.umontreal.ca>
 
 	* message.el (message-tokenize-header, message-send-mail-with-qmail):
Index: flow-fill.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/flow-fill.el,v
retrieving revision 1.5
diff -u -r1.5 flow-fill.el
--- flow-fill.el	4 Sep 2004 13:13:43 -0000	1.5
+++ flow-fill.el	8 Sep 2004 18:17:09 -0000
@@ -56,6 +56,7 @@
 (defcustom fill-flowed-display-column 'fill-column
   "Column beyond which format=flowed lines are wrapped, when displayed.
 This can be a Lisp expression or an integer."
+  :group 'mime-display
   :type '(choice (const :tag "Standard `fill-column'" fill-column)
 		 (const :tag "Fit Window" (- (window-width) 5))
 		 (sexp)
@@ -65,6 +66,7 @@
   "Column beyond which format=flowed lines are wrapped, in outgoing messages.
 This can be a Lisp expression or an integer.
 RFC 2646 suggests 66 characters for readability."
+  :group 'mime-display
   :type '(choice (const :tag "Standard fill-column" fill-column)
 		 (const :tag "RFC 2646 default (66)" 66)
 		 (sexp)
Index: gnus.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/gnus.el,v
retrieving revision 1.28
diff -u -r1.28 gnus.el
--- gnus.el	4 Sep 2004 13:13:43 -0000	1.28
+++ gnus.el	8 Sep 2004 18:17:10 -0000
@@ -1599,6 +1599,7 @@
  "Return GROUP's to-address."
  :variable-document
  "*Alist of group regexps and correspondent to-addresses."
+ :variable-group gnus-group-parameter
  :parameter-type '(gnus-email-address :tag "To Address")
  :parameter-document "\
 This will be used when doing followups and posts.
@@ -1625,6 +1626,7 @@
  "Return GROUP's to-list."
  :variable-document
  "*Alist of group regexps and correspondent to-lists."
+ :variable-group gnus-group-parameter
  :parameter-type '(gnus-email-address :tag "To List")
  :parameter-document "\
 This address will be used when doing a `a' in the group.
@@ -1643,6 +1645,7 @@
  "Return GROUP's subscription status."
  :variable-document
  "*Groups which are automatically considered subscribed."
+ :variable-group gnus-group-parameter
  :parameter-type '(const :tag "Subscribed" t)
  :parameter-document "\
 Gnus assumed that you are subscribed to the To/List address.
@@ -1749,6 +1752,7 @@
  "Return GROUP's initial input of the number of articles."
  :variable-document
  "*Alist of group regexps and its initial input of the number of articles."
+ :variable-group gnus-group-parameter
  :parameter-type '(choice :tag "Initial Input for Large Newsgroup"
 			  (const :tag "All" nil)
 			  (integer))
Index: mml-sec.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/mml-sec.el,v
retrieving revision 1.2
diff -u -r1.2 mml-sec.el
--- mml-sec.el	4 Sep 2004 13:13:43 -0000	1.2
+++ mml-sec.el	8 Sep 2004 18:17:11 -0000
@@ -83,6 +83,7 @@
 understood by all PGP implementations, in particular PGP version
 2 does not support it!  See Info node `(message)Security' for
 details."
+  :group 'message
   :type '(repeat (list (choice (const :tag "S/MIME" "smime")
 			       (const :tag "PGP" "pgp")
 			       (const :tag "PGP/MIME" "pgpmime")
Index: mml2015.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/mml2015.el,v
retrieving revision 1.2
diff -u -r1.2 mml2015.el
--- mml2015.el	4 Sep 2004 13:13:43 -0000	1.2
+++ mml2015.el	8 Sep 2004 18:17:11 -0000
@@ -83,6 +83,7 @@
     ("TRUST_FULLY"     . t)
     ("TRUST_ULTIMATE"  . t))
   "Map GnuPG trust output values to a boolean saying if you trust the key."
+  :group 'mime-security
   :type '(repeat (cons (regexp :tag "GnuPG output regexp")
 		       (boolean :tag "Trust key"))))
 
Index: nntp.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/nntp.el,v
retrieving revision 1.22
diff -u -r1.22 nntp.el
--- nntp.el	4 Sep 2004 13:13:44 -0000	1.22
+++ nntp.el	8 Sep 2004 18:17:11 -0000
@@ -34,6 +34,10 @@
 
 (eval-when-compile (require 'cl))
 
+(defgroup nntp nil
+  "NNTP access for Gnus."
+  :group 'gnus)
+
 (defvoo nntp-address nil
   "Address of the physical nntp server.")
 
@@ -182,6 +186,7 @@
 
 (defcustom nntp-authinfo-file "~/.authinfo"
   ".netrc-like file that holds nntp authinfo passwords."
+  :group 'nntp
   :type
   '(choice file
 	   (repeat :tag "Entries"

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


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

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

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

Re: Gnus 5.10 is now on the trunk

[Miles Bader]

FWIW, I've gotten around to switching to the new in-tree Gnus (I
uninstalled my previous Gnus 5.10 installation), and everything seems to
work fine, including the Gnus mode-line icon.

BTW, aren't we supposed to change the version number to "5.11" now?

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

Gnus image problem (was: Gnus 5.10 is now on the trunk)

[Reiner Steib]

On Tue, Sep 07 2004, Sam Steingold wrote:

>> I don't see it here.  What is the value of
>> `gnus-mode-line-image-cache' on your system?
>
> gnus-mode-line-image-cache
> (image :type xbm :file "d:/gnu/emacs/etc/gnus-pointer.xbm" :ascent center)
> indeed the above file is not there (this is a CVS head).

Strange, it should be nil if the image is not found (see gnus.el):

(setq gnus-mode-line-image-cache
      (find-image
       '((:type xpm :file "gnus-pointer.xpm"
		:ascent center)
	 (:type xbm :file "gnus-pointer.xbm"
		:ascent center))))

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

Where to put images for lisp packages? (was: Gnus 5.10 is now on the trunk)

[Reiner Steib]

On Tue, Sep 07 2004, Miles Bader wrote:

> On Mon, Sep 06, 2004 at 07:58:29PM +0200, Reiner Steib wrote:
[...]
>> I have placed the new (or changed) images in lisp/gnus/.  This is the
>> location where most images lived before the merge (i.e. in Gnus 5.9).
>> 
>> But I think it would be better to move the files lisp/gnus/*.[px][bp]m
>> to etc/gnus/ [1] and etc/smilies/ [2].  Currently, the smilies images
>> aren't found.
>
> We should come up with some sort of consistent rule for where lisp-package
> image files go -- currently it seems kinda random: [...]

I agree.

> If they're to go in etc/, it would be nice if they went in to a
> sub-hierarchy that strictly mirrored the correspodning lisp dirs, to
> make them easier to find (for a hacker, not for the code :-).

"strictly" would require minor changes in `smilies.el': Look in
etc/gnus instead of etc/smilies.

On Thu, Sep 09 2004, Miles Bader wrote:

> FWIW, I've gotten around to switching to the new in-tree Gnus (I
> uninstalled my previous Gnus 5.10 installation), and everything seems to
> work fine, including the Gnus mode-line icon.

Do you see these test smilies as images (when
`gnus-treat-display-smileys' is non-nil)?

| Test smileys:  :-) :-\ :-( :-/

For me, `smiley-data-directory' is nil and no graphical smilies are
displayed:

,----
| (defcustom smiley-data-directory (nnheader-find-etc-directory "smilies")
|   "*Location of the smiley faces files."
`----

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

Gnus version numbers (was: Gnus 5.10 is now on the trunk)

[Reiner Steib]

On Thu, Sep 09 2004, Miles Bader wrote:

> BTW, aren't we supposed to change the version number to "5.11" now?

I also thought about this.

I propose to add another minor version number: Let us set it to 5.11.1
now.  After the release of Emacs 21.4, increase it again to 5.11.2 and
so on, so that each Emacs release also has a different Gnus version
(unless there are no changes in the Gnus code and manuals, maybe).

Rationale: In Emacs 21.1-21.3 all Gnus versions had 5.9 although the
Gnus version had significant differences.
E.g. `mm-coding-system-priorities' has been introduced in Emacs 21.2.
I don't remember how often I typed "if you have Gnus 5.9 that comes
with Emacs 21.2 or later you can set `mm-coding-system-priorities'
...".

Additionally, each time a new Emacs version is released, we could
release an unbundled Gnus version from the Gnus v5-10 branch.
Assuming that Gnus in Emacs' CVS and the Gnus v5-10 branch in sync, of
course.  Lars, WDYT?

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

Re: Gnus version numbers

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> Additionally, each time a new Emacs version is released, we could
> release an unbundled Gnus version from the Gnus v5-10 branch.
> Assuming that Gnus in Emacs' CVS and the Gnus v5-10 branch in sync, of
> course.  Lars, WDYT?

Sounds good.

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

Re: Where to put images for lisp packages?

[Miles Bader]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>> If they're to go in etc/, it would be nice if they went in to a
>> sub-hierarchy that strictly mirrored the correspodning lisp dirs, to
>> make them easier to find (for a hacker, not for the code :-).
>
> "strictly" would require minor changes in `smilies.el': Look in
> etc/gnus instead of etc/smilies.

What about moving the standalone Gnus to do the same thing?

I'd actually go farther and put _all_ images in something like
`etc/images/' (with further subdirs like `etc/images/gnus/' etc).
In the past I've always found finding image files for a package, or
alternatively, finding which package uses a particular image file, very
annoying because of the current randomness.

> Do you see these test smilies as images (when
> `gnus-treat-display-smileys' is non-nil)?

Hmmm, indeed I don't...

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Gnus version numbers

[Reiner Steib]

On Thu, Sep 09 2004, Lars Magne Ingebrigtsen wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>
>> Additionally, each time a new Emacs version is released, we could
>> release an unbundled Gnus version from the Gnus v5-10 branch.
>> Assuming that Gnus in Emacs' CVS and the Gnus v5-10 branch in sync, of
>> course.  Lars, WDYT?
>
> Sounds good.

One possible problem with using the additional minor number (5.11.1
instead of 5.11) is that `gnus-continuum-version' of 5.11.1 is greater
than that of all No Gnus versions:

ELISP> (gnus-continuum-version "No Gnus v0.3")
5.110003
ELISP> (gnus-continuum-version "Gnus v5.11.1")
5.1101
ELISP> (gnus-continuum-version "Gnus v5.11")
5.11

I don't know how problematic this would be, but I would think that all
No Gnus versions should be higher than the 5.11* versions.  A simple
(but ugly?) solution would be to change the set the version to
5.11MMNN for "No Gnus v0.NN" with MM in (01...99).

With MM=90: "No Gnus v0.3"  ==> 5.119003
            "No Gnus v0.12" ==> 5.119012

With MM=99: "No Gnus v0.3"  ==> 5.119903
            "No Gnus v0.12" ==> 5.119912

Might be a little confusion for the user, but I don't think that users
are supposed to look at the continuum version at all.

Other suggestions?

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

Re: Gnus version numbers

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> One possible problem with using the additional minor number (5.11.1
> instead of 5.11) is that `gnus-continuum-version' of 5.11.1 is greater
> than that of all No Gnus versions:

Perhaps it's just simpler to name the version in Emacs 5.11 (without
any further numbering), since that's what's been done traditionally.

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

Re: Gnus version numbers

[Stefan Monnier]

> One possible problem with using the additional minor number (5.11.1
> instead of 5.11) is that `gnus-continuum-version' of 5.11.1 is greater
> than that of all No Gnus versions:

Seeing how the Gnus and Emacs code are now "the same", I think we may as
well call Emacs's Gnus code "5.10.1" (or some such).

Why use a different number and then have to explain "5.11 is just the same
as 5.10 except it's the version that comes with Emacs".


        Stefan

Re: Gnus version numbers

[Lars Magne Ingebrigtsen]

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

> Why use a different number and then have to explain "5.11 is just the same
> as 5.10 except it's the version that comes with Emacs".

Because that's the way we've always done it before.  :-)

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

Re: Gnus version numbers

[Reiner Steib]

On Fri, Sep 10 2004, Reiner Steib wrote:

> One possible problem with using the additional minor number (5.11.1
> instead of 5.11) is that `gnus-continuum-version' of 5.11.1 is greater
> than that of all No Gnus versions: [...]

How about modifying `gnus-continuum-version' a little...

--8<---------------cut here---------------start------------->8---
      (string-to-number
       (cond
	((zerop major) ;; development version
	 (format "%s00%02d%02d"
		 [...])
	((= 1 (% minor 2)) ;; Emacs bundled version
	 (format "%d.%02d0000%02d" major minor least))
	(t ;; non-bundled release
	 (format "%d.%02d%02d" major minor least))))
--8<---------------cut here---------------end--------------->8---

... so that we'd get:

ELISP> (gnus-continuum-version "No Gnus v0.3")
5.110003
ELISP> (gnus-continuum-version "Gnus v5.11.1")
5.11000001
ELISP> (gnus-continuum-version "Gnus v5.11.2")
5.11000002
ELISP> (gnus-continuum-version "Gnus v5.10.6")
5.1006

Without the minor number, we would get:

ELISP> (gnus-continuum-version "Gnus v5.11")
5.11

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

Re: Gnus version numbers

[Lars Magne Ingebrigtsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> How about modifying `gnus-continuum-version' a little...

Modifying that function won't help older versions get this right.
(It's mainly used for seeing whether .newsrc.eld files need upgrading
or not.)

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

Re: Gnus version numbers

[Per Abrahamsen]

Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:

> I propose to add another minor version number: Let us set it to 5.11.1
> now.

The only information the version number for the bundled Gnus need to
contain, is that it *is* the bundled version.  Everything else can be
obtained from the Emacs version number.

Thus 5.11 is both traditional and (more than) sufficient.

Re: Where to put images for lisp packages?

[Reiner Steib]

On Fri, Sep 10 2004, Miles Bader wrote:

> Reiner Steib <4.uce.03.r.s@nurfuerspam.de> writes:
>>> If they're to go in etc/, it would be nice if they went in to a
>>> sub-hierarchy that strictly mirrored the correspodning lisp dirs, to
>>> make them easier to find (for a hacker, not for the code :-).
>>
>> "strictly" would require minor changes in `smilies.el': Look in
>> etc/gnus instead of etc/smilies.
>
> What about moving the standalone Gnus to do the same thing?

Sure.

> I'd actually go farther and put _all_ images in something like
> `etc/images/' (with further subdirs like `etc/images/gnus/' etc).

I'm not familiar with the way images should be found in Emacs.  But at
least Gnus doesn't seems to use a uniform method for finding the image
directories.  See `mm-image-load-path' (for the tool bars),
`smiley.el', `gnus-picon.el', the function
`gnus-group-startup-message', the use of `gnus-pointer.xpm', ...

After...

$ mkdir -p etc/images/gnus
$ mv lisp/gnus/*.[px][pb]? etc/images/gnus
$ mv etc/gnus*.[px][pb]?   etc/images/gnus

... and the following patch, all Gnus images (splash, mode-line,
smilies, tool bar) are found.

--8<---------------cut here---------------start------------->8---
Index: gnus.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/gnus.el,v
retrieving revision 1.30
diff -u -r1.30 gnus.el
--- gnus.el	20 Sep 2004 12:03:04 -0000	1.30
+++ gnus.el	23 Sep 2004 16:05:06 -0000
@@ -325,7 +325,8 @@
   (defvar gnus-mode-line-image-cache t)
   (if (fboundp 'find-image)
       (defun gnus-mode-line-buffer-identification (line)
-	(let ((str (car-safe line)))
+	(let ((str (car-safe line))
+	      (load-path (mm-image-load-path)))
 	  (if (and (stringp str)
 		   (string-match "^Gnus:" str))
 	      (progn (add-text-properties
@@ -874,7 +875,7 @@
    ((and
      (fboundp 'find-image)
      (display-graphic-p)
-     (let* ((data-directory (nnheader-find-etc-directory "gnus"))
+     (let* ((data-directory (nnheader-find-etc-directory "images/gnus"))
 	    (image (find-image
 		    `((:type xpm :file "gnus.xpm"
 			     :color-symbols
Index: mm-util.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/mm-util.el,v
retrieving revision 1.31
diff -u -r1.31 mm-util.el
--- mm-util.el	20 Sep 2004 12:03:04 -0000	1.31
+++ mm-util.el	23 Sep 2004 16:05:06 -0000
@@ -788,7 +788,7 @@
       (if (file-directory-p
 	   (setq dir (concat (file-name-directory
 			      (directory-file-name path))
-			     "etc/" (or package "gnus/"))))
+			     "etc/images/" (or package "gnus/"))))
 	  (push dir result))
       (push path result))))
 
Index: smiley.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/smiley.el,v
retrieving revision 1.3
diff -u -r1.3 smiley.el
--- smiley.el	20 Sep 2004 12:03:05 -0000	1.3
+++ smiley.el	23 Sep 2004 16:05:06 -0000
@@ -44,7 +44,7 @@
   :group 'gnus-visual)
 
 ;; Maybe this should go.
-(defcustom smiley-data-directory (nnheader-find-etc-directory "smilies")
+(defcustom smiley-data-directory (nnheader-find-etc-directory "images/gnus")
   "*Location of the smiley faces files."
   :type 'directory
   :group 'smiley)
--8<---------------cut here---------------end--------------->8---

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

Re: Where to put images for lisp packages?

[Reiner Steib]

On Thu, Sep 23 2004, Reiner Steib wrote:

> After...
>
> $ mkdir -p etc/images/gnus
> $ mv lisp/gnus/*.[px][pb]? etc/images/gnus
> $ mv etc/gnus*.[px][pb]?   etc/images/gnus
>
> ... and the following patch, all Gnus images (splash, mode-line,
> smilies, tool bar) are found.

I would like to install this patch (see previous message or
http://article.gmane.org/gmane.emacs.devel/27497) and move the image
files as described above.

Miles, would it be better to move the files via arch or should I
simply use the normal CVS procedure (remove and add)?

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

Re: Where to put images for lisp packages?

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> I would like to install this patch (see previous message or
> http://article.gmane.org/gmane.emacs.devel/27497) and move the image
> files as described above.
>
> Miles, would it be better to move the files via arch or should I
> simply use the normal CVS procedure (remove and add)?

It _should_ end up having the same effect, modulo exact log entry contents
etc. -- the CVS/arch gateway tries to detect such add/deletes and turn them
into real moves -- but I'd feel a bit more comfortable doing it myself from
arch.  Maybe it's just the control-freak in me... :-/

BTW, should smilies really go in "images/gnus"?  How about "images/smilies",
so other packages could (theoretically) use them (I don't know what, but
some kind of IM client or whatever might want too...)?

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: Where to put images for lisp packages?

[Reiner Steib]

On Thu, Oct 07 2004, Miles Bader wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
[...]
>> Miles, would it be better to move the files via arch or should I
>> simply use the normal CVS procedure (remove and add)?
>
> [...] -- but I'd feel a bit more comfortable doing it myself from
> arch.  Maybe it's just the control-freak in me... :-/

Please do. :-) If you also want to apply the patch in Gnus'
repository, minor modifications in etc/Makefile.in (install,
uninstall) are necessary.

> BTW, should smilies really go in "images/gnus"?  How about "images/smilies",
> so other packages could (theoretically) use them

For me, both possibilities are okay.  I "unified" it to
etc/images/gnus, because I though this is what you suggested in
<87brgff2eg.fsf@tc-1-100.kawasaki.gol.ne.jp>.  But probably I
misunderstood.

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