IRC Client for Emacs

IRC Client for Emacs

[Jonathan Walther]

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

Please consider this my vote for the ERC irc client.  I've been using it
for more than 6 months now, and love it.  I have found it easy to use with
no special configuration; (require 'erc) is all I needed to do.  Never
could wrap my head around ZenIRC

May I also take this time to ask that color-theme.el be added to the
Emacs distribution.

Jonathan

-- 
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: IRC Client for Emacs

[Damien Elmes]

Jonathan Walther <krooger@debian.org> writes:

> Please consider this my vote for the ERC irc client.  I've been using it
> for more than 6 months now, and love it.  I have found it easy to use with
> no special configuration; (require 'erc) is all I needed to do.  Never
> could wrap my head around ZenIRC
>
> May I also take this time to ask that color-theme.el be added to the
> Emacs distribution.

Make that another vote for ERC and color-theme :-)

-- 
Damien Elmes

color-theme.el

[Alex Schroeder]

Jonathan Walther <krooger@debian.org> writes:

> May I also take this time to ask that color-theme.el be added to the
> Emacs distribution.

A long time ago, I tried fiddling with the source Jan Vroonhofer wrote
for XEmacs in order to integrate "themes" with custom.  I also sent
the code to Dave Love at the time.  My color-theme.el does not use
this custom theme stuff, it implements themes by just redefining
faces, frame parameters, etc.  And I don't feel like getting the
custom-theme stuff to work anymore.  As far as I am concerned, these
last years have shown that there is just no need for that.

One minor problem that remains unsolved (but which I do not care
about) is non-perfect "undoing".  "undoing" the installation of a
theme happens by storing away snapshots of the faces and frame
parameters currently defined.  Invariably, this leads to small
inconsistencies.  Example:  Emacs starts, n faces are defined.  When
install a color-theme, this creates a snapshot with n faces and
installs the new theme.  This theme probably defines m faces, where m
> n.  When we uninstall the theme, n faces are reset (because only n
are stored in the snapshot).  The new faces (m - n) remain as defined
in the theme.  Anyway, that is the current situation.

As to the paperwork, I have the email addresses of all theme authors
on file, so I could arrange the paperwork.

Alex.

Re: color-theme.el

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> And I don't feel like getting the custom-theme stuff to work
> anymore.  As far as I am concerned, these last years have shown that
> there is just no need for that.

I think there is plenty of need, but nobody both able and willing to
do the work.  I tried to re-sync custom with the XEmacs version a
couple of years ago (which would have got us themes), and quickly
burned out.

So while I believe color-theme.el is the wrong solution, it is better
than the alternative, which is no solution.

Re: color-theme.el

[Richard Stallman]

    So while I believe color-theme.el is the wrong solution, it is better
    than the alternative, which is no solution.

What do you think is the right solution?

Re: color-theme.el

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     So while I believe color-theme.el is the wrong solution, it is better
>     than the alternative, which is no solution.
>
> What do you think is the right solution?

Integrate real themes, a.la. Jan Vroonhofs work.

Re: color-theme.el

[Richard Stallman]

    Integrate real themes, a.la. Jan Vroonhofs work.

What is better about that?  Would it provide more features (which),
work more reliably, be less code, or what?

Re: color-theme.el

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     Integrate real themes, a.la. Jan Vroonhofs work.
>
> What is better about that?  Would it provide more features (which),
> work more reliably, be less code, or what?

See my answer to Alex.

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     Integrate real themes, a.la. Jan Vroonhofs work.
>
> What is better about that?  Would it provide more features (which),
> work more reliably, be less code, or what?

There are two main advantages.

Here is how it basically works: A setting is tagged as coming from a
theme.  The settings currently loaded from .emacs or similar would be
tagged as coming from the "user" theme, and the standard values would
be tagged as coming from the "standard" theme.  Authors could now
write additional themes.  Anytime a variable is set via custom or
themes, this is recorded.

Advantage 1: When you customize variabes that where set via a theme,
the custom buffer could offer more information.  I faintly remember
that it currently just says that it was set using a theme.  But it
could name the theme, or even all the installed themes that tried
setting the variable (and the current value would be from the last
theme installed).

Advantage 2: When you undo a theme, custom can set the variable to
something else than the standard value or the saved (user) value.  It
can set it to the second-to-last installed theme, for example.

Or, putting it another way, assume a variable foo with a default value
of A.  The user customizes it to B and saves this.  In his .emacs, the
user then loads two themes, "theme 1" and "theme 2".  The first sets
foo to C, the second sets foo to D.

The value of foo is now D.  When "theme 2" is undone, the value will
be C.

Currently (and if we followed my much simple suggestions), the same
situation would result in a different end:  When Emacs starts, foo is
eventually set to D.  If you want to go back to the second-to-last
value (C), you might want to undo "theme 2".  But there is no way to
undo "theme 2", except to install "theme 1" again.  Custom would only
know the current value (D), the saved value (B) and the standard value
(A).

My position is that this is no great loss.

Alex.

Re: color-theme.el

[Richard Stallman]

It sounds like the big difference is that "real" themes handle
customizable variables (and face attributes?), whereas color-theme.el
just handles themes.  Is that a correct description?

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> It sounds like the big difference is that "real" themes handle
> customizable variables (and face attributes?), whereas color-theme.el
> just handles themes.  Is that a correct description?

Hm.  Not really.  Let me try to put it in your terms.

"real" themes can set customizable variables and customizable face
attributes, *plus* it can undo these settings when a theme is
uninstalled.

color-theme.el can set any variables, any face attributes, and frame
parameters, but no undoing of themes.

Alex.

Re: color-theme.el

[Richard Stallman]

    "real" themes can set customizable variables and customizable face
    attributes, *plus* it can undo these settings when a theme is
    uninstalled.

    color-theme.el can set any variables, any face attributes, and frame
    parameters, but no undoing of themes.

If that is the difference, then does the suggestion I sent in a previous
message on Aug 31 take care of doing it?

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     "real" themes can set customizable variables and customizable face
>     attributes, *plus* it can undo these settings when a theme is
>     uninstalled.
>
>     color-theme.el can set any variables, any face attributes, and frame
>     parameters, but no undoing of themes.
>
> If that is the difference, then does the suggestion I sent in a previous
> message on Aug 31 take care of doing it?

The existing code takes care of theme undoing, just as your suggestion
probably would.  Neither of them can install frame parameters,
however.  Then again, I don't know wether there are any settings in
Emacs 21 that can only be set via frame parameters.  All the settings
people use in color themes such as background-color, foreground-color,
cursor-color, and font can be set via faces.  The things we still
cannot set via faces or variables are not significant for color-themes
(frame sizes, for example).

If you really want undoing of themes, then your best bet is to take
the custom code that Dave Love has.

Alex.

Re: color-theme.el

[Alex Schroeder]

Alex Schroeder <alex@emacswiki.org> writes:

> If you really want undoing of themes, then your best bet is to take
> the custom code that Dave Love has.

What is the current status of this?

Alex.

Re: color-theme.el

[Richard Stallman]

    > If you really want undoing of themes, then your best bet is to take
    > the custom code that Dave Love has.

    What is the current status of this?

I asked Dave to send it to me and to you.  He responded "Alex who?"
and told me how to get diffs from CVS myself.  However, I have not
been in a situation where I can stay on the net long enough to do
that.

Re: color-theme.el

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I think there is plenty of need, but nobody both able and willing to
> do the work.  I tried to re-sync custom with the XEmacs version a
> couple of years ago (which would have got us themes), and quickly
> burned out.

Since RMS is interested, let me explain my position.  I worked on
porting the XEmacs code by Jan Vroonhof to Emacs, so I know something
about the code.  (I actually met him in person in Zuerich before doing
it!)  I think the code is complex.  I really tried to make it happen.
I even proposed a solution to make alists customizable.  This was one
of the open problems.  And yet, I am convinced that we do not need
this complexity.  We should not bother.  Why?

First, let us look at the kind of effort involved in using
cus-theme.el.  To create a theme involves about as much work as
writing a setq statement for all the variables, and giving this
collection of settings a name.  So for an author, there is no benefit
compared to writing a defun.  The defun has a name and can set tons of
variables.  The benefit for users is that undoing the theme is
straightforward.

Now, let us look at the scenarios where this is going to be used.  One
of the examples cited is that authors at big sites could prepare
themes so that their users can selectively do and undo the site
settings.  But how many users are there that actually need this?
Power users will skip the site code and do it all in their own .emacs
file.  Newbies will rely on the site code.  In the few cases, where
more choice is involved, big sites have already done the correct
thing:  They offer a collection of functions that users can call from
their .emacs to selectively install parts of the site configuration.

If this is the only benefit, however, then perhaps we are better off
with another solution altogether:  Let us create a new list of
functions to call at startup.  Let us call it `startup-functions'.
Let us make this customizable.  Now site authors can install a
suitable default, and users can still customize it to their liking.
The customizations will be saved to their .emacs file.  Problem
solved!  And the solution was easy to understand.

Now let us look at another problem.  For example my problem <grin>: A
color theme package.  What is the requirement?  People want to call a
function that sets lots of faces and variables.  People might want to
undo this once or twice.  Well, using the existing custom machinery, I
was able to implement this easily!  Problem solved!  People do not
want to do fancy stuff with themes.  Just setting the variables is
enough.  And even simple undoing the settings is possible, because we
have the normal custom stuff in place.

Sure, this does not solve the problem of people installing themes A,
B, and C, and then undoing the settings of B.  What settings should be
used now?  Something equivalent to installing only A and C.  But do
users really want this?  My claim is that they do not.  cus-theme.el
is going for the perfect solution, but nobody needs it enough to fix
it.

This holds, eventhough there is very little fixing to do.  When I
finished porting the code, it worked.  All I asked for was some
testing, and for some feedback for the alist customizing (I called
them diff-lists at the time).  It does not even matter wether Dave
Love looked at the code or not -- nobody ever asked about it anyway!
Thus I conclude that nobody is suffering from a problem.

Note that the totally perfect solution would use cus-theme.el, and
implemented some UI for theme authors.  Currently nobody seems to have
such ideas.  I faintly remember that I used a widget for simple theme
creation at the time.  But nobody tested that, either.

And guess what?  My color-theme.el provides a possibility to save a
snapshot of the current configuration.  Thus M-x customize-faces
suddenly is the interface to produce new themes.  What else could a
user possibly want.  So not even that is really needed.

Thus here is my opinion on the cus-theme.el efforts: Implementing the
perfect solution took effort (cus-theme.el, my simple make-theme.el),
still is not finished (a more elaborate UI might be required, real
testing), is not required for power users, is not required for
newbies, does not help site administrators, does not improve the
color-theme.el experience, is not asked for in the newsgroups.  

"As far as I am concerned, these last years have shown that there is
just no need for that."

Alex.

Re: color-theme.el

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
> First, let us look at the kind of effort involved in using
> cus-theme.el.  To create a theme involves about as much work as
> writing a setq statement for all the variables, and giving this
> collection of settings a name.  So for an author, there is no benefit
> compared to writing a defun.  The defun has a name and can set tons of
> variables.  The benefit for users is that undoing the theme is
> straightforward.

Jan Vroonhofs code is only the first (Lisp) step, the second step
would be to add theme commands to the customize UI, like "add setting
to theme", and "save theme".

This would allow users with no knowledge of Lisp to create and share
customizations, and, in my opinion, give them a first taste of the
free software culture of sharing.

They already do this, but they share entire "customize-set-variables"
sections, which we know doesn't work well.

> If this is the only benefit,

It isn't.  Large packages like Gnus can offer "build-in" themes for
e.g. slow and fast connections, and fancy and boring display (which in
Gnus involves much more than just faces).

Emacs itself could come with some themes, such as an "Emacs 20" theme
for people who dislike the UI changes in Emacs 21.

> however, then perhaps we are better off with another solution
> altogether: Let us create a new list of functions to call at
> startup.  Let us call it `startup-functions'.  Let us make this
> customizable.  Now site authors can install a suitable default, and
> users can still customize it to their liking.  The customizations
> will be saved to their .emacs file.  Problem solved!  And the
> solution was easy to understand.

The problem is that any individual option set by "setq" from a funtion
in such a list will overwrite the users individual customization of
that item.  With Jans themes it is the other way around, the explicit
individual settings will overwrite the the settings.

This benefit come both from package themes, other users themes, and
site themes.  They could all be done with functions and setq, but Jans
themes makes it possible to prioritize them when they conflict, and
overwrite individual options.

> "As far as I am concerned, these last years have shown that there is
> just no need for that."

I don't think you can scale the experience gained from the existence
of an unbundled package, to themes being integrated in Emacs.
Hopefully, the later will mean many more themes will be available,
with increasing need for conflict resolution and overwriting
individual choises.

Re: color-theme.el

[Alex Schroeder]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Jan Vroonhofs code is only the first (Lisp) step, the second step
> would be to add theme commands to the customize UI, like "add setting
> to theme", and "save theme".

I had a very simple UI that would allow me to specify the variables
that are part of the theme, the name of theme, and a file name.  It
would then save the appropriate lisp code.  It was trivial.

> This would allow users with no knowledge of Lisp to create and share
> customizations, and, in my opinion, give them a first taste of the
> free software culture of sharing.  They already do this, but they
> share entire "customize-set-variables" sections, which we know
> doesn't work well.

I think we could write something like that without the need for
cus-theme.el.  A wizard using widget.el that lets you specify the
variables that are part of the theme, the name of theme, and a file
name.  It would then save the appropriate lisp code -- a bunch of setq
statements (in a defun, with appropriate call to `provide').

We would then modify the `startup-functions' idea I presented in an
earlier mail: Let it be called `startup-requires'.  Users could then
save the file with the generated setq statements in their load-path,
and customize `startup-requires' such that the appropriate theme is
loaded, and the variables are set, at startup time.

This would provide the user experience you describe, with very little
work required.

> Large packages like Gnus can offer "build-in" themes for e.g. slow
> and fast connections, and fancy and boring display (which in Gnus
> involves much more than just faces).  Emacs itself could come with
> some themes, such as an "Emacs 20" theme for people who dislike the
> UI changes in Emacs 21.

Sure -- but do we need the real theme code, with precedences,
selective uninstalling, etc?  Would a bunch of setq not do the job?
You think it would not, I think it would.  I don't think we can decide
that at the moment.  The only thing I know is that I have not seen any
requests for it, in the limited time I spend on the newsgroups these
days.

> The problem is that any individual option set by "setq" from a funtion
> in such a list will overwrite the users individual customization of
> that item.  With Jans themes it is the other way around, the explicit
> individual settings will overwrite the the settings.

If we want that, let the customization of `startup-requires' be the
first thing acted upon when doing customization.  Then individual
settings will still overwrite stuff installed via startup-requires.

> I don't think you can scale the experience gained from the existence
> of an unbundled package, to themes being integrated in Emacs.

Well, if I cannot generalize it from the existing themes I maintain,
who is going to offer an opinion?  Nobody else is maintaining anything
like it.  We could compare it to Gnus group parameters, perhaps.
These are also settings saved outside of .emacs and custom.  Or the
.newsrc.el file.  But I find it difficult to draw conclusions from
it.  It seems to me that my basis for prediction is small, but
everybody else's basis is even smaller.

> Hopefully, the later will mean many more themes will be available,
> with increasing need for conflict resolution and overwriting
> individual choises.

I'm not sure how conflict resolution will actually improve.  I think
the user experience  will turn out to be something like this:  

A: Why does this and that not work?
B: What themes do you have installed?
A: X and Y.
B: Ah, these conflict, you must uninstall one of them.
A: Oh.

If so, then this user experience can be had using my simple idea I
offered at the top, using a widget to save setq in files, take
advantage of the require/provide conventions, introducing the new
option startup-requires, which means adding a bit of code to the place
where .emacs is read, and adding a bit of code to the place where
customizations are saved.  That seems to be far less than the entire
cus-theme.el stuff.  And I am saying these eventhough I ported Jan's
code from XEmacs to Emacs!

Alex.

Re: color-theme.el

[Per Abrahamsen]

Alex Schroeder <alex@emacswiki.org> writes:

> Well, if I cannot generalize it from the existing themes I maintain,
> who is going to offer an opinion?  

Everyone can offer an opinion, but nobody can do so based on realistic
empirical data, as no such data exists.  It is basically a question of
intuition how popular themes are going to be, and what they will be
used for.  

Your scheme won't integrate cleanly with customize (the option will be
marked "rogue", i.e. "option is changed outside customize"), which is
my major emotional problem with it.  It will make customize less
useful than now, when another major customization feature doesn't
"play nice" with it.

> And I am saying these eventhough I ported Jan's code from XEmacs to
> Emacs!

I did so too, at least the Lisp part.  I remember writing ChangeLogs
for them once.

Unrelated to what is best, having different schemes for Emacs and
XEmacs is certainly going to make them both much less useful.
Especially for cross-platform packages like Gnus.

But as I said before, if nobody is actually going to do the work of
integrating Jan's themes in GNU Emacs, your stuff is better than
nothing.  And since I'm not volunteering (again) and you are, your
opinion should carrry more weight.

Re: color-theme.el

[Richard Stallman]

    I think we could write something like that without the need for
    cus-theme.el.  A wizard using widget.el that lets you specify the
    variables that are part of the theme, the name of theme, and a file
    name.  It would then save the appropriate lisp code -- a bunch of setq
    statements (in a defun, with appropriate call to `provide').

    We would then modify the `startup-functions' idea I presented in an
    earlier mail: Let it be called `startup-requires'.  Users could then
    save the file with the generated setq statements in their load-path,
    and customize `startup-requires' such that the appropriate theme is
    loaded, and the variables are set, at startup time.

    This would provide the user experience you describe, with very little
    work required.

This may not be a very large job, but the first part is not
trivial--do you want to do it?

As for the feature of using multiple themes, of being able to add and
remove themes from the list and have the right thing happen, I think I
see an easy way to add that.  We just have to make sure that each
theme function saves the old values of the variables that it sets, so
that it can "turn itself off" later on.

Then, when the user edits the list of currently enabled themes, here's
what you do.  You turn off all the themes in the list, in reverse
order.  You change the list.  Then you turn on the themes that are now
in the list.

    > The problem is that any individual option set by "setq" from a funtion
    > in such a list will overwrite the users individual customization of
    > that item.  With Jans themes it is the other way around, the explicit
    > individual settings will overwrite the the settings.

    If we want that, let the customization of `startup-requires' be the
    first thing acted upon when doing customization.

That would work at startup.  To make it work right for editing the
list later would take a little more.  These theme functions could
carefully avoid setting variables that are marked as customized.

This probably means that instead of using setq directly, they should
use a macro `theme-setq' to set each variable.  The macro would take care of
recording the old value, not setting variables that are customized,
etc.

Would this give equivalent benefits to cus-theme.el?

    Your scheme won't integrate cleanly with customize (the option will be
    marked "rogue", i.e. "option is changed outside customize"), which is
    my major emotional problem with it.

Would it be difficult to create a new status value, "set by a theme"?
theme-setq could mark the variable with this status.


Meanwhile, would anyone be willing to step forward to integrate
cus-theme.el into Emacs?

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> This may not be a very large job, but the first part is not
> trivial--do you want to do it?

I might want to do this; however...

> As for the feature of using multiple themes, of being able to add and
> remove themes from the list and have the right thing happen, I think I
> see an easy way to add that.  We just have to make sure that each
> theme function saves the old values of the variables that it sets, so
> that it can "turn itself off" later on.

If you want the feature, then we should test and use the cus-theme.el
I sent to Dave Love some time ago.

My argument was that we did not need the feature, therefore why bother
with the code.  If you want the feature, however, then there is no use
in reinventing it.  We might as well use the existing code.

As to color-theme.el, I therefore propose not to add it until
cus-theme.el is working.  Then we can use color-theme.el as the first
major test for the cus-theme.el code.

>     Your scheme won't integrate cleanly with customize (the option will be
>     marked "rogue", i.e. "option is changed outside customize"), which is
>     my major emotional problem with it.
>
> Would it be difficult to create a new status value, "set by a theme"?
> theme-setq could mark the variable with this status.

I think cus-theme.el does this, but I am not sure anymore.  I
currently do not have the code.  I wiped my disk at Easter by accident
and lost a lot of stuff.  And I did not do backups.  So I'd have to
ask Dave Love for a copy, or find an archive of the custom mailing
list.  I will mail Dave to see wether he still has it.

> Meanwhile, would anyone be willing to step forward to integrate
> cus-theme.el into Emacs?

The first step would be to install the code locally and play with it.
The work has already been done.

Alex.

Re: color-theme.el

[Richard Stallman]

    > As for the feature of using multiple themes, of being able to add and
    > remove themes from the list and have the right thing happen, I think I
    > see an easy way to add that.  We just have to make sure that each
    > theme function saves the old values of the variables that it sets, so
    > that it can "turn itself off" later on.

    If you want the feature, then we should test and use the cus-theme.el
    I sent to Dave Love some time ago.

Are you saying that cus-theme.el is a simple implementation of this
feature, and nothing more?  If that's the case, then it does seem like
this could be the code to use.  However, the other things that have
been said about cus-theme.el give the impression that it is not so
simple.

Could you tell me what you think on this particular question?

Dave, could you email me the cus-theme.el file that Alex sent you, so
I can take a look for myself?

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> Are you saying that cus-theme.el is a simple implementation of this
> feature, and nothing more?

cus-theme.el is an implementation of this complex feature.  Every
customizable variable has a property has an alist that associates
themes with value like a history.

> If that's the case, then it does seem like this could be the code to
> use.  However, the other things that have been said about
> cus-theme.el give the impression that it is not so simple.

Well, cus-theme.el implements a complex feature.  I did not want to
argue against cus-theme.el because its implementation was byzantine.
I argued against cus-theme.el because it implements a feature that is
useless to most if not all users.

Other people such as Per seem to want this feature, and you offered an
idea to implement this feature.  If people want his feature, then
cus-theme.el is the way to go.  In fact, all other solutions will
eventually do what cus-theme.el already does.  Therefore I think
cus-theme.el is our best bet -- *if* we want this feature.

cus-theme.el will need some improvements eventually to be able to use
this feature to its fullest.  Integrating cus-theme.el will allow us
to build on it, improve it, and use it for applications such as
color-theme.el -- since I will switch to using cus-theme.el if and
only if it is integrated into Emacs.

Eventhough cus-theme.el is currently not perfect, it fails in ways
that custom generally fails already: alists (default-frame-alist and
friends in particular) are problematic, frame local variables are not
supported, the only user interface that allows users to create themes
without writing the elisp by hand is my make-theme, which is very
simple, and there is currently no user interface (except for calling
the relevant commands manually using M-x) to manage themes (installing
and deinstalling them).

> Dave, could you email me the cus-theme.el file that Alex sent you, so
> I can take a look for myself?

You will need all the other cus*.el files as well, because they are
all affected.  Remeber, all variables and faces now maintain an alist
of theme-value associations.

Alex.

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     I think we could write something like that without the need for
>     cus-theme.el.  A wizard using widget.el that lets you specify the
>     variables that are part of the theme, the name of theme, and a file
>     name.  It would then save the appropriate lisp code -- a bunch of setq
>     statements (in a defun, with appropriate call to `provide').
>>
> This may not be a very large job, but the first part is not
> trivial--do you want to do it?

Sure.  If we do not use cus-theme, that would be very handy for
sharing settings.

Re: IRC Client for Emacs

[Richard Stallman]

    May I also take this time to ask that color-theme.el be added to the
    Emacs distribution.

What does this do, and how can I talk with the author?

Re: color-theme.el

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     May I also take this time to ask that color-theme.el be added to the
>     Emacs distribution.
>
> What does this do, and how can I talk with the author?

I am the author.  :)

Basically, it provides around 50 elisp functions that will change lots
of faces, frame-parameters, and variables, such as to change the look
of Emacs completely.

Since all 50 functions redefine lots of faces, the source file is VERY
large:

~/WWW/home/tuning $ ls -l ~/elisp/color-theme
total 635
drwxrwxr-x   2 alex     alex         4096 Aug 10 20:58 CVS
-rw-rw-r--   1 alex     alex         4195 Apr 30 00:32 color-theme-maker.el
-rw-rw-r--   1 alex     alex       634752 Aug 10 20:57 color-theme.el
-rw-rw-r--   1 alex     alex       569761 Aug 25 15:31 color-theme.elc
-rw-rw-r--   1 alex     alex         3097 Sep  1  2001 make-theme.el

The color-theme-maker.el allows you to combine several color themes
into new themes, by example taking all faces definitions of faces
starting with "gnus-" from theme A and all other faces from theme B.

make-theme.el allows you to split the color-theme.el file
automatically into an "engine" and on file per theme function.  We
could make only the engine part of Emacs, and let people distribute
themes by themselves.

Here is a very short example -- my favorite theme.  It installs
color-theme-gnome2, and then it does some slight modifications.  It
also illustrates that many themes include faces for packages that are
not part of Emacs.  I would not go through the trouble of removing
these, since I depend on theme contributions by users.

(defun color-theme-robin-hood ()
  "`color-theme-gnome2' with navajo white on green."
  (interactive)
  (color-theme-gnome2)
  (let ((color-theme-is-cumulative t))
    (color-theme-install
     '(color-theme-robin-hood
       ((foreground-color . "navajo white")
	(background-color . "#304020"))
       ((CUA-mode-read-only-cursor-color . "white"))
       (default ((t (nil))))
       (fringe ((t (:background "#003700"))))
       (header-line ((t (:background "#030" :foreground "#AA7"))))
       (ido-subdir-face ((t (:foreground "MediumSlateBlue"))))
       (menu ((t (:background "#304020" :foreground "navajo white"))))
       (modeline ((t (:background "dark olive green" :foreground "wheat"))))
       (semantic-dirty-token-face ((t (:background "grey22"))))
       (tool-bar ((t (:background "#304020" :foreground "wheat" :box (:line-width 1 :style released-button)))))
       (tooltip ((t (:background "lemon chiffon" :foreground "black"))))))))

