The MH-E repository

The MH-E repository

[Bill Wohler]

Back in 2001, I asked where the MH-E repository should go. Stefan
responded that using the Emacs repository would avoid the problems
incurred by the Gnus folks. But for one reason or another, the
repository ended up at SourceForge. Then in 2003, Richard suggested the
same thing to keep the Emacs version more fresh. While I keep the Emacs
version pretty fresh, and I've automated much of the importing and
exporting between the repositories, it's still work that could be
eliminated with a shared repository.

Now that there is a separate lisp/mh-e directory, and all of the MH-E
developers have signed papers and therefore should have write access or
be able to get write access to the Emacs repository, I'd like to ask
what folks think about moving the MH-E src module from SourceForge to
gnu.org.

I've listed some of the issues below and I invite comments from both the
Emacs maintainers and MH-E developers since these issues affect both
teams.

There may be some files mentioned below that the Emacs maintainers would
not want to see in the Emacs repository. Files will have to be organized
so that MH-E can be developed from within and outside of CVS Emacs, and
run as a released module from any supported version of Emacs.


Releases. Since MH-E has releases more frequently than Emacs, MH-E will
still need the ability to build its own releases.

Makefile and README. These files go in the MH-E release and are not
copied to lisp/mh-e in Emacs. The Makefile, which is used to build
mh-loaddefs.el and to build MH-E releases, could go in lisp/mh-e. The
file lisp/Makefile could be modified to run the mh-loaddefs.el target.
The import-emacs and import-emacs and install-emacs targets could be
eliminated ;-). I don't think it would hurt to add the README, which
contains instructions for building and installing MH-E, to lisp/mh-e
although it wouldn't need to appear in an Emacs release.

MH-E-NEWS. This file is copied from the MH-E src directory to the Emacs
etc directory. Since I'm the only one who edits this file and I already
have CVS Emacs checked out, I'm happy to edit this directly in etc.

Image files. The MH-E src directory contains images that are copied to
the Emacs lisp/toolbar and lisp/mail directories. Unless we did
something fancy, MH-E developers would have to check out the
lisp/toolbar and lisp/mail directories in addition to lisp/mh-e. We'd
have to figure out how to access the images from CVS Emacs, an installed
version of Emacs using both developmental MH-E and released MH-E.

mh-xemacs.el. This file in the MH-E src directory goes in the MH-E
release but not in GNU Emacs. Since it wouldn't hurt, it could go in
lisp/mh-e.

release-utils. This is a script that is used to perform various tasks
when making releases. It couldn't hurt to go in lisp/mh-e. It need not
appear in a release.

mh-unit.el. This file contains MH-E unit tests and runs checkdoc and
lm-verify before making releases. It couldn't hurt to go in lisp/mh-e.
It need not appear in a release.

contrib, debian, htdocs, xemacs modules. These would remain on
SourceForge.

Subversion. SourceForge has plans to offer Subversion this year. Are
there plans to move the Emacs repository to Subversion?


My two big questions are: 1) Is anyone against this, and why? 2) Would
the Emacs maintainers mind having the extra files mentioned previously
in the lisp/mh-e directory or would they prefer any files associated
with MH-E's life outside of Emacs to be kept outside of Emacs?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Juanma Barranquero]

> Subversion. SourceForge has plans to offer Subversion this year. Are
> there plans to move the Emacs repository to Subversion?

I think that one was discussed one year ago or so and rejected. Unfortunately.

> My two big questions are: 1) Is anyone against this, and why? 2) Would
> the Emacs maintainers mind having the extra files mentioned previously
> in the lisp/mh-e directory or would they prefer any files associated
> with MH-E's life outside of Emacs to be kept outside of Emacs?

These questions (or at least the second one) will be best answered by RMS.

-- 
                    /L/e/k/t/u


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Miles Bader]

On 5/31/05, Bill Wohler <wohler@newt.com> wrote:
> 2) Would
> the Emacs maintainers mind having the extra files mentioned previously
> in the lisp/mh-e directory or would they prefer any files associated
> with MH-E's life outside of Emacs to be kept outside of Emacs?

What _advantage_ is there to having them be included?

I maintain the synchronization of the Emacs tree Gnus files with the
Gnus tCVS ree, and files that are "only on one side " are not much of
a problem because they only really have an effect when added/deleted
-- and that's a fairly rare event.  So as far as I can see, there's
little reason to include such files.

BTW, I personally would prefer it if the non-lisp files would go in
"proper" locations, eg. image files in etc/images, etc.  I think Gnus
is a very good model to follow on this (though I'm a bit prejudiced
because of my association I guess...).

-Miles
-- 
Do not taunt Happy Fun Ball.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Jérôme Marant]

Selon Bill Wohler <wohler@newt.com>:

...
> Now that there is a separate lisp/mh-e directory, and all of the MH-E
> developers have signed papers and therefore should have write access or
> be able to get write access to the Emacs repository, I'd like to ask
> what folks think about moving the MH-E src module from SourceForge to
> gnu.org.

Hi,

I think this is a bad idea, especially for those who like to do regular
checkouts in order to have the cutting edge versions. There is no
really benefit.

I'll add that trying to integrate more and more lisp modules in Emacs
core is bad, and even worst since there are so few Emacs
releases that people always use more recent versions of modules
they grabbed from outside instead of the ones shipped with Emacs (for
example: Gnus, speedbar, ...).

To my mind, the good solution would be to ship modules in a separate
tarball and update them more frequently.

--
Jérôme Marant


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Miles Bader]

Jérôme Marant <jmarant@free.fr> writes:
> I'll add that trying to integrate more and more lisp modules in Emacs
> core is bad

mh-e is _already_ part of Emacs, so it seems sort of a moot point.

> and even worst since there are so few Emacs releases that people
> always use more recent versions of modules they grabbed from outside
> instead of the ones shipped with Emacs (for example: Gnus, speedbar,
> ...).

The two distribution methods need not conflict (e.g., Gnus seems to work
fine standalone, despite also being part of the distribution).

For packages where the user doesn't care so much about being on the
cutting edge -- and I'd argue this is the most of them -- it's _very_
convenient to have some version available without having to deal with
issues related to separate distribution (these are less of a problem if
you're using a good packaging system with good maintainers, like debian,
but I think most Emacs users aren't).  This especially true of the small
packages which seem to be typical for Emacs and elisp.

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


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Jérôme Marant]

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

> Jérôme Marant <jmarant@free.fr> writes:
> > I'll add that trying to integrate more and more lisp modules in Emacs
> > core is bad
>
> mh-e is _already_ part of Emacs, so it seems sort of a moot point.

Since 22.0 only.

> > and even worst since there are so few Emacs releases that people
> > always use more recent versions of modules they grabbed from outside
> > instead of the ones shipped with Emacs (for example: Gnus, speedbar,
> > ...).
>
> The two distribution methods need not conflict (e.g., Gnus seems to work
> fine standalone, despite also being part of the distribution).

I didn't say they are.

> For packages where the user doesn't care so much about being on the
> cutting edge -- and I'd argue this is the most of them -- it's _very_
> convenient to have some version available without having to deal with
> issues related to separate distribution (these are less of a problem if
> you're using a good packaging system with good maintainers, like debian,
> but I think most Emacs users aren't).  This especially true of the small
> packages which seem to be typical for Emacs and elisp.

What about bugs in packages? There are many bugs in 21.4 that have
already been fixed in the CVS trunk but noone cared for providing
bugfix releases in between.
At Debian, we have tons of bugs about Gnus 5.9 (shipped with Emacs)
but we certainly are not going to search for fixes: they have surely
been fixed already and everyone stopped using it in favour of the
external package.

If you are not interested in bugfix releases, a good tradeoff is to
ship them outside and to update them more frequently.

--
Jérôme Marant


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Mark D. Baushke]

Jérôme Marant <jmarant@free.fr> writes:

> Selon Miles Bader <miles@lsi.nec.co.jp>:
> 
> > Jérôme Marant <jmarant@free.fr> writes:
> > > I'll add that trying to integrate more and more lisp modules in Emacs
> > > core is bad
> >
> > mh-e is _already_ part of Emacs, so it seems sort of a moot point.
> 
> Since 22.0 only.

I believe you have overlooked the earlier versions of MH-E that have
existed in the Emacs distribution for a very long time. [I personally
started using mh-e (MH-E version 3.x) with Emacs 18.x (where x was
somewhere around 34) circa 1988.]

The oldest tarball I happen to have on hand right now is for Emacs
19.34b, so let me see...

% tar ztf /volume/opensource/GNU/emacs/emacs-19.34b.tar.gz |grep -i mh
emacs-19.34/lisp/gnus-mh.el
emacs-19.34/lisp/mh-comp.el
emacs-19.34/lisp/mh-e.el
emacs-19.34/lisp/mh-funcs.el
emacs-19.34/lisp/mh-mime.el
emacs-19.34/lisp/mh-pick.el
emacs-19.34/lisp/mh-seq.el
emacs-19.34/lisp/mh-utils.el
emacs-19.34/lisp/nnmh.el
emacs-19.34/lisp/gnus-mh.elc
emacs-19.34/lisp/mh-comp.elc
emacs-19.34/lisp/mh-e.elc
emacs-19.34/lisp/mh-funcs.elc
emacs-19.34/lisp/mh-mime.elc
emacs-19.34/lisp/mh-pick.elc
emacs-19.34/lisp/mh-seq.elc
emacs-19.34/lisp/mh-utils.elc
emacs-19.34/lisp/nnmh.elc
emacs-19.34/src/termhooks.h
emacs-19.34/etc/MH-E-NEWS
emacs-19.34/etc/MH-E-ONEWS
emacs-19.34/info/mh-e
emacs-19.34/info/mh-e-1
emacs-19.34/info/mh-e-2
emacs-19.34/info/mh-e-3
emacs-19.34/info/mh-e-4
emacs-19.34/man/mh-e.texi
emacs-19.34/man/mh-e.aux
emacs-19.34/man/mh-e.cps
emacs-19.34/man/mh-e.fns
emacs-19.34/man/mh-e.vrs
%

The version in emacs-19.34b was MH-E Version 5.0.2 which worked with
both MH version 6.8 or nmh.

	Thanks,
	-- Mark


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Jérôme Marant]

Selon "Mark D. Baushke" <mdb@gnu.org>:

> Jérôme Marant <jmarant@free.fr> writes:
>
> > Selon Miles Bader <miles@lsi.nec.co.jp>:
> >
> > > Jérôme Marant <jmarant@free.fr> writes:
> > > > I'll add that trying to integrate more and more lisp modules in Emacs
> > > > core is bad
> > >
> > > mh-e is _already_ part of Emacs, so it seems sort of a moot point.
> >
> > Since 22.0 only.
>
> I believe you have overlooked the earlier versions of MH-E that have
> existed in the Emacs distribution for a very long time. [I personally
> started using mh-e (MH-E version 3.x) with Emacs 18.x (where x was
> somewhere around 34) circa 1988.]

You're right. It was buried in the mail directory.

--
Jérôme Marant


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Bill Wohler]

Jérôme Marant <jmarant@free.fr> wrote:

> Selon Miles Bader <miles@lsi.nec.co.jp>:
> 
> > Jérôme Marant <jmarant@free.fr> writes:
> > > I'll add that trying to integrate more and more lisp modules in Emacs
> > > core is bad
> >
> > mh-e is _already_ part of Emacs, so it seems sort of a moot point.
> 
> Since 22.0 only.

MH-E was incorporated into Emacs sometime around version 13-15 in
1983-1985. Perhaps you are thinking of the creation of the MH-E
SourceForge project in 2000 or the creation of the Emacs lisp/mh-e
directory in 2003.

Please limit this discussion to the points I mentioned. If one wants to
discuss the merits of packaging, please do so with a different subject.
Thanks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Eli Zaretskii]

> Date: Tue, 31 May 2005 09:08:17 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: mh-e-devel@lists.sourceforge.net, emacs-devel@gnu.org
> 
> I think this is a bad idea, especially for those who like to do regular
> checkouts in order to have the cutting edge versions.

??? Those who want the bleeding edge will always be able to checkout
it from the Emacs CVS, no?


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

The practice of parts of Emacs in places other than the Emacs
repository is quite harmful to Emacs maintenance.  It regularly leads
to difficulties getting the latest code into Emacs, and even to
unintended forks.  To think of this as a way to serve Emacs users
is taking a short-term view.

I would rather see more Lisp package maintainers keep their master
sources inside the Emacs repository, so as to reduce the potential
for these problems.

Re: The MH-E repository

[Jérôme Marant]

Richard Stallman <rms@gnu.org> writes:

> The practice of parts of Emacs in places other than the Emacs
> repository is quite harmful to Emacs maintenance.  It regularly leads
> to difficulties getting the latest code into Emacs, and even to
> unintended forks.  To think of this as a way to serve Emacs users
> is taking a short-term view.
>
> I would rather see more Lisp package maintainers keep their master
> sources inside the Emacs repository, so as to reduce the potential
> for these problems.

I understand your points but there are many risks to make them too
strongly bound to the Emacs CVS version along with its Lisp changes,
which could make them incompatible with previous Emacs releases.

Currently, packages maintained outside of the Emacs CVS are meant
to work on the stable Emacs release and they usually do.

BTW, I'd like to see them more often updated for the stable Emacs
release, because it's not really acceptable for users to wait for
the next stable release to see their bugs fixed (last real update
was in 2003).

-- 
Jérôme Marant

Re: The MH-E repository

[Richard Stallman]

You are trying to facilitate updates in specific packages
at the expense of undermining the long-term development of Emacs.
If people do what you want, it will impede progress.

Please stop interfering with Emacs development.
Please just stop!

packaging (was: The MH-E repository)

[Janusz S. Bień]

On Wed, 01 Jun 2005  Richard Stallman <rms@gnu.org> wrote:

> You are trying to facilitate updates in specific packages
> at the expense of undermining the long-term development of Emacs.
> If people do what you want, it will impede progress.

Please elaborate.

> 
> Please stop interfering with Emacs development.
> Please just stop!

I hope Jérôme will not follow your suggestion. He is making enourmous
although indirect contribution to Emacs development by providing
Debian community with Emacs snapshot package. To be more precise, this
is a script which fully automates the package creation:

        http://people.debian.org/~jerome/build-emacs-snapshot.sh

As you may happen to remember, I used to be a pretester. I stopped
testing Emacs not only because of general lack of time, but also
because integrating CVS Emacs with Debian was too cumbersome. Now
emacs-snapshot is a separate flavour which peacefully coexists with
stable version, so it allows extensive testing without unnecessary
risks. I am again on emacs-devel list and hope, thanks to Jérôme, to
be able to do some testing again. 

I don't think Emacs should grow infinitely and spliting it sooner or
later into packages seems to me inevitable. MH-E stuff is an obvious
candidate for a package.

Best regards

Janusz

-- 
                     ,   
dr hab. Janusz S. Bien, prof. UW -  Uniwersytet Warszawski (Katedra Lingwistyki Formalnej)
Prof. Janusz S. Bien - Warsaw Uniwersity (Chair of Formal Linguistics)
jsbien@mimuw.edu.pl, jsbien@uw.edu.pl, http://www.mimuw.edu.pl/~jsbien/, http://www.klf.uw.edu.pl

Re: packaging (was: The MH-E repository)

[Richard Stallman]

    > You are trying to facilitate updates in specific packages
    > at the expense of undermining the long-term development of Emacs.
    > If people do what you want, it will impede progress.

    Please elaborate.

I explained that in the first message.  When packages are maintained
in places outside of the Emacs repository, often the changes do not
get installed in the Emacs repository.

We had a problem like this in regard to flyspell which I had to clear
up myself just recently.  I had to spend hours on it.  We know of
similar problem in regard to cperl-mode.  There was a problem of this
kind with Gnus for a long time.

There are probably other such problems that we do not know about.
It is not easy to find out about them without sending mail to a lot
of people, which would be a lot of work.

I am going to look for measures to discourage the practice of
releasing parts of Emacs separately.

Re: The MH-E repository

[Kim F. Storm]

Bill Wohler <wohler@newt.com> writes:

> Now that there is a separate lisp/mh-e directory, and all of the MH-E
> developers have signed papers and therefore should have write access or
> be able to get write access to the Emacs repository, I'd like to ask
> what folks think about moving the MH-E src module from SourceForge to
> gnu.org.

How many developers are involved?

Have they signed papers for MH-E only, or general past/future changes
for emacs as a whole?

In the "good ol' days", two projects on savannah.gnu.org could
trivially share modules with symbolic links, i.e. lisp/mh-e in
emacs CVS could just be a symbolic link to the MH-E CVS root.
IIRC, the url project was shared like that.

But these days, savannah is not an "open sandbox" anymore, so
symbolic links between projects are no longer possible.

I'm not sure what benefit you would actually get in terms of
sharing code by moving from sourceforce to gnu.org -- but
since MH-E is a gnu package, it seems natural to maintain
it on gnu.org.

> contrib, debian, htdocs, xemacs modules. These would remain on
> SourceForge.

Why?

> Subversion. SourceForge has plans to offer Subversion this year. Are
> there plans to move the Emacs repository to Subversion?

No, but perhaps savannah.gnu.org supports Subversion for other projects.

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



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Mark D. Baushke]

Kim F. Storm <storm@cua.dk> writes:

> Bill Wohler <wohler@newt.com> writes:
> 
> > Now that there is a separate lisp/mh-e directory, and all of the MH-E
> > developers have signed papers and therefore should have write access or
> > be able to get write access to the Emacs repository, I'd like to ask
> > what folks think about moving the MH-E src module from SourceForge to
> > gnu.org.
> 
> How many developers are involved?

Eight.

  Name                  Disclaimers (from copyright.list file)

  Mark D Baushke	EMACS past/future
  Chad Brown		EMACS past/future
  Satyaki Das		MH-E GNUS past/future
  Eric Ding		MH-E past/future
  Peter S Galbraith	MH-E past/future
  Stephen Gildea	EMACS past/future
  Jeffrey Honig		EMACS past/future
  Bill Wohler		EMACS past/future

> Have they signed papers for MH-E only, or general past/future changes
> for emacs as a whole?

It seems to be a mixture right now.

(Feel free to look in /gd/gnuorg/copyright.list on fencepost.gnu.org for
all of the details...)

	-- Mark


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

    > Have they signed papers for MH-E only, or general past/future changes
    > for emacs as a whole?

    It seems to be a mixture right now.

How, specifically, does that matter?

Re: The MH-E repository

[Mark D. Baushke]

Richard Stallman <rms@gnu.org> writes:

>     > Have they signed papers for MH-E only, or
>     > general past/future changes for emacs as a
>     > whole?
> 
>     It seems to be a mixture right now.
> 
> How, specifically, does that matter?

I do not believe it should matter.

I was just trying to answer a question asked by
Kim F Storm <storm@cua.dk>.

For what it may be worth, here are the Savannah
Login names for each of the MH-E developers:

  Name			Savannah Login Name

  Mark D Baushke	mdb
  Chad Brown		(unknown)
  Satyaki Das		satyaki
  Eric Ding		(unknown)
  Peter S Galbraith	psg
  Stephen Gildea	gildea
  Jeffrey Honig		jchonig
  Bill Wohler		wohler

I could not find either Chad Brown or Eric Ding listed,
so they will need to register with savannah and let us
know their login names...

	-- Mark

Re: The MH-E repository

[chad brown]

>   Name            Savannah Login Name
>
>   Chad Brown        (unknown)
>
> I could not find either Chad Brown or Eric Ding listed,
> so they will need to register with savannah and let us
> know their login names...