The color theme selection buffer looks something like this:

    [Reset]                 Undo changes, if possible.
    [Quit]                  Bury this buffer.
    Aalto Dark              Jari Aalto <jari.aalto@poboxes.com>
    Aalto Light             Jari Aalto <jari.aalto@poboxes.com>
    Alice Blue              Girish Bharadwaj <girishb@gbvsoft.com>
    Arjen                   Arjen Wiersma <arjen@wiersma.org>
    Bharadwaj               Girish Bharadwaj <girishb@gbvsoft.com>
    Billw                   Bill White <billw@wolfram.com>
    BlackOnGray             Sudhir Bhojwani <sbhojwani@altoweb.com>
    Blipp Blopp             Thomas Sicheritz-Ponten<thomas@biopython.org>
    Black                   Jonadab <jonadab@bright.net>
    Blue Mood               Nelson Loyola <nloyola@yahoo.com>
    Blue Sea                Alex Schroeder <alex@gnu.org>
    Cheap Goldenrod         Alex Schroeder <alex@gnu.org>

etc.

As you can see, we would need assignments by all the authors.  Since
their email addresses are part of the source, however, this should be
easy to get.

Alex.


PS: Here is the commentary of color-theme.el.

;;; Commentary:

;; Sharing your current color setup:
;;
;; Use `color-theme-submit'.  If you have already invested time in
;; customizing Emacs faces, please consider sharing your current setup.
;; Make sure that color-theme.el is in your `load-path'.  Type M-x
;; load-library RET color-theme RET to load all the functions.  Type M-x
;; color-theme-submit RET and mail the result to the maintainer of this
;; package (see above for mail addres).
;;
;; If you want to make sure that all your customization was exported,
;; type M-x list-faces-display RET to get a list of all faces currently
;; defined.  This is the list of faces that `color-theme-print' uses.

;; Installing a color theme:
;;
;; Make sure that color-theme.el is in your `load-path'.  Type M-x
;; load-library RET color-theme RET to load all the functions.
;;
;; The main function to call is color-theme-select.  Type M-x
;; color-theme-select RET.  That creates a Color Theme Selection
;; buffer.  Press RET or `i' on a color theme to install it for the
;; rest of your session.
;;
;; If you want to install the color theme as soon as Emacs is started
;; up, read the description of the theme you like and remember the
;; name of the color theme function.  Press `d' on a color theme in
;; the Color Theme Selection buffer to read the description.  Assuming
;; you like the Gnome2 theme, you'll find that the function to use is
;; called `color-theme-gnome2'.  Add the following to the end of your
;; .emacs (removing the leading `;;').
;;
;; (require 'color-theme)
;; (color-theme-gnome2)

;; Changing menu colors:
;;
;; In Emacs 21 on X, you can set the menu colors and font using the
;; menu face.  Example for your .emacs file:
;;
;;   (set-face-font 'menu "7x14")
;;   (set-face-foreground 'menu "white").
;;
;; If are using X, you can set the menu foreground and background using
;; a resource file, usually .Xdefaults or .Xresources.  Usually
;; .Xdefaults is used when you start your session using a display
;; manager such as xdm or gdm.  .Xresources is usually used when you
;; start X directly via a shell script such as startx.  If you set
;; Emacs*Background and Emacs*Foreground in such a resource file, the
;; foreground and background of Emacs including the menu will be set.
;; If your .emacs then loads a color theme, the foreground and
;; background are changed -- with the exception of the menu.  There is
;; no way to manipulate the menu foreground and background color from
;; elisp.  You can also set more specific menu resources for Emacs in
;; the resource file.  Here is a sample entry for your resource file:
;;
;;   Emacs*Background:		DarkSlateGray
;;   Emacs*Foreground:		wheat

;; Creating your own color theme:
;;
;; Use M-x customize-face and customize the faces.  Make sure to "Set
;; for Current Session" -- you don't want to save these using custom!
;; When you are done, call M-x color-theme-print to produce the elisp
;; code required to recreate your theme.  Better yet, use M-x
;; color-theme-submit to mail it to the maintainer.  That way it will be
;; added to future versions of color-theme.el.
;;
;; For more information on the elisp format of a color theme, start with
;; the documentation of `color-theme-install' using C-h f
;; color-theme-install.
;;
;; When your color theme is just a variation of an existing color theme,
;; take a look at `color-theme-robin-hood' in order to see an example of
;; how to do it.  Essentially you want to call all the parent color
;; themes before installing your changes.  For all but the first parent
;; color theme, you need to make sure that `color-theme-is-cumulative'
;; is bound to t.  If you don't do that, users that set
;; `color-theme-is-cumulative' to nil will only install your changes
;; without the parent color themes.

;; Making a color theme work for both Emacs and XEmacs:
;;
;; The most important thing is to add missing faces for the other
;; editor.  These are the most important faces to check:
;;
;; In Emacs			  In XEmacs
;; `font-lock-builtin-face'	  `font-lock-reference-face'
;; `font-lock-doc-face'	          `font-lock-doc-string-face'
;; `font-lock-constant-face'	  `font-lock-preprocessor-face'
;; `modeline'			  `modeline-buffer-id'
;; `modeline'			  `modeline-mousable'
;; `modeline'			  `modeline-mousable-minor-mode'
;; `region'			  `primary-selection'
;; `region'			  `zmacs-region'
;; `font-lock-string-face'	  `dired-face-boring'
;; `font-lock-function-name-face' `dired-face-directory'
;; `default'			  `dired-face-executable'
;; `font-lock-warning-face'	  `dired-face-flagged'
;; `font-lock-warning-face'	  `dired-face-marked'
;; `default'			  `dired-face-permissions'
;; `default'			  `dired-face-setuid'
;; `default'			  `dired-face-socket'
;; `font-lock-keyword-face'	  `dired-face-symlink'
;;
;; Further comments:
;;
;; In Emacs 21 `modeline' is just an alias for `mode-line'.  I recommend
;; the use of `modeline' until further notice.
;;
;; The support for :foreground and :background attributes works for
;; Emacs 20 and 21 as well as for XEmacs.  :inverse-video is taken care
;; of while printing color themes.
;;
;; I don't recommend making font sizes part of a color theme.  Most
;; users would be surprised to see their font sizes change when they
;; install a color-theme.  Therefore, remove all :height attributes if
;; the value is an integer.  If the value is a float, this is ok -- the
;; value is relative to the default height.  One notable exceptions is
;; for a color-theme created for visually impaired people.  These *must*
;; use a larger font in order to be usable.
;;
;; The tool-bar should not be part of the frame-parameters, since it
;; should not appear or disappear depending on the color theme.  The
;; apppearance of the toolbar, however, can be changed by the color
;; theme.  For Emacs 21, use the `tool-bar' face.  The easiest way to do
;; this is to give it the default fore- and background colors.  This can
;; be achieved using (tool-bar ((t (nil)))) in the theme.  Usually it
;; makes more sense, however, to provide the same colors as used in the
;; `menu' face, and to specify a :box attribute.  In order to alleviate
;; potential Emacs/XEmacs incompatibilities, `toolbar' will be defined
;; as an alias for `tool-bar' if it does not exist, and vice-versa.
;; This is done eventhough the face `toolbar' seems to have no effect on
;; XEmacs.  If you look at XEmacs lisp/faces.el, however, you will find
;; that it is in fact referenced for XPM stuff.
;;
;; Similarly, the `fringe' face defines what the left and right borders
;; of the frame look like in Emacs 21.  To give them default fore- and
;; background colors, use (fringe ((t (nil)))) in your color theme.
;; Usually it makes more sense to choose a color slightly lighter or
;; darker from the default background.

Re: color-theme.el

[Eli Zaretskii]

> From: Alex Schroeder <alex@emacswiki.org>
> Date: Sun, 25 Aug 2002 15:38:57 +0200
> 
> ~/WWW/home/tuning $ ls -l ~/elisp/color-theme
> total 635
> drwxrwxr-x   2 alex     alex         4096 Aug 10 20:58 CVS
> -rw-rw-r--   1 alex     alex         4195 Apr 30 00:32 color-theme-maker.el
> -rw-rw-r--   1 alex     alex       634752 Aug 10 20:57 color-theme.el
> -rw-rw-r--   1 alex     alex       569761 Aug 25 15:31 color-theme.elc
> -rw-rw-r--   1 alex     alex         3097 Sep  1  2001 make-theme.el

If this package is added to Emacs, please rename color-theme-maker.el
to some name whose first 8 characters are different from "color-th",
to avoid file-name clashes in the 8+3-restricted DOS filesystems
(which Emacs still supports).

TIA

Re: color-theme.el

[Richard Stallman]

    make-theme.el allows you to split the color-theme.el file
    automatically into an "engine" and on file per theme function.  We
    could make only the engine part of Emacs, and let people distribute
    themes by themselves.

I think that would be the right first step, if we decide to use
this rather than cus-themes.el.