I am (now) registered with savannah under the name `yandros', in case  
it helps.  Thanks.

*chad


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

If you have given someone write access to MH-E, we can give him
write access to the Emacs repository.  However, these people should
only make changes in MH-E, if they have only signed papers for MH-E.

I think we should also ask these people to sign papers covering all of
Emacs.  But we don't have to wait for that.

Re: The MH-E repository

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > Have they signed papers for MH-E only, or general past/future changes
>     > for emacs as a whole?
>
>     It seems to be a mixture right now.
>
> How, specifically, does that matter?

Maybe it doesn't, but...

If someone has write access to the emacs repository, but only has signed
papers for a (small) subset of the code, we need to make sure that person
doesn't change things outside the assignments.

To me, it seems simpler if people with write access have assigned
past/future changes to Emacs as a whole.

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



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Stefan Monnier]

Things you may want to consider:

- RMS doesn't automatically give write access to people who signed papers.

- Maybe you could automate the syncing some more and do it more frequently.

- Take a look at the way Gnus's code is synced.  The use of Arch for that is
  key.  It not only can propagate commits both ways, but it can even deal
  with things like different filenames in the two repositories, or files
  that are only present in one repository and not the other, ...


-- Stefan


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Bill Wohler]

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

> - RMS doesn't automatically give write access to people who signed papers.

Not having write access would be a show-stopper. Question to MH-E
developers: which of you know that you don't have write access, or
aren't sure?

> - Maybe you could automate the syncing some more and do it more frequently.
> 
> - Take a look at the way Gnus's code is synced.  The use of Arch for that is
>   key.

Tell me more. Is there a document like
http://mh-e.sourceforge.net/doc/devguide.html that explains the process?
I'm not familiar with Arch. Are you talking about
http://www.gnu.org/software/gnu-arch/?

How often do you sync? Do you clone the CVS check-ins including log
messages? It looks like the answer is yes and no. Looking at the Emacs
log, it appears that many of the messages are "Merge from..." although I
see some similarity with the log messages in the Gnus CVS repository.

I'm currently syncing at MH-E releases (about 4/year) with Emacs cvs
logs like "Upgraded to MH-E version 7.84. See etc/MH-E-NEWS and
lisp/mh-e/ChangeLog for details." My MH-E CVS logs are very similar to
the Gnus CVS logs (as I look at the Gnus CVS log).

Kim F. Storm <storm@cua.dk> wrote:

> How many developers are involved?
> 
> Have they signed papers for MH-E only, or general past/future changes
> for emacs as a whole?

Mark answered this nicely.

> > contrib, debian, htdocs, xemacs modules. These would remain on
> > SourceForge.
> 
> Why?

I think you might not understand what I'm talking about. I'm not talking
about moving the SourceForge MH-E project to Savannah, I'm merely
talking about not having two separate CVS repositories for the lisp/mh-e
directory.

Miles Bader <snogglethorpe@gmail.com> wrote:

> What _advantage_ is there to having [MH-E maintenance files] be included?

Less up-front effort modifying scripts with a different layout. There
wouldn't be any advantage to the Emacs project as a whole, so I'm
expecting that I will be keeping them external from emacs/lisp/mh-e.

> BTW, I personally would prefer it if the non-lisp files would go in
> "proper" locations, eg. image files in etc/images, etc.  I think Gnus
> is a very good model to follow on this...

I agree. The MH-E package shares images with the mail and toolbar
packages. If you were developing MH-E with a non-CVS Emacs, then you
would have to be careful about putting lisp/mail at the end of your
load-path so you don't get the wrong version of the mail elisp files.

If I were to make the requisite changes in MH-E, would someone be
willing to make the changes to these other packages?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: The MH-E repository

[Mark D. Baushke]

Bill Wohler <wohler@newt.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > - RMS doesn't automatically give write access to people who signed papers.
> 
> Not having write access would be a show-stopper. Question to MH-E
> developers: which of you know that you don't have write access, or
> aren't sure?

I do not have write access. 

(Stefan, you may consider this my request to have you add my 'mdb'
userid to the emacs project.)

Looking at the 93 members under
  https://savannah.gnu.org/projects/emacs/

I see the following MH-E developers listed:

  Project Member Stephen Gildea <gildea>
  Project Member Bill Wohler <wohler>

None of the rest of the MH-E developers:

  Mark D Baushke
  Chad Brown
  Satyaki Das
  Eric Ding
  Peter S Galbraith
  Jeffrey Honig

appear to be listed.

	-- Mark

Re: The MH-E repository

[Stefan Monnier]

> (Stefan, you may consider this my request to have you add my 'mdb'
> userid to the emacs project.)

Such request should be made online at the Emacs project page on savannah.
And for what it's worth RMS insists on being the only one to give write
access,


        Stefan


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard M. Stallman]

Please forgive the delay--I was waiting to have a chance
to make some of you members of the Emacs project myself.
Instead I decided I will find someone else to do that.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

Re: The MH-E repository

[Bill Wohler]

"Richard M. Stallman" <rms@gnu.org> writes:

> Please forgive the delay--I was waiting to have a chance
> to make some of you members of the Emacs project myself.
> Instead I decided I will find someone else to do that.

Thank you. This person can verify the MH-E developers at

  https://sourceforge.net/project/memberlist.php?group_id=13357

As soon as all of the MH-E developers are Emacs committers, I will
proceed with the switch.

MH-E developers: if you haven't already done so, please submit your
request via https://savannah.gnu.org/my/groups.php.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: The MH-E repository

[Mark D. Baushke]

Hi Bill,

Bill Wohler <wohler@newt.com> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
> 
> > Please forgive the delay--I was waiting to have a chance
> > to make some of you members of the Emacs project myself.
> > Instead I decided I will find someone else to do that.
> 
> Thank you. This person can verify the MH-E developers at
> 
>   https://sourceforge.net/project/memberlist.php?group_id=13357
> 
> As soon as all of the MH-E developers are Emacs committers, I will
> proceed with the switch.

For what it may be worth, here are the Savannah Login names for each of
the MH-E developers that have been given Emacs membership:

  Name			Savannah Login Name
  Mark D Baushke	mdb
  Satyaki Das		satyaki
  Peter S Galbraith	psg
  Stephen Gildea	gildea
  Jeffrey Honig		jchonig
  Bill Wohler		wohler

So, it looks like most of the team has been granted Emacs membership.
 
> MH-E developers: if you haven't already done so, please submit your
> request via https://savannah.gnu.org/my/groups.php.

Hmmm... I still do not see two MH-E developers on the Emacs list:

   Name            Savannah Login Name

   Chad Brown        yandros
   Eric Ding         (unknown)

I do not know what Eric Ding's Savannah Login Name is (or if he has
one).

	-- Mark


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

Re: The MH-E repository

[Miles Bader]

On 6/1/05, Bill Wohler <wohler@newt.com> wrote:
> I'm not familiar with Arch. Are you talking about
> http://www.gnu.org/software/gnu-arch/?

Yes; the wiki at (I think) http://wiki.gnuarch.org might be more informative.

The key property of arch that makes things easier is the ability to
create and apply "changesets" (basically, patches) that operate by
file _identity_ rather than filename.  So a changeset from the Gnus
tree does more or less the right thing when applied to Emacs tree. 
Arch also keeps track of what changes have been merged, which reduces
the need for manual book-keeping (one of the most stressful things
about more manual merging, I find).

Note that this doesn't remove the need for manual intervention, as
there are cases where the right thing doesn't happen, but it takes
care of about 95% of the work.  I have a sort of mental checklist of
exceptional cases to be on the lookout for and be ready to fixup by
hand (for instance the Emacs file "man/ChangeLog" contains entries for
changes to gnus texinfo files, but also many other non-Gnus texinfo
files, and only the Gnus-related changes should go into the Gnus
tree).

Note that my usage of Arch for this is sort of a hack -- Arch has no
explicit notion of a "subtree"; merging in the Emacs => Gnus direction
results in many "unappliable" changes, because they are to files which
don't exist in Gnus (Arch puts such changes in a scratch directory
where you can look at them if you want).

> How often do you sync?

Usually about every 2-3 days; however I also follow the Gnus mailing
list and sync immediately if someone makes an important change.  Note
that the relationship is:

    Emacs trunk <=> Gnus-5.10 branch (bi-directional)
     Gnus trunk <== Gnus-5.10 branch (one-way)

So changes from Emacs eventually end up in the Gnus trunk too, via the
Gnus 5.10 branch.  Activity on the Gnus 5.10 branch is relatively
light, which makes the job easier.

> Do you clone te CVS check-ins including log messages?

CVS log messages are not used; Arch is "tree changeset" oriented
rather than file-oriented, so there's no easy way to maintain them. 
However in Emacs (unlike some projects), basically all changes have
in-tree ChangeLog entries too, so my scripts try to create relevant
log messages from, which are what gets committed to CVS.

I've relatively knowledgeable about the way Arch works, and have many
of my own scripts, so I'm not sure how easy it would be for someone to
start doing the same thing from scratch.

BTW, I would certainly be willing to try syncing MH-E in the same way
I sync Gnus.  My experience with Gnus is that while it's a bit of
manual work, it's not that much, and it's not unpleasant.

-Miles
--
Do not taunt Happy Fun Ball.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

    Subversion. SourceForge has plans to offer Subversion this year. Are
    there plans to move the Emacs repository to Subversion?

No.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

    My two big questions are: 1) Is anyone against this, and why?

I am in favor of it.

								  2) Would
    the Emacs maintainers mind having the extra files mentioned previously
    in the lisp/mh-e directory or would they prefer any files associated
    with MH-E's life outside of Emacs to be kept outside of Emacs?

It's not the most important of issues, but but if you're planning to
keep a repository elsewhere, why not leave those three additional
files there rather than in Emacs?  It would be cleanest for the Emacs
repository to contain only the files that belong in Emacs.

Re: The MH-E repository

[Peter S Galbraith]

Bill Wohler <wohler@newt.com> wrote:

> My two big questions are: 1) Is anyone against this, and why?

My only concern is having more people affected by broken code.  I don't
know how Emacs developers works because I don't track their daily work,
so maybe this isn't a relevant issue...

Sometimes in the past, a MH-E developer would _try_ something, possibly
a new way of handling something.  He would check the new code into CVS
and it might break the codebase a little while it was being finalized,
but it was checked in so other developers could try it out and give
feedback.  I wouldn't feel comfortable doing this anymore knowing that
I'm affecting Emacs for a far greater number of users.  I prefer that we
check in released version of MH-E that are known to work.

-- 
Peter S. Galbraith, MH-E developer  <p.galbraith@globetrotter.net>
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E
6623'rd GNU/Linux user at the Counter - http://counter.li.org/

Re: The MH-E repository

[Bill Wohler]

Peter S Galbraith <p.galbraith@globetrotter.net> wrote:

> Bill Wohler <wohler@newt.com> wrote:
> 
> > My two big questions are: 1) Is anyone against this, and why?
> 
> Sometimes in the past, a MH-E developer would _try_ something, possibly
> a new way of handling something.  He would check the new code into CVS
> and it might break the codebase a little while it was being finalized,
> but it was checked in so other developers could try it out and give
> feedback.  I wouldn't feel comfortable doing this anymore knowing that
> I'm affecting Emacs for a far greater number of users.

Good observation. Note that we are not affecting Emacs users who do not
use MH-E. Perhaps the Emacs developers and users who check out CVS Emacs
who use MH-E are also comfortable with this. It is extremely rare.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: The MH-E repository

[Richard Stallman]

    Sometimes in the past, a MH-E developer would _try_ something, possibly
    a new way of handling something.  He would check the new code into CVS
    and it might break the codebase a little while it was being finalized,
    but it was checked in so other developers could try it out and give
    feedback.

Please don't worry about it.  This is normal practice for
Emacs--except when we are close to a release.

People who want stable Emacs get the releases, not the CVS version.



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: Shall we use etc/images more?

[Peter S Galbraith]

Bill Wohler <wohler@newt.com> wrote:

> > >     etc/images/mail/rescan -- updates the message listing
> > 
> > Refresh
> 
> Like in a browser. Hmmm. That might work. What does the MH-E gang think
> about replacing the cabinet icon with a more well-known refresh icon
> (two arrows chasing the other's tail) and renaming rescan (the icon) to
> refresh?

I like it too.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: The MH-E repository

[Bill Wohler]

I just thought of a potentially big issue. Or not.

If this switch comes to pass, would the Emacs developers mind if I added
the following line to CVSROOT/loginfo?

 lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net

I'd also add the syncmail script to the CVSROOT directory. It's a script
that sends a diff of the checkin to the given address. See
http://syncmail.sourceforge.net/.

This is how the MH-E team performs code reviews.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: The MH-E repository

[Richard Stallman]

    If this switch comes to pass, would the Emacs developers mind if I added
    the following line to CVSROOT/loginfo?

     lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net

Would you please explain what this would do?  I don't understand,
but I can't say yes until I understand.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Bill Wohler]

Richard Stallman <rms@gnu.org> wrote:

>     If this switch comes to pass, would the Emacs developers mind if I added
>     the following line to CVSROOT/loginfo?
> 
>      lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net
> 
> Would you please explain what this would do?  I don't understand,
> but I can't say yes until I understand.

This loginfo entry calls syncmail on each check-in for the lisp/mh-e
directory. The syncmail script, when run in the CVS loginfo context will
send a diff of each check-in to the given mailing list (mh-e-devel).

To see what this looks like please see:

  https://sourceforge.net/mailarchive/forum.php?thread_id=7414775&forum_id=5136

The DEFAULT entry is used if no others match. For example, the Emacs
project could define:

  DEFAULT $CVSROOT/CVSROOT/syncmail -u %{sVv} emacs-commits@gnu.org

> If you have given someone write access to MH-E, we can give him
> write access to the Emacs repository.

Thank you. The list of developers that I've given write access to MH-E
can be found at:

  https://sourceforge.net/project/memberlist.php?group_id=13357

I've asked the MH-E developers to request Emacs write access on the
Savannah site. I would appreciate it if you gave it to them.

> However, these people should only make changes in MH-E, if they have
> only signed papers for MH-E.

I trust that won't be a problem.

>                              I think we should also ask these people
> to sign papers covering all of Emacs. But we don't have to wait for
> that.

Satyaki, Eric, and Peter: please find instructions to do this at
http://mh-e.sourceforge.net/doc/devguide.html#Prerequisites. Please
substitute Emacs for MH-E.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005

Re: The MH-E repository

[Richard Stallman]

    >     If this switch comes to pass, would the Emacs developers mind if I added
    >     the following line to CVSROOT/loginfo?
    > 
    >      lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net
    > 
    > Would you please explain what this would do?  I don't understand,
    > but I can't say yes until I understand.

    This loginfo entry calls syncmail on each check-in for the lisp/mh-e
    directory. The syncmail script, when run in the CVS loginfo context will
    send a diff of each check-in to the given mailing list (mh-e-devel).

Ok with me.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: The MH-E repository

[Bill Wohler]

Richard Stallman <rms@gnu.org> wrote:

>     >     If this switch comes to pass, would the Emacs developers mind if I added
>     >     the following line to CVSROOT/loginfo?
>     > 
>     >      lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net
>     > 
>     > Would you please explain what this would do?  I don't understand,
>     > but I can't say yes until I understand.
> 
>     This loginfo entry calls syncmail on each check-in for the lisp/mh-e
>     directory. The syncmail script, when run in the CVS loginfo context will
>     send a diff of each check-in to the given mailing list (mh-e-devel).
> 
> Ok with me.

Thanks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Savannah-help-public] Re: The MH-E repository

[Sylvain Beucler]

Considering that you want lisp/mh-e to notify both mh-e-devel and
emacs-commit, this is currently not possible in the current setup,
mainly because CVS's loginfo only matches one configuration file line,
and each line call our notification script that only accept 1 e-mail
address per kind of notifications (diff / nodiff).

Currently we do not have to resources to work on this script to bypass
CVS's limitations, but the source code is freely available at
administration/administration/infra/commit_prep-log_accum/ in the
administration project repository at Savannah.

-- 
Sylvain

On Fri, Jun 03, 2005 at 04:25:14PM -0700, Bill Wohler wrote:
> Richard Stallman <rms@gnu.org> wrote:
> 
> >     >     If this switch comes to pass, would the Emacs developers mind if I added
> >     >     the following line to CVSROOT/loginfo?
> >     > 
> >     >      lisp/mh-e $CVSROOT/CVSROOT/syncmail -u %{sVv} mh-e-devel@lists.sourceforge.net
> >     > 
> >     > Would you please explain what this would do?  I don't understand,
> >     > but I can't say yes until I understand.
> > 
> >     This loginfo entry calls syncmail on each check-in for the lisp/mh-e
> >     directory. The syncmail script, when run in the CVS loginfo context will
> >     send a diff of each check-in to the given mailing list (mh-e-devel).
> > 
> > Ok with me.
> 
> Thanks.
> 
> -- 
> Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
> Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
> If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Savannah-help-public] Re: The MH-E repository

[Miles Bader]

On 6/4/05, Sylvain Beucler <beuc@gnu.org> wrote:
> Considering that you want lisp/mh-e to notify both mh-e-devel and
> emacs-commit, this is currently not possible in the current setup,
> mainly because CVS's loginfo only matches one configuration file line,
> and each line call our notification script that only accept 1 e-mail
> address per kind of notifications (diff / nodiff).

As a work-around, you could have it send to an alias (I mean one in
/etc/aliases or equivalent) which in turn just forwards to both lists.

-Miles
-- 
Do not taunt Happy Fun Ball.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 

Re: [Savannah-help-public] Re: The MH-E repository

[Bill Wohler]

Miles Bader <snogglethorpe@gmail.com> wrote:

> On 6/4/05, Sylvain Beucler <beuc@gnu.org> wrote:
> > Considering that you want lisp/mh-e to notify both mh-e-devel and
> > emacs-commit, this is currently not possible in the current setup,
> > mainly because CVS's loginfo only matches one configuration file line,
> > and each line call our notification script that only accept 1 e-mail
> > address per kind of notifications (diff / nodiff).
> 
> As a work-around, you could have it send to an alias (I mean one in
> /etc/aliases or equivalent) which in turn just forwards to both lists.

That's true. What might be a better alternative is that I could (and
probably should) set up an mh-e-commits mailing list. I'd add
emacs-commits to that list.

At first I thought that the Emacs folks would not really be interested
in seeing the MH-E commits, but perhaps that would not be the case.

However, if the Emacs maintainers don't even *want* to have an
emacs-commits mailing list, then this is a moot point. Do they?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: [Savannah-help-public] Re: The MH-E repository

[Sylvain Beucler]

On Sat, Jun 04, 2005 at 09:13:37AM -0700, Bill Wohler wrote:
> Miles Bader <snogglethorpe@gmail.com> wrote:
> 
> > On 6/4/05, Sylvain Beucler <beuc@gnu.org> wrote:
> > > Considering that you want lisp/mh-e to notify both mh-e-devel and
> > > emacs-commit, this is currently not possible in the current setup,
> > > mainly because CVS's loginfo only matches one configuration file line,
> > > and each line call our notification script that only accept 1 e-mail
> > > address per kind of notifications (diff / nodiff).
> > 
> > As a work-around, you could have it send to an alias (I mean one in
> > /etc/aliases or equivalent) which in turn just forwards to both lists.
> 
> That's true. What might be a better alternative is that I could (and
> probably should) set up an mh-e-commits mailing list. I'd add
> emacs-commits to that list.
> 
> At first I thought that the Emacs folks would not really be interested
> in seeing the MH-E commits, but perhaps that would not be the case.
> 
> However, if the Emacs maintainers don't even *want* to have an
> emacs-commits mailing list, then this is a moot point. Do they?

The FSF set up an anti-spam rule that block mail "from AND to mailing
lists" :/

However I/Miles/... should be able to setup an alias at fencepost :)
Indeed.

Please tell me what you decide (whether commits should go to both
mailing lists or only mh-e-devel).

-- 
Sylvain


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: [Savannah-help-public] Re: The MH-E repository

[Bill Wohler]

Sylvain Beucler <beuc@gnu.org> wrote:

> On Sat, Jun 04, 2005 at 09:13:37AM -0700, Bill Wohler wrote:
> > Miles Bader <snogglethorpe@gmail.com> wrote:
> > 
> > > On 6/4/05, Sylvain Beucler <beuc@gnu.org> wrote:
> > > > Considering that you want lisp/mh-e to notify both mh-e-devel and
> > > > emacs-commit, this is currently not possible in the current setup,
> > > > mainly because CVS's loginfo only matches one configuration file line,
> > > > and each line call our notification script that only accept 1 e-mail
> > > > address per kind of notifications (diff / nodiff).
> > > 
> > > As a work-around, you could have it send to an alias (I mean one in
> > > /etc/aliases or equivalent) which in turn just forwards to both lists.
> > 
> > That's true. What might be a better alternative is that I could (and
> > probably should) set up an mh-e-commits mailing list. I'd add
> > emacs-commits to that list.
> > 
> > At first I thought that the Emacs folks would not really be interested
> > in seeing the MH-E commits, but perhaps that would not be the case.
> > 
> > However, if the Emacs maintainers don't even *want* to have an
> > emacs-commits mailing list, then this is a moot point. Do they?
> 
> The FSF set up an anti-spam rule that block mail "from AND to mailing
> lists" :/
> 
> However I/Miles/... should be able to setup an alias at fencepost :)
> Indeed.
> 
> Please tell me what you decide (whether commits should go to both
> mailing lists or only mh-e-devel).

Sylvain,

It's time to proceed with this. But first, a couple of quick questions.

I have not been able to find (your version of) the log_accum.pl script
to confirm, but the following email implies that we might be able to say
-m emacs-commit -m mh-e-devel on the command line:

  http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg01079.html

Then there's the question of the -D option as well.

Also, is there an option to generate unified diffs instead of context
diffs? With large hunks, it's impossible to compare the changes in
context diffs.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: [Savannah-help-public] Re: The MH-E repository

[Sylvain Beucler]

On Fri, Sep 30, 2005 at 03:49:08PM -0700, Bill Wohler wrote:
> Sylvain Beucler <beuc@gnu.org> wrote:
> 
> > On Sat, Jun 04, 2005 at 09:13:37AM -0700, Bill Wohler wrote:
> > > Miles Bader <snogglethorpe@gmail.com> wrote:
> > > 
> > > > On 6/4/05, Sylvain Beucler <beuc@gnu.org> wrote:
> > > > > Considering that you want lisp/mh-e to notify both mh-e-devel and
> > > > > emacs-commit, this is currently not possible in the current setup,
> > > > > mainly because CVS's loginfo only matches one configuration file line,
> > > > > and each line call our notification script that only accept 1 e-mail
> > > > > address per kind of notifications (diff / nodiff).
> > > > 
> > > > As a work-around, you could have it send to an alias (I mean one in
> > > > /etc/aliases or equivalent) which in turn just forwards to both lists.
> > > 
> > > That's true. What might be a better alternative is that I could (and
> > > probably should) set up an mh-e-commits mailing list. I'd add
> > > emacs-commits to that list.
> > > 
> > > At first I thought that the Emacs folks would not really be interested
> > > in seeing the MH-E commits, but perhaps that would not be the case.
> > > 
> > > However, if the Emacs maintainers don't even *want* to have an
> > > emacs-commits mailing list, then this is a moot point. Do they?
> > 
> > The FSF set up an anti-spam rule that block mail "from AND to mailing
> > lists" :/
> > 
> > However I/Miles/... should be able to setup an alias at fencepost :)
> > Indeed.
> > 
> > Please tell me what you decide (whether commits should go to both
> > mailing lists or only mh-e-devel).
> 
> Sylvain,
> 
> It's time to proceed with this. But first, a couple of quick questions.
> 
> I have not been able to find (your version of) the log_accum.pl script
> to confirm, but the following email implies that we might be able to say
> -m emacs-commit -m mh-e-devel on the command line:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg01079.html

Check
http://savannah.gnu.org/cgi-bin/viewcvs/administration/administration/infra/commit_prep-log_accum/log_accum.pl?rev=1.4&content-type=text/vnd.viewcvs-markup

Apparently it should work there as well, my bad.

> Then there's the question of the -D option as well.

I don't think all combinations will be possible. Activating the diffs
globally for all lists should work.

> Also, is there an option to generate unified diffs instead of context
> diffs? With large hunks, it's impossible to compare the changes in
> context diffs.

Yes.

-- 
Sylvain

Re: [Savannah-help-public] Re: The MH-E repository

[Bill Wohler]

Sylvain Beucler <beuc@gnu.org> wrote:

> On Fri, Sep 30, 2005 at 03:49:08PM -0700, Bill Wohler wrote:
> > Sylvain Beucler <beuc@gnu.org> wrote:
> > 
> > > The FSF set up an anti-spam rule that block mail "from AND to mailing
> > > lists" :/
> > > 
> > > However I/Miles/... should be able to setup an alias at fencepost :)
> > > Indeed.
> > > 
> > > Please tell me what you decide (whether commits should go to both
> > > mailing lists or only mh-e-devel).
> > 
> > It's time to proceed with this. But first, a couple of quick questions.
> > 
> > I have not been able to find (your version of) the log_accum.pl script
> > to confirm, but the following email implies that we might be able to say
> > -m emacs-commit -m mh-e-devel on the command line:
> > 
> >   http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg01079.html
> 
> Check
> http://savannah.gnu.org/cgi-bin/viewcvs/administration/administration/infra/commit_prep-log_accum/log_accum.pl?rev=1.4&content-type=text/vnd.viewcvs-markup
> 
> Apparently it should work there as well, my bad.
> 
> > Then there's the question of the -D option as well.
> 
> I don't think all combinations will be possible. Activating the diffs
> globally for all lists should work.
> 
> > Also, is there an option to generate unified diffs instead of context
> > diffs? With large hunks, it's impossible to compare the changes in
> > context diffs.
> 
> Yes.

Sylvain,

Thanks for the pointer to the modified script. If I'm reading it
correctly, I think that the MH-E developers would be happy (the log
message and unified diffs for every file in the check-in combined within
a single message) with a loginfo entry of:

  ^emacs/lisp/mh-e /bin/log_accum -T emacs -C -m mh-e-devel@lists.sourceforge.net -m emacs-commit@gnu.org -D -u -r "" -s %{sVv}

However, if you're correct in that your spam filter will deny this, then
it should be changed to:

  ^emacs/lisp/mh-e /bin/log_accum -T emacs -C -m mh-e-commit@gnu.org -D -u -r "" -s %{sVv}

and an mh-e-commit alias on fencepost should be created that contains
mh-e-devel@lists.sourceforge.net and emacs-commit@gnu.org.

Finally, if the emacs-commit community does not like getting the MH-E
diffs (unified ones at that) in the same message as the log, then
emacs-commit should be removed from the mailing list and interested
individuals should subscribe (assuming that the mailing list is set up
with mailman and rather than in /etc/aliases).

Can you makes these changes for me please? If so, please let me know
when I can test this. Thanks!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [Savannah-help-public] Re: The MH-E repository

[Sylvain Beucler]

On Mon, Oct 03, 2005 at 04:14:50PM -0700, Bill Wohler wrote:
> Sylvain Beucler <beuc@gnu.org> wrote:
> > On Fri, Sep 30, 2005 at 03:49:08PM -0700, Bill Wohler wrote:
> > > Sylvain Beucler <beuc@gnu.org> wrote:
> > > 
> > > > The FSF set up an anti-spam rule that block mail "from AND to mailing
> > > > lists" :/
> > > > 
> > > > However I/Miles/... should be able to setup an alias at fencepost :)
> > > > Indeed.
> > > > 
> > > > Please tell me what you decide (whether commits should go to both
> > > > mailing lists or only mh-e-devel).
> > > 
> > > It's time to proceed with this. But first, a couple of quick questions.
> > > 
> > > I have not been able to find (your version of) the log_accum.pl script
> > > to confirm, but the following email implies that we might be able to say
> > > -m emacs-commit -m mh-e-devel on the command line:
> > > 
> > >   http://lists.gnu.org/archive/html/emacs-devel/2001-11/msg01079.html
> > 
> > Check
> > http://savannah.gnu.org/cgi-bin/viewcvs/administration/administration/infra/commit_prep-log_accum/log_accum.pl?rev=1.4&content-type=text/vnd.viewcvs-markup
> > 
> > Apparently it should work there as well, my bad.
> > 
> > > Then there's the question of the -D option as well.
> > 
> > I don't think all combinations will be possible. Activating the diffs
> > globally for all lists should work.
> > 
> > > Also, is there an option to generate unified diffs instead of context
> > > diffs? With large hunks, it's impossible to compare the changes in
> > > context diffs.
> > 
> > Yes.
> 
> Sylvain,
> 
> Thanks for the pointer to the modified script. If I'm reading it
> correctly, I think that the MH-E developers would be happy (the log
> message and unified diffs for every file in the check-in combined within
> a single message) with a loginfo entry of:
> 
>   ^emacs/lisp/mh-e /bin/log_accum -T emacs -C -m mh-e-devel@lists.sourceforge.net -m emacs-commit@gnu.org -D -u -r "" -s %{sVv}
> 
> However, if you're correct in that your spam filter will deny this, then
> it should be changed to:
> 
>   ^emacs/lisp/mh-e /bin/log_accum -T emacs -C -m mh-e-commit@gnu.org -D -u -r "" -s %{sVv}
> 
> and an mh-e-commit alias on fencepost should be created that contains
> mh-e-devel@lists.sourceforge.net and emacs-commit@gnu.org.
> 
> Finally, if the emacs-commit community does not like getting the MH-E
> diffs (unified ones at that) in the same message as the log, then
> emacs-commit should be removed from the mailing list and interested
> individuals should subscribe (assuming that the mailing list is set up
> with mailman and rather than in /etc/aliases).
> 
> Can you makes these changes for me please? If so, please let me know
> when I can test this. Thanks!

I setup the first solution (no alias).

There should not be spam issues.

-- 
Sylvain


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [Savannah-help-public] Re: The MH-E repository

[Bill Wohler]

Sylvain Beucler <beuc@gnu.org> writes:

> I setup the [MH-E loginfo messages] (no alias).
>
> There should not be spam issues.

Indeed. I just made a small test and it looks great! Thanks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: [Savannah-help-public] Re: The MH-E repository

[Richard Stallman]

It should be possible for someone to write a filter to read
the diffs that are already being mailed out, and discard
all but those that pertain to the lisp/mh-e directory.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Shall we use etc/images more?

[Bill Wohler]

In MH-E, I think I'd like to reference images in etc/images/mail and,
say, etc/images/common, instead of lisp/mail and lisp/toolbar.

I only see gnus and smilies directories in there now. Is the intent to
someday move the images to etc/images? I recall Miles saying he thought
that Gnus was a good example to follow.

If so, what do people think of me checking in copies of the images in
lisp/mail into etc/images/mail and the images in lisp/toolbar into
etc/images/common (or nominate your favorite). I'll update MH-E to
reference the new location (if necessary). When the others files have
been modified (if necessary) to reference the new location, then the
images in the old locations can be removed.

I'm open to suggestions and concerns. Since I'm making changes to the
MH-E distribution now in preparation of using the Emacs repository
instead of the SourceForge repository (finally!), now would be a good
time to make these sorts of changes.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Kim F. Storm]

Bill Wohler <wohler@newt.com> writes:

> In MH-E, I think I'd like to reference images in etc/images/mail and,
> say, etc/images/common, instead of lisp/mail and lisp/toolbar.

I'd oppose to a "common" subdirectory -- such "general purpose" images
should just be placed directly in etc/images.

> and the images in lisp/toolbar into
> etc/images/common (or nominate your favorite).

etc/images

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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

>     In MH-E, I think I'd like to reference images in etc/images/mail and,
>     say, etc/images/common, instead of lisp/mail and lisp/toolbar.
> 
>     I only see gnus and smilies directories in there now. Is the intent to
>     someday move the images to etc/images? I recall Miles saying he thought
>     that Gnus was a good example to follow.
> 
> I think it is a good idea.
>
>     If so, what do people think of me checking in copies of the images in
>     lisp/mail into etc/images/mail and the images in lisp/toolbar into
>     etc/images/common (or nominate your favorite). I'll update MH-E to
>     reference the new location (if necessary). When the others files have
>     been modified (if necessary) to reference the new location, then the
>     images in the old locations can be removed.
> 
> What other references are there
> to the same images that you are moving?

Excellent question. The images can be referenced in various ways and I
do not know of a good way to find these places other than grep. I would
appreciate it if a knowledgeable volunteer can help me with this. Please
contact me directly if you think you could help.

It's possible that the images we use are not yet shared by others.

I'll try to send out a proposal by early next week with the list of
affected image files. For historical reasons, for which I need to remind
myself, the images are mostly in lisp/toolbar although at first blush it
seems they should be in lisp/mail. These will map to etc/images (per
Kim's request) and etc/images/mail respectively.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Richard M. Stallman]

    Excellent question. The images can be referenced in various ways and I
    do not know of a good way to find these places other than grep. I would
    appreciate it if a knowledgeable volunteer can help me with this. Please
    contact me directly if you think you could help.

Has anyone offered to help you yet?


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

>     Excellent question. The images can be referenced in various ways and I
>     do not know of a good way to find these places other than grep. I would
>     appreciate it if a knowledgeable volunteer can help me with this. Please
>     contact me directly if you think you could help.
> 
> Has anyone offered to help you yet?

Not yet.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Richard M. Stallman]

Would someone please offer to help?

>     Excellent question. The images can be referenced in various ways and I
>     do not know of a good way to find these places other than grep. I would
>     appreciate it if a knowledgeable volunteer can help me with this. Please
>     contact me directly if you think you could help.

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

> Would someone please offer to help?
> 
> >     Excellent question. The images can be referenced in various ways
> >     and I do not know of a good way to find these places other than
> >     grep. I would appreciate it if a knowledgeable volunteer can
> >     help me with this. Please contact me directly if you think you
> >     could help.

This volunteer would find the places in the code where the following
images are used:

    toolbar/alias
    toolbar/execute
    toolbar/highlight
    toolbar/mh-logo
    toolbar/page-down
    toolbar/refile
    toolbar/repack
    toolbar/reply-all
    toolbar/reply-from
    toolbar/reply-to
    toolbar/rescan
    toolbar/show
    toolbar/widen
    mail/reply2

If these are still only used within the MH-E package, they are done as
I'm handling the changes within the MH-E package. If outside, they would
make the relevant changes (TBD) in their local codebase, wait until I
check in my changes, test their changes, and then check in their
changes. I think that should work well.

Thanks.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Richard M. Stallman]

    This volunteer would find the places in the code where the following
    images are used:

I did a grep for find-image and found that various packages
encapsulate it.  I did not look at the code for those functions,
but there were only around 6 of them.  To look at each one
and where it is used would not take terribly long.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

>     This volunteer would find the places in the code where the following
>     images are used:
> 
> I did a grep for find-image and found that various packages
> encapsulate it.  I did not look at the code for those functions,
> but there were only around 6 of them.  To look at each one
> and where it is used would not take terribly long.

Thanks. Is find-image the only function that uses these images? If
that's case, you're right about it not taking long and I can make the
appropriate changes myself.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Richard M. Stallman]

    Thanks. Is find-image the only function that uses these images? 

I do not know, but I think so.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Bill Wohler]

I've moved just the MH-E images to etc/images for now. Please use "cvs
up -d" to get the new etc/images/mail directory.

There was a small 30 second window where the .pbm images did not have
the -kb sticky flag. Run "cvs stat etc/images/refresh.pbm" and ensure
the -kb sticky flag is present. If not, run "cvs up -C etc/images."
Don't do this if you've been editing some images!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Shall we use etc/images more?

[Chong Yidong]

How about this patch?  It changes find-image to look for an image file
in etc/images first, then in etc/, then in the load-path.  The last
two are for backward compatibility, the idea being that images should
go into etc/images by default.

For example, if foobar.el needs an image that is installed into
etc/images/foobar/foo.xpm, it calls

(defimage foo-image ((:type xpm :file "foobar/foo.xpm" ....)))


*** emacs/lisp/image.el.~1.48.~	2005-08-06 18:13:43.000000000 -0400
--- emacs/lisp/image.el	2005-09-14 03:55:29.000000000 -0400
***************
*** 286,292 ****
  specification to be returned.  Return nil if no specification is
  satisfied.
  
! The image is looked for first on `load-path' and then in `data-directory'."
    (let (image)
      (while (and specs (null image))
        (let* ((spec (car specs))
--- 286,293 ----
  specification to be returned.  Return nil if no specification is
  satisfied.
  
! The image is looked for first in `data-directory'/images, then in
! `data-directory', then in `load-path'."
    (let (image)
      (while (and specs (null image))
        (let* ((spec (car specs))
***************
*** 296,315 ****
  	     found)
  	(when (image-type-available-p type)
  	  (cond ((stringp file)
! 		 (let ((path load-path))
! 		   (while (and (not found) path)
! 		     (let ((try-file (expand-file-name file (car path))))
! 		       (when (file-readable-p try-file)
! 			 (setq found try-file)))
! 		     (setq path (cdr path)))
! 		   (unless found
! 		     (let ((try-file (expand-file-name file data-directory)))
! 		       (if (file-readable-p try-file)
! 			   (setq found try-file))))
! 		   (if found
! 		       (setq image
! 			     (cons 'image (plist-put (copy-sequence spec)
! 						     :file found))))))
  		((not (null data))
  		 (setq image (cons 'image spec)))))
  	(setq specs (cdr specs))))
--- 297,323 ----
  	     found)
  	(when (image-type-available-p type)
  	  (cond ((stringp file)
! 		 (if (or (file-readable-p
! 			  (setq found
! 				(expand-file-name
! 				 file
! 				 (concat data-directory "/images"))))
! 			 (file-readable-p
! 			  (setq found
! 				(expand-file-name file data-directory)))
! 			 (let ((path load-path))
! 			   (setq found nil)
! 			   (while (and (not found) path)
! 			     (unless (file-readable-p
! 				      (setq found (expand-file-name
! 						   file (car path))))
! 			       (setq found nil))
! 			     (setq path (cdr path)))
! 			   found))
! 		     ;; image file found
! 		     (setq image
! 			   (cons 'image (plist-put (copy-sequence spec)
! 						   :file found)))))
  		((not (null data))
  		 (setq image (cons 'image spec)))))
  	(setq specs (cdr specs))))

Re: Shall we use etc/images more?

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> How about this patch?  It changes find-image to look for an image file
> in etc/images first, then in etc/, then in the load-path.  The last
> two are for backward compatibility, the idea being that images should
> go into etc/images by default.
>

IMO, This is a good approach.

However, I would suggest that you define an image-load-path
variable like this:

(defvar image-load-path '("etc/images/" "etc/" load-path)
  "List of directories and other load paths to search for images.
If element is a string, it defines a directory to search.
Non-absolute directories are relative to `data-directory'.
If element is a variable symbol, the value of that variable
is used as a load-path of directories to search.")


Then modify this part of your patch

> ! 		 (if (or (file-readable-p
> ! 			  (setq found
> ! 				(expand-file-name
> ! 				 file
> ! 				 (concat data-directory "/images"))))
> ! 			 (file-readable-p
> ! 			  (setq found
> ! 				(expand-file-name file data-directory)))
> ! 			 (let ((path load-path))
> ! 			   (setq found nil)
> ! 			   (while (and (not found) path)
> ! 			     (unless (file-readable-p
> ! 				      (setq found (expand-file-name
> ! 						   file (car path))))
> ! 			       (setq found nil))
> ! 			     (setq path (cdr path)))
> ! 			   found))

to call the function below like this:

   (setq found (image-search-load-path file image-load-path))


(defun image-search-load-path (file path)
  (let (found)
    (while (and (not found) (consp path))
       (cond
         ((stringp (car path))
          (setq found (expand-file-name file
                        (expand-file-name (car path) data-directory))
         ((and (symbolp (car path) (boundp (car path)))
          (setq found (image-search-load-path file (symbol-value (car path)))))))))
       (setq path (cdr path)))
    found))


WDYT?
        
> For example, if foobar.el needs an image that is installed into
> etc/images/foobar/foo.xpm, it calls
>
> (defimage foo-image ((:type xpm :file "foobar/foo.xpm" ....)))
>
>
> *** emacs/lisp/image.el.~1.48.~	2005-08-06 18:13:43.000000000 -0400
> --- emacs/lisp/image.el	2005-09-14 03:55:29.000000000 -0400
> ***************
> *** 286,292 ****
>   specification to be returned.  Return nil if no specification is
>   satisfied.
>   
> ! The image is looked for first on `load-path' and then in `data-directory'."
>     (let (image)
>       (while (and specs (null image))
>         (let* ((spec (car specs))
> --- 286,293 ----
>   specification to be returned.  Return nil if no specification is
>   satisfied.
>   
> ! The image is looked for first in `data-directory'/images, then in
> ! `data-directory', then in `load-path'."
>     (let (image)
>       (while (and specs (null image))
>         (let* ((spec (car specs))
> ***************
> *** 296,315 ****
>   	     found)
>   	(when (image-type-available-p type)
>   	  (cond ((stringp file)
> ! 		 (let ((path load-path))
> ! 		   (while (and (not found) path)
> ! 		     (let ((try-file (expand-file-name file (car path))))
> ! 		       (when (file-readable-p try-file)
> ! 			 (setq found try-file)))
> ! 		     (setq path (cdr path)))
> ! 		   (unless found
> ! 		     (let ((try-file (expand-file-name file data-directory)))
> ! 		       (if (file-readable-p try-file)
> ! 			   (setq found try-file))))
> ! 		   (if found
> ! 		       (setq image
> ! 			     (cons 'image (plist-put (copy-sequence spec)
> ! 						     :file found))))))
>   		((not (null data))
>   		 (setq image (cons 'image spec)))))
>   	(setq specs (cdr specs))))
> --- 297,323 ----
>   	     found)
>   	(when (image-type-available-p type)
>   	  (cond ((stringp file)
> ! 		 (if (or (file-readable-p
> ! 			  (setq found
> ! 				(expand-file-name
> ! 				 file
> ! 				 (concat data-directory "/images"))))
> ! 			 (file-readable-p
> ! 			  (setq found
> ! 				(expand-file-name file data-directory)))
> ! 			 (let ((path load-path))
> ! 			   (setq found nil)
> ! 			   (while (and (not found) path)
> ! 			     (unless (file-readable-p
> ! 				      (setq found (expand-file-name
> ! 						   file (car path))))
> ! 			       (setq found nil))
> ! 			     (setq path (cdr path)))
> ! 			   found))
> ! 		     ;; image file found
> ! 		     (setq image
> ! 			   (cons 'image (plist-put (copy-sequence spec)
> ! 						   :file found)))))
>   		((not (null data))
>   		 (setq image (cons 'image spec)))))
>   	(setq specs (cdr specs))))
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>

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

Re: Shall we use etc/images more?

[Chong Yidong]

> IMO, This is a good approach.
>
> However, I would suggest that you define an image-load-path
> variable like this...

Good idea.  Here's a revised patch:

*** emacs/lisp/image.el.~1.48.~	2005-08-06 18:13:43.000000000 -0400
--- emacs/lisp/image.el	2005-09-14 19:50:41.000000000 -0400
***************
*** 49,54 ****
--- 49,61 ----
  with one argument, a string containing the image data.  If PREDICATE returns
  a non-nil value, TYPE is the image's type.")
  
+ (defvar image-load-path
+   (list (concat data-directory "images/") data-directory 'load-path)
+   "List of locations in which to search for image files.
+ If an element is a string, it defines a directory to search.
+ If an element is a variable symbol, the value of that variable is
+ used as a list of directories to search.")
+ 
  (defun image-jpeg-p (data)
    "Value is non-nil if DATA, a string, consists of JFIF image data.
  We accept the tag Exif because that is the same format."
***************
*** 269,274 ****
--- 276,292 ----
  	  (delete-overlay overlay)))
        (setq overlays (cdr overlays)))))
  
+ (defun image-search-load-path (file path)
+   (let (found)
+     (while (and (not found) (consp path))
+       (cond
+        ((stringp (car path))
+ 	(setq found (file-readable-p (expand-file-name (car path)))))
+        ((and (symbolp (car path)) (boundp (car path)))
+ 	(setq found (image-search-load-path
+ 		     file (symbol-value (car path))))))
+       (setq path (cdr path)))
+     found))
  
  ;;;###autoload
  (defun find-image (specs)
***************
*** 286,292 ****
  specification to be returned.  Return nil if no specification is
  satisfied.
  
! The image is looked for first on `load-path' and then in `data-directory'."
    (let (image)
      (while (and specs (null image))
        (let* ((spec (car specs))
--- 304,310 ----
  specification to be returned.  Return nil if no specification is
  satisfied.
  
! The image is looked for in `image-load-path'."
    (let (image)
      (while (and specs (null image))
        (let* ((spec (car specs))
***************
*** 296,315 ****
  	     found)
  	(when (image-type-available-p type)
  	  (cond ((stringp file)
! 		 (let ((path load-path))
! 		   (while (and (not found) path)
! 		     (let ((try-file (expand-file-name file (car path))))
! 		       (when (file-readable-p try-file)
! 			 (setq found try-file)))
! 		     (setq path (cdr path)))
! 		   (unless found
! 		     (let ((try-file (expand-file-name file data-directory)))
! 		       (if (file-readable-p try-file)
! 			   (setq found try-file))))
! 		   (if found
! 		       (setq image
! 			     (cons 'image (plist-put (copy-sequence spec)
! 						     :file found))))))
  		((not (null data))
  		 (setq image (cons 'image spec)))))
  	(setq specs (cdr specs))))
--- 314,324 ----
  	     found)
  	(when (image-type-available-p type)
  	  (cond ((stringp file)
! 		 (if (setq found (image-search-load-path
! 				  file image-load-path))
! 		     (setq image
! 			   (cons 'image (plist-put (copy-sequence spec)
! 						   :file found)))))
  		((not (null data))
  		 (setq image (cons 'image spec)))))
  	(setq specs (cdr specs))))

Re: Shall we use etc/images more?

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> Good idea.  Here's a revised patch:

Looks good to me.

You should wait for RMS approval before installing though.


There's one bug though:

> + 	(setq found (file-readable-p (expand-file-name (car path)))))

(setq found (file-readable-p (expand-file-name file (car path)))))

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

Re: Shall we use etc/images more?

[Richard M. Stallman]

    You should wait for RMS approval before installing though.

The basic ideas are fine with me.  If it works, please install it.

But first, please write the changes for etc/NEWS and the Lisp manual.

Re: Shall we use etc/images more?

[Katsumi Yamaoka]

>>>>> In <87wtljurw2.fsf@stupidchicken.com> Chong Yidong wrote:

> + (defvar image-load-path
> +   (list (concat data-directory "images/") data-directory 'load-path)
> +   "List of locations in which to search for image files.
> + If an element is a string, it defines a directory to search.
> + If an element is a variable symbol, the value of that variable is
> + used as a list of directories to search.")

It would be better to use the symbol `data-directory' rather
than its value there.  It is because some programs, e.g., Gnus,
bind the value of `data-directory' when finding image files.  It
also requires changing of the `image-search-load-path' function.

I've changed Gnus in cvs.gnus.org so as to bind `image-load-path'
too, though.

Re: Shall we use etc/images more?

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> I'll try to send out a proposal by early next week with the list of
> affected image files.

This email lists the images in use by the MH-E package today, explains
how they got there, and proposes new locations in etc/images for them.
At the end, I also suggest some code changes to image.el.


These are the (pbm and xpm) images the MH-E project has installed:

    toolbar/alias
    toolbar/execute
    toolbar/highlight
    toolbar/mh-logo
    toolbar/page-down
    toolbar/refile
    toolbar/repack
    toolbar/reply-all
    toolbar/reply-from
    toolbar/reply-to
    toolbar/rescan
    toolbar/show
    toolbar/widen
    mail/reply2

They are in the toolbar directory since the images were added before
MH-E had its own directory, and were put there instead of the mail
directory at RMSs urging. I think the mail-specific images lack a
mail- prefix because of 8.3 restrictions. I don't remember why reply2
went into the mail directory, but we added the -2 suffix to avoid
potential conflicts with Gnus.

One way to reorganize these--assuming that other packages haven't used
them yet--is to put them all into etc/images/mh-e. However, in the
interest of sharing images, I propose the following structure instead:
    
    etc/images/mail/alias -- adds the current sender to your alias file
    etc/images/mail/refile -- files the message(s)
    etc/images/mail/repack -- renumbers the messages, removing gaps
    etc/images/mail/reply -- different flavors of replies
    etc/images/mail/reply-all
    etc/images/mail/reply-from
    etc/images/mail/reply-to
    etc/images/mail/rescan -- updates the message listing
    etc/images/mail/show -- display the current message
    etc/images/mail/widen -- removes a view restriction
    etc/images/mh-e/mh-logo
    etc/images/execute -- could be used by the dired `x' command
    etc/images/highlight -- used to add a persistent mark
    etc/images/page-down

Instead of putting all of the images in a single directory and using
the convention of preceding an image name with mail-, for example, it
would be preferable to use the directory structure for this purpose.
Shortening the file names makes it easier to be 8.3 compliant, and is
essential in the images above.

Three of the images could be generally useful and could be placed at
the top-level. It's possible I've overlooked other general images, so
feel free to comment. Maybe repack is too MH-specific and should be in
the MH-E directory?

Gnus uses mm-image-load-path to add etc/images/gnus to the load-path
if it finds an ../etc/images/gnus directory relative to another
directory in the load-path. We'd have to do something like that as
well since we the user can run a version of MH-E outside of the Emacs
tree. Unfortunately, the function adds "gnus" by default so in the
short term we'd create our own version.

In the long term, I think we should modify find-image to use the
algorithm in mm-image-load-path instead of using just data-directory.
That would make find-image more flexible by finding all relevant
etc/images directories so that mm-image-load-path (and MH-E's variant)
would no longer be necessary. It could easily be made backward
compatible by stripping "images/" from a file spec.

If that's not in Emacs' interest, then I would suggest that instead of
(or in addition to) using data-directory, find-image should check a
new variable called image-directory (default: $EMACS_ROOT/etc/images)
which MH-E and Gnus can modify accordingly.

Gnus adds etc/images/gnus to the load-path so that it can refer to the
images directly like "exit-gnus" instead of "gnus/exit-gnus". I think
I'd prefer to specify the images explicitly as in "execute" or
"mail/reply". This would make the code impervious to future changes of
find-image and I think the slightly longer names would improve
maintenance by making it easier to find the images. It also eliminates
name collisions that we have in the current scheme.

Thoughts? Questions? Comments?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Kim F. Storm]

Bill Wohler <wohler@newt.com> writes:


> One way to reorganize these--assuming that other packages haven't used
> them yet--is to put them all into etc/images/mh-e. However, in the
> interest of sharing images, I propose the following structure instead:

I haven't looked at the actual icons, but from your described
use, they sound more generally useful...

>     
>     etc/images/mail/alias -- adds the current sender to your alias file

Add XX item to YY list/file.

>     etc/images/mail/rescan -- updates the message listing

Refresh

>     etc/images/mail/show -- display the current message

Display current ITEM

>     etc/images/mail/widen -- removes a view restriction

Widen -- in general

> Shortening the file names makes it easier to be 8.3 compliant, and is
> essential in the images above.

Does emacs support images on any of the 8.3 limited systems?

> Three of the images could be generally useful and could be placed at
> the top-level. It's possible I've overlooked other general images, so
> feel free to comment. Maybe repack is too MH-specific and should be in
> the MH-E directory?
>
> In the long term, I think we should modify find-image to use the
> algorithm in mm-image-load-path instead of using just data-directory.

That's a good suggestion.

> That would make find-image more flexible by finding all relevant
> etc/images directories so that mm-image-load-path (and MH-E's variant)
> would no longer be necessary.

To me it seems that having a generic image-load-path would be
preferable!?  It could be setup automatically to include
subdirectories of etc/images/, just like load-path includes
subdirectories of lisp/

> It could easily be made backward
> compatible by stripping "images/" from a file spec.

Yes.

> If that's not in Emacs' interest, then I would suggest that instead of
> (or in addition to) using data-directory, find-image should check a
> new variable called image-directory (default: $EMACS_ROOT/etc/images)
> which MH-E and Gnus can modify accordingly.

That may be a good alternative to image-load-path, if we require 
using explicit subdirs in the image names, e.g. mail/reply.

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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Shall we use etc/images more?

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 13 Sep 2005 11:23:21 +0200
> Cc: mh-e-devel@lists.sourceforge.net, emacs-devel@gnu.org
> 
> > Shortening the file names makes it easier to be 8.3 compliant, and is
> > essential in the images above.
> 
> Does emacs support images on any of the 8.3 limited systems?

It doesn't, but that's not the issue.  The issue is that if we have in
the Emacs distro files whose names clash after 8+3 truncation, then
Emacs distribution cannot be unpacked on such a filesystem without, at
best, troubling questions being asked by the unpacking utility, and at
worst overwriting files without notice.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Bill Wohler]

Thanks much for the quick feedback.

Kim F. Storm <storm@cua.dk> wrote:

> >     
> >     etc/images/mail/alias -- adds the current sender to your alias file
> 
> Add XX item to YY list/file.

Yes and no. If you're add X, Y, and Z items to XX, YY, and ZZ lists,
then having three identical icons to do those things isn't terribly
useful. I don't think I can buy this suggestion quite yet.

> >     etc/images/mail/rescan -- updates the message listing
> 
> Refresh

Like in a browser. Hmmm. That might work. What does the MH-E gang think
about replacing the cabinet icon with a more well-known refresh icon
(two arrows chasing the other's tail) and renaming rescan (the icon) to
refresh?

> >     etc/images/mail/show -- display the current message
> 
> Display current ITEM

Yes. I think our icon would work for dired even.

> >     etc/images/mail/widen -- removes a view restriction
> 
> Widen -- in general

Yes.

> > In the long term, I think we should modify find-image to use the
> > algorithm in mm-image-load-path instead of using just data-directory.
> 
> That's a good suggestion.

Thanks. However, I'm not entirely sure about this now since find-image
would have to keep track of when it updated the load-path and re-run the
algorithm whenever it detects that load-path changes, which would be
kind of a pain. I think I liked your suggestion about image-load-path,
although one problem with this that just occurred to me is that it would
add a little complexity to the user's environment and may not have the
benefit to counter that complexity. So, perhaps RMS is right.

Richard M. Stallman <rms@gnu.org> wrote:

>     I don't remember why reply2
>     went into the mail directory, but we added the -2 suffix to avoid
>     potential conflicts with Gnus.
> 
> If Gnus and MH-E both want an icon for replies, shouldn't they both
> use the same one?

Yes.

> This makes sense, except that having a subdirectory mh-e just to
> contain one file is pointless.  It would be better to use
> etc/images/mh-logo for that.

My thinking was that all icons at the top level are general icons that
could be used in any package. Icons that are only relevant to a single
package (or "virtual" package as in "mail") should be in a sub-directory
with the same name as that package. Thus, the directory serves not only
to reduce clutter, but to make it easier for someone to find an icon by
organizing them in groups rather than in a jumbled collection at the top
level. Does this sound like a good reason to you? On the other hand,
putting all of the application-identification icons (like mh-logo) in a
single directory makes it easier to find the one you want if you're
binding a desktop icon to your Emacs app (although the Gnome project
puts them in an "apps" directory which I could start). Given the size of
MH-E, it's also very possible that we may add more specific icons in the
future. I could go any of three ways as I've argued all sides ;-).

Should I put the mh-logo image in the top-level, in "mh-e", or in "apps"?

>     In the long term, I think we should modify find-image to use the
>     algorithm in mm-image-load-path instead of using just data-directory.
> 
> I think we should not do either of these; instead, we should do
> what you've suggested here.
> 
>     Gnus adds etc/images/gnus to the load-path so that it can refer to the
>     images directly like "exit-gnus" instead of "gnus/exit-gnus". 

By "here" I'm assuming that you think that the MH-E package should
modify the load-path as Gnus does?

>                                                                   I think
>     I'd prefer to specify the images explicitly as in "execute" or
>     "mail/reply"
> 
> I agree.

OK, I will do that.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Wohler <wohler@newt.com> writes:

> Kim F. Storm <storm@cua.dk> wrote:
> 
> > >     etc/images/mail/rescan -- updates the message listing
> > 
> > Refresh
> 
> Like in a browser. Hmmm. That might work. What does the MH-E gang think
> about replacing the cabinet icon with a more well-known refresh icon
> (two arrows chasing the other's tail) and renaming rescan (the icon) to
> refresh?

I like it.

	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFDJ8YNCg7APGsDnFERAsJvAKDdkQIsYuaDXsgUIDFjx1uLCh8fyQCguaaV
FChgpspQCxn2zIIueeUjauE=
=PLT1
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Richard M. Stallman]

    My thinking was that all icons at the top level are general icons that
    could be used in any package. Icons that are only relevant to a single
    package (or "virtual" package as in "mail") should be in a sub-directory
    with the same name as that package. Thus, the directory serves not only
    to reduce clutter, but to make it easier for someone to find an icon by
    organizing them in groups rather than in a jumbled collection at the top
    level. Does this sound like a good reason to you?

A subdir with one file in it is nothing but clutter.
It does not help anything.

I'd rather have a file called images/mh-logo than a directory called
images/mh-e, if I have the choice of one or the other.

    >     In the long term, I think we should modify find-image to use the
    >     algorithm in mm-image-load-path instead of using just data-directory.
    > 
    > I think we should not do either of these; instead, we should do
    > what you've suggested here.
    > 
    >     Gnus adds etc/images/gnus to the load-path so that it can refer to the
    >     images directly like "exit-gnus" instead of "gnus/exit-gnus". 

    By "here" I'm assuming that you think that the MH-E package should
    modify the load-path as Gnus does?

That's a misunderstanding.  I was not talking about the paragraph
starting "Gnus adds", I was talking about your suggestion to modify
find-image.  We should not modify load-path, and it should not search
for images through the subdirectories of etc/images.

Each place that refers to an image should specify the intended
subdirectory explicitly.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

> I'd rather have a file called images/mh-logo than a directory called
> images/mh-e, if I have the choice of one or the other.

OK.

> That's a misunderstanding.  I was not talking about the paragraph
> starting "Gnus adds", I was talking about your suggestion to modify
> find-image.  We should not modify load-path, and it should not search
> for images through the subdirectories of etc/images.

I'm glad I clarified. I had mentioned the creation of an image-directory
variable. However, I prefer Kim's suggestion of image-load-path since
that would allow an external package to use its own image directory in
addition to the standard images. Would you agree?

> Each place that refers to an image should specify the intended
> subdirectory explicitly.

Right. The default image-load-path would contain $EMACS_ROOT/etc/images
so that images would be specified relative to that.
 
-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Re: Shall we use etc/images more?

[Bill Wohler]

> revision 1.50
> date: 2005/09/18 14:04:46;  author: cyd;  state: Exp;  lines: +20 -11
> (image-load-path): Use symbol `data-directory' instead of its value,
> for backward compatibility with packages that bind it during
> `find-image'.  Suggested by Katsumi Yamaoka.
> (image-search-load-path): Handle symbols whose values are strings.
> ----------------------------
> revision 1.49
> date: 2005/09/15 14:00:09;  author: cyd;  state: Exp;  lines: +28 -15
> 2005-09-15  Chong Yidong  <cyd@stupidchicken.com>
> 
> 	* image.el (image-load-path): New variable.
> 	(image-search-load-path): New function.
> 	(find-image): Search for images in `image-load-path'.

Chong,

Thanks very much for making the image-load-path modifications to
find-image!

Were you planning on moving the images from toolbar and mail to
etc/images, or should I proceed as I have suggested? Actually, I had
suggested just moving the MH-E images, but it would probably be good for
completeness to move all of the images. Thoughts?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Shall we use etc/images more?

[Bill Wohler]

Regarding my last message about rehoming *all* of the images, I have the
following specific proposal.

Because the changes are large, I would like permission from the Emacs
royals before proceeding. Otherwise, I'll just move the MH-E images
(which, by the way, do not appear to be in use by other packages within
Emacs).

1. Move *all* of the images from lisp, lisp/toolbar, and lisp/mail to
   etc/images.

2. Rename any file with an underscore to one with a dash and update
   affected source files (affects MH-E, Gnus, info.el, tool-bar.el).

3. Move the gud-* files to etc/images/gud, strip the gud- prefix, and
   update lisp/progmodes/gud.el.

4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and
   update lisp/speedbar.el.

5. Because tool-bar.el will be the only file left in the lisp/toolbar
   directory, move it to lisp and delete lisp/toolbar.

These changes will affect other third-party packages. Because we're
making a major release, this should be acceptable I'd definitely update
NEWS with the specifics.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Shall we use etc/images more?

[Chong Yidong]

> 4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and
>    update lisp/speedbar.el.

I can handle this one.  A new version of speedbar, with a new set of
images, is due to be checked in as soon as the papers get settled
(there seems to be some delay at the FSF copyright assignment office).

Re: Shall we use etc/images more?

[Richard M. Stallman]

    1. Move *all* of the images from lisp, lisp/toolbar, and lisp/mail to
       etc/images.

    2. Rename any file with an underscore to one with a dash and update
       affected source files (affects MH-E, Gnus, info.el, tool-bar.el).

    3. Move the gud-* files to etc/images/gud, strip the gud- prefix, and
       update lisp/progmodes/gud.el.

    4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and
       update lisp/speedbar.el.

    5. Because tool-bar.el will be the only file left in the lisp/toolbar
       directory, move it to lisp and delete lisp/toolbar.

These plans sound good to me.  And speedbar has just been updated,
so there is no need to wait any longer before you do this.

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

> Bill Wohler <wohler@newt.com> wrote:
>
>     1. Move *all* of the images from lisp, lisp/toolbar, and lisp/mail to
>        etc/images.
> 
>     2. Rename any file with an underscore to one with a dash and update
>        affected source files (affects MH-E, Gnus, info.el, tool-bar.el).
> 
>     3. Move the gud-* files to etc/images/gud, strip the gud- prefix, and
>        update lisp/progmodes/gud.el.

Done.

>     4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and
>        update lisp/speedbar.el.

Done, thanks to Chong.

>     5. Because tool-bar.el will be the only file left in the lisp/toolbar
>        directory, move it to lisp and delete lisp/toolbar.
> 
> These plans sound good to me.  And speedbar has just been updated,
> so there is no need to wait any longer before you do this.

I'm starting to work on this.

I'm not sure whether to move the lc-* (low resolution copies) images to
etc/images/lc or leave them as etc/images/lc*. Thoughts?

Miles, shall I send a note to the Gnus folks about the changes, or will
you do so when you migrate the changes? They are impacted since the
mail_* images will move into the etc/images/mail directory. I'd also
like to ask them to use mail/reply instead of gnus/reply or
gnus/mail-reply.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Shall we use etc/images more?

[Romain Francoise]

When you move files around, please always reflect your changes in the
make-dist script, if appropriate.  Failure to do so results in
incomplete release tarballs.  (I fixed several omissions last week
already.)

-- 
Romain Francoise <romain@orebokech.com> | I used to think there is no
it's a miracle -- http://orebokech.com/ | future left at all.

Re: Shall we use etc/images more?

[Bill Wohler]

Romain Francoise <romain@orebokech.com> wrote:

> When you move files around, please always reflect your changes in the
> make-dist script, if appropriate.

Thank you. I just added the gud stuff to it. It appears that the two
sections that begin:

  echo "Creating subdirectories"
  echo "Making links to \`etc/images'"

are affected. There doesn't seem to be any changes required when I
delete the toolbar directory. Correct? 

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Shall we use etc/images more?

[Romain Francoise]

Bill Wohler <wohler@newt.com> writes:

> There doesn't seem to be any changes required when I delete the
> toolbar directory. Correct?

Yep, subdirectories of lisp/ are found automatically.

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | All you've been is a piece of
it's a miracle -- http://orebokech.com/ | blood wrapped in skin.

Re: Shall we use etc/images more?

[Richard M. Stallman]

    I'm not sure whether to move the lc-* (low resolution copies) images to
    etc/images/lc or leave them as etc/images/lc*. Thoughts?

The most natural thing would be to replace `lc-' with a suffix
or infix; instead of lc-foo.pbm, it would be foo-lc.pbm.
However, depending on the actual file names, that might cause
collisions on some systems.

I can't see find those files--or perhaps they don't exist in my
directory--so I can't see what the actual names look like.

Re: Shall we use etc/images more?

[Bill Wohler]

Richard M. Stallman <rms@gnu.org> wrote:

>     I'm not sure whether to move the lc-* (low resolution copies) images to
>     etc/images/lc or leave them as etc/images/lc*. Thoughts?
> 
> The most natural thing would be to replace `lc-' with a suffix
> or infix; instead of lc-foo.pbm, it would be foo-lc.pbm.
> However, depending on the actual file names, that might cause
> collisions on some systems.

Indeed, the previous prefix was "locol", but that was changed to "lc"
most likely for the reasons you cite.

When I saw how many images were in etc/images, I opted to put these
images in an "lc" sub-directory and strip the lc- prefix. Another
advantage of this is that we gain three characters of uniqueness in the
actual image names. This should allow for more descriptive names such as
ones that Nick used in the gud directory.

It also just occurred to me that we could now be more descriptive name
in the directory name as well by using low-color instead of lc.

What do you think?

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Shall we use etc/images more?

[Richard M. Stallman]

    It also just occurred to me that we could now be more descriptive name
    in the directory name as well by using low-color instead of lc.

    What do you think?

I don't care.

lisp/toolbar is gone (was: Shall we use etc/images more?)

[Bill Wohler]

"Richard M. Stallman" <rms@gnu.org> writes:

>     1. Move *all* of the images from lisp, lisp/toolbar, and lisp/mail to
>        etc/images.
>
>     2. Rename any file with an underscore to one with a dash and update
>        affected source files (affects MH-E, Gnus, info.el, tool-bar.el).
>
>     3. Move the gud-* files to etc/images/gud, strip the gud- prefix, and
>        update lisp/progmodes/gud.el.
>
>     4. Move the sb-* files to etc/images/speedbar, strip the sb- prefix, and
>        update lisp/speedbar.el.
>
>     5. Because tool-bar.el will be the only file left in the lisp/toolbar
>        directory, move it to lisp and delete lisp/toolbar.
>
> These plans sound good to me.  And speedbar has just been updated,
> so there is no need to wait any longer before you do this.

This has been done. Please run "cvs up -dP" to create the new
directories in etc/images and to prune lisp/toolbar.

lisp/ldefs-boot.el contains the string:

  :26219:;;;;;;  "toolbar/tool-bar.el" (17134 20613))

Is it worthwhile to check in the current loaddefs.el in its place?

etc/NEWS contains the following:

  *** The function `find-image' now searches in etc/images/ and etc/.
  The new variable `image-load-path' is a list of locations in which to
  search for image files.  The default is to search in etc/images, then
  in etc/, and finally in the directories specified by `load-path'.
  Subdirectories of etc/ and etc/images are not recursively searched; if
  you put an image file in a subdirectory, you have to specify it
  explicitly; for example, if an image is put in etc/images/foo/bar.xpm:

Is it worthwhile mentioning that all of the images have been moved?
Maybe not, but I think I should add a list of filenames that had
underscores that now have dashes since users will need to know to
update their code.

If you know of any changes that are required to the Emacs and Elisp,
please let me know which section you think would be best.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: lisp/toolbar is gone (was: Shall we use etc/images more?)

[Andreas Schwab]

Bill Wohler <wohler@newt.com> writes:

> lisp/ldefs-boot.el contains the string:
>
>   :26219:;;;;;;  "toolbar/tool-bar.el" (17134 20613))
>
> Is it worthwhile to check in the current loaddefs.el in its place?

Feel free to do that any time.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Re: Shall we use etc/images more?

[Richard M. Stallman]

    I don't remember why reply2
    went into the mail directory, but we added the -2 suffix to avoid
    potential conflicts with Gnus.

If Gnus and MH-E both want an icon for replies, shouldn't they both
use the same one?

    One way to reorganize these--assuming that other packages haven't used
    them yet--is to put them all into etc/images/mh-e. However, in the
    interest of sharing images, I propose the following structure instead:

	etc/images/mail/alias -- adds the current sender to your alias file
	etc/images/mail/refile -- files the message(s)
	etc/images/mail/repack -- renumbers the messages, removing gaps
	etc/images/mail/reply -- different flavors of replies
	etc/images/mail/reply-all
	etc/images/mail/reply-from
	etc/images/mail/reply-to
	etc/images/mail/rescan -- updates the message listing
	etc/images/mail/show -- display the current message
	etc/images/mail/widen -- removes a view restriction
	etc/images/mh-e/mh-logo
	etc/images/execute -- could be used by the dired `x' command
	etc/images/highlight -- used to add a persistent mark
	etc/images/page-down

This makes sense, except that having a subdirectory mh-e just to
contain one file is pointless.  It would be better to use
etc/images/mh-logo for that.

    Three of the images could be generally useful and could be placed at
    the top-level. It's possible I've overlooked other general images, so
    feel free to comment.

Conceptually, widen and rescan are not limited to mail,
so I think they ought to go at top level.

			  Maybe repack is too MH-specific and should be in
    the MH-E directory?

It's not worth having an mh-e directory just for that.

    In the long term, I think we should modify find-image to use the
    algorithm in mm-image-load-path instead of using just data-directory.

I think we should not do either of these; instead, we should do
what you've suggested here.

    Gnus adds etc/images/gnus to the load-path so that it can refer to the
    images directly like "exit-gnus" instead of "gnus/exit-gnus". I think
    I'd prefer to specify the images explicitly as in "execute" or
    "mail/reply"

I agree.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf