IRC client for Emacs

IRC client for Emacs

[Alex Schroeder]

I would like to add ERC -- the Emacs IRC Client -- to Emacs.

Mario Lang and I decided some time ago to take ERC and tinker with it.
Mario is now maintaining it.  It started out as a project by Alexander
L. Belikoff, was then maintained by Sergey Berezin, and finally picked
up by us.  A few weeks ago (before gnu.org problems) I was finally
able to locate Alexander and he agreed to sign papers.  If you agree
that having an IRC client as part of Emacs is a good thing, then I
will track down all the other contributors and ask them to sign
papers.  Before I do that, however, I would like to know wether ERC
will be added if I do all that.  I would be happy to provide more
information on ERC and IRC if required.

Alex.

Re: IRC client for Emacs

[John Wiegley]

>>>>> On Fri Aug  9, Alex writes:

> I would like to add ERC -- the Emacs IRC Client -- to Emacs.

I agree that ERC is a very good IRC client for Emacs.

This brings up a question: Exactly how monolithic is the Emacs
distribution going to become, before we implement a module system?
The "lisp" directory weighs in at over 57M now...

John

Re: IRC client for Emacs

[Noah Friedman]

There are also other irc clients, e.g. zenirc.  I am nominally the
maintainer again though I have been somewhat busy and haven't finished
re-merging all the code forks.

Re: IRC client for Emacs

[Richard Stallman]

      If you agree
    that having an IRC client as part of Emacs is a good thing, then I
    will track down all the other contributors and ask them to sign
    papers.

Why not?  It has everything else.

We would need to see the actual code before deciding to install it,
of course.

Re: IRC client for Emacs

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>       If you agree
>     that having an IRC client as part of Emacs is a good thing, then I
>     will track down all the other contributors and ask them to sign
>     papers.
>
> Why not?  It has everything else.
>
> We would need to see the actual code before deciding to install it,
> of course.

Sure.  I will start organizing papers, then.  Once you see the code, I
am sure a plethora of changes will await us.  Time to worry about that
later, when we have the paperwork out of our way.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: IRC client for Emacs

[Richard Stallman]

Would people like to compare the merits of the various Emacs IRC clients?

Re: IRC client for Emacs

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> Would people like to compare the merits of the various Emacs IRC clients?

Here is a copy of
http://www.emacswiki.org/cgi-bin/wiki.pl?InternetRelayChat.
I would like to see more recommendations on that page.
All I know that the users on #emacs @opn use ERC or a client not based
on Emacs.

Alex.


[Home]InternetRelayChat

SiteMap | RecentChanges | Preferences
-------------------------------------------------------------------------------
There are various IRC channels dedicated to Emacs around. Here is a list of the
known ones:

  * #emacs @ [irc.openprojects.net] (see EmacsChannel)
  * #mygnus @ irc.my.gnus.org

Clients

There are also Emacs based IRC clients:

  * EmacsIRCClient aka ERC.
  * IrChat
  * LieceIrcClient
  * ZenIRC

Emacs IRC Client Recommendations

I use ERC. -- AlexSchroeder

I use ERC (EmacsIRCClient) too:

Some comments about clients I tried:

If you are looking for a client which does it "the Emacs way", ZenIRC and ERC
are definitely for you. ERC has some extra features over ZenIRC like colour
display as well as the possibility to display a separate info buffer for every
channel. Have a look at both and compare them yourself.

Liece (LieceIrcClient) and IrChat both take a somewhat different approach. You
get an input buffer for commands and a separate buffer where the channel/query
content go into. Some people like that. IrChat is kind of freaky because it
supports different cryptographic algorithms as well as DCC implemented through
an external perl script.

For EmacSpeak users, there are speech enabling extension for EmacsIRCClient and
ZenIRC. I have also written erc-speak.el which allows you to listen to channel
content using EmacSpeak. You can grab erc-speak.el from the EmacsIRCClient CVS.

-- MarioLang

me too! I use ERC!! --ShaeErisson

I love ERC. Man, It just rocks -- GirishB
-------------------------------------------------------------------------------
CategoryHelp
-------------------------------------------------------------------------------
SiteMap | RecentChanges | Preferences
Edit text of this page | View other revisions
Last edited May 24, 2002 1:38 (diff)
Search: [                    ]

Re: IRC client for Emacs

[Noah Friedman]

>ERC has some extra features over ZenIRC like colour display as well as the
>possibility to display a separate info buffer for every channel.

Yes, those are the top 2 missing features in zenirc that need to be
addressed.  There are modules that implement these which people have
contributed, but they still have a bunch of corner cases that I need to
debug.

I don't know if ERC has been internationalized, but zenirc has a
a few localization catalogs already.

I'll take a look at ERC in the next few days and see how they differ in
more detail.

Re: IRC client for Emacs

[Steve Youngs]

|--==> "RS" == Richard Stallman <rms@gnu.org> writes:

  RS> Would people like to compare the merits of the various Emacs IRC
  RS> clients?

I'd suggest you guys take a look at Liece... Very slick.

,----[ liece/README ]
|   Development of Liece uses CVS, Concurrent Versions System.
|   Latest developing version is available at CVS.
|   
| (0) logging in to anonymous CVS server.
|   
|     % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login
| 
|     CVS password: [CR] # NULL string
|   
| (1) checkout modules
|   
|     % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root checkout liece
`----


-- 
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
|            XEmacs - It's not just an editor.             |
|                    It's a way of life.                   |
|------------------------------------<youngs@xemacs.org>---|

Re: IRC client for Emacs

[Richard Stallman]

Those recommendations seem to say ERC is better than ZenIRC.
Does anyone prefer ZenIRC, or like some features in ZenIRC
that ERC does not have?  (Maybe the easiest thing is to add
those features to ERC.)

Re: IRC client for Emacs

[Noah Friedman]

>Those recommendations seem to say ERC is better than ZenIRC.
>Does anyone prefer ZenIRC, or like some features in ZenIRC
>that ERC does not have?  (Maybe the easiest thing is to add
>those features to ERC.)

Well, I prefer using zenirc because I'm one of the principal authors, but
that's not an objective answer.

I don't think it's important to bundle another large client with the
standard emacs distribution, but I wouldn't object (I think someone has
already made a zenirc package for XEmacs anyway).  On the other hand I
would not only need to collect assignments from contributors, but there is
some merging work I need to finish before it would be ready to check into
the fsf's repository.  I'm dealing with several branches at the moment,
and I don't have a timetable for completion.

RE: IRC client for Emacs

[Mark Ayers]

Would it be unusual to offer both and allow user choice?

ALA
mail and message

That said user extensibility of ERC is attractive.

Re: IRC client for Emacs

[John Wiegley]

>>>>> On Mon Aug 12, RMS writes:

> Those recommendations seem to say ERC is better than ZenIRC.  Does
> anyone prefer ZenIRC, or like some features in ZenIRC that ERC does
> not have?  (Maybe the easiest thing is to add those features to
> ERC.)

I have been a fairly active user of both at one time, and they each
have strengths and weaknesses.  ERC tends to be a little simpler to
setup and use, but zenirc is much more extensible.  Personally, I
would like to see them merged someday.

John

Re: IRC client for Emacs

[Alex Schroeder]

John Wiegley <johnw@gnu.org> writes:

> I have been a fairly active user of both at one time, and they each
> have strengths and weaknesses.  ERC tends to be a little simpler to
> setup and use, but zenirc is much more extensible.  Personally, I
> would like to see them merged someday.

I realized that this has happened in the past.  It seems that Mario
got inspiration for the localization stuff and event-handling from
ZenIRC, so I just sent out a mail to the ZenIRC dev list to see wether
they would sign papers.

I am not sure wether "drawing inspiration" has legal implications -- I
would hope not! -- but better safe than sorry.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: IRC client for Emacs

[Richard Stallman]

    Would it be unusual to offer both and allow user choice?

I would rather not put two IRC clients in Emacs.  One is enough.

Re: IRC client for Emacs

[Richard Stallman]

    I am not sure wether "drawing inspiration" has legal implications -- I
    would hope not! -- but better safe than sorry.

We don't need legal papers from people who contributed only ideas
and no code.

Re: IRC client for Emacs

[Mario Lang]

Noah Friedman <friedman@splode.com> writes:

>>ERC has some extra features over ZenIRC like colour display as well as the
>>possibility to display a separate info buffer for every channel.
>
> Yes, those are the top 2 missing features in zenirc that need to be
> addressed.  There are modules that implement these which people have
> contributed, but they still have a bunch of corner cases that I need to
> debug.

Well, info buffers work, but are not really popular.  I've written
some bits of speedbar integration, which seem to be the way to go.

> I don't know if ERC has been internationalized, but zenirc has a
> a few localization catalogs already.

We have the code, but no other languages then English right now.

>
> I'll take a look at ERC in the next few days and see how they differ in
> more detail.

Most useful is erc-track imho, and a nice addition is erc-button, which
allows to buttonize based on regexps.

I've also written erc-speak, which integrates with emacspeak for continuus
channel reading.

See http://emacswiki.org/cgi-bin/wiki.pl?EmacsIRCClient for our
documentation center, and the rest is in sourceforge cvs.

-- 
CYa,
  Mario

Re: IRC client for Emacs

[Karl Eichwalder]

Noah Friedman <friedman@splode.com> writes:

> I don't know if ERC has been internationalized, but zenirc has a
> a few localization catalogs already.

Can it serve as an example to internationalized other parts of Emacs,
too?

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: IRC client for Emacs

[Alex Schroeder]

Karl Eichwalder <keichwa@gmx.net> writes:

> Noah Friedman <friedman@splode.com> writes:
>
>> I don't know if ERC has been internationalized, but zenirc has a
>> a few localization catalogs already.
>
> Can it serve as an example to internationalized other parts of Emacs,
> too?

Maybe for applications within Emacs.  In erc.el there is code like
this:

(defun erc-make-message-variable-name (catalog entry)
  (intern (concat "erc-message-"
		  (symbol-name catalog) "-" (symbol-name entry))))

(defun erc-define-catalog-entry (catalog entry format-spec)
  (set (erc-make-message-variable-name catalog entry)
       format-spec))

(defun erc-define-catalog (catalog entries)
  (dolist (entry entries)
    (erc-define-catalog-entry catalog (car entry) (cdr entry))))

(erc-define-catalog
 'english
 '((bad-ping-response . "Unexpected PING response from %n (time %t)")
   (bad-syntax . "Bad syntax")
   (cannot-find-file . "Cannot find file %f")
   (cannot-read-file . "Cannot read file %f")
   (connect . "Connecting to %S:%p... ")

etc.

Alex.

Re: IRC client for Emacs

[Mario Lang]

huug <huug.at.gmane@xs4all.nl> writes:

> On 2002-08-14, Alex Schroeder <alex@emacswiki.org> wrote:
>> (erc-define-catalog
>>  'english '((bad-ping-response . "Unexpected PING response from %n
>>  (time %t)") (bad-syntax . "Bad syntax") (cannot-find-file . "Cannot
>>  find file %f") (cannot-read-file . "Cannot read file %f") (connect
>>  . "Connecting to %S:%p... ")
>
> Doesn't look that robust: the order of %n%t and %S%p thingies is
> language-dependent.

That's exactly the reason why we decided to use format-spec instead
of simply %s%s%s like constructs.

The catalog can be translated, and the order does NOT matter.

So you can either write "%a is %b" or "%b is %a".

-- 
CYa,
  Mario

Re: IRC client for Emacs

[Karl Eichwalder]

Alex Schroeder <alex@emacswiki.org> writes:

Thanks for the info.

> (erc-define-catalog
>  'english
>  '((bad-ping-response . "Unexpected PING response from %n (time %t)")
>    (bad-syntax . "Bad syntax")
>    (cannot-find-file . "Cannot find file %f")
>    (cannot-read-file . "Cannot read file %f")
>    (connect . "Connecting to %S:%p... ")
>
> etc.

I don't like it to see the messages separated from the places where they
are actually used into a catalog.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: IRC client for Emacs

[Richard Stallman]

    Maybe for applications within Emacs.  In erc.el there is code like
    this:

    (defun erc-make-message-variable-name (catalog entry)
      (intern (concat "erc-message-"
		      (symbol-name catalog) "-" (symbol-name entry))))

This seems like a space-inefficient way to store the data, creating a
symbol for each translatable string.  Aside from that, how would you
load a new message catalog?  I suppose you would set each of these
variables.  That means Emacs can only hold one message catalog
for the category at any time.

I think it would be better to use a hash table to record the message
catalog, and to look up the original string in the hash table to
translate it.  This would be more space-efficient, I think.  And it
would be quick and easy to switch between different message catalogs.

The drawback would be that lookup is slower.  But I think this won't
matter much, because these operations are mostly for user output.

A program that needs to use various message translations, and wants to
run fast, could look them up once at the outset and then save the
translations in local variables.  This would combine the advantages
of both methods.

Re: IRC client for Emacs

[Noah Friedman]

>    Maybe for applications within Emacs.  In erc.el there is code like
>    this:
>
>    (defun erc-make-message-variable-name (catalog entry)
>      (intern (concat "erc-message-"
>		      (symbol-name catalog) "-" (symbol-name entry))))
>
>This seems like a space-inefficient way to store the data, creating a
>symbol for each translatable string.  Aside from that, how would you
>load a new message catalog?  I suppose you would set each of these
>variables.  That means Emacs can only hold one message catalog
>for the category at any time.

zenirc already uses separate hashtables for each language, so multiple
languages at once are supported and the current language can be
buffer-local.

It looks to me like the erc API is pretty similar to the zenirc API in
regard to using symbols for the catalog entry lookup.  The reason zenirc
chose this method was because the actual message strings change in cosmetic
ways from time to time and people aren't necessarily good at keeping the
rest of the catalogs up to date.  So if someone changed the (english)
format string in the source code, suddenly none of the other catalogs would
work anymore for that message.  (It goes without saying that these are
still maintained manually; we don't have a message entry scanner.)  Symbols
don't ever need to change, so this was a maintenance choice.  I'm not set
on preserving this style, but at the time the obfuscation factor seemed
minor in constrast to reliability.

(Also, zenirc still uses obarrays, not proper hashtables, so we are already
paying a high symbol use price.  And preserving emacs 18 compatibility is
still a goal, so the authors would probably want to implement obarray-based
catalogs as a fallback method anyway.)

Argument order is also still a potential problem in zenirc and right now
some of the catalogs probably have awkward sentence construction just to
keep the parameter order the same in every language.  I have been
contemplating some kludges to address this, such allowing an optional
argument order list for each message entry in a given language's catalog.
But I seem to recall that the C library's printf library has some feature
for dealing with this already in the format specifier, e.g.

      printf ("%2$s is %1$s", "foo", "bar");
      =| bar is foo

and wondered if this would be worth adding this functionality to emacs's
message function as part of the basic functionality for i18n in elisp
packages.

>The drawback would be that lookup is slower.  But I think this won't
>matter much, because these operations are mostly for user output.
>
>A program that needs to use various message translations, and wants to
>run fast, could look them up once at the outset and then save the
>translations in local variables.  This would combine the advantages
>of both methods.

Given the relative infrequency of messages in irc (on the order of less
than 1/s most of the time, often there are minutes of idle time), this is a
non-problem for the program we're talking about at the moment.  I am more
concerned about preloading the entire contents of the message catalogs into
memory at once, rather than lazy-loading entries as they are used.

Even for an application that might produce a lot of output very quickly,
I'm not sure that the cost of looking up the catalog entry is
significantly higher than parsing the format string and converting
arguments.  Has anyone ever profiled this?

Re: IRC client for Emacs

[Richard Stallman]

    But I seem to recall that the C library's printf library has some feature
    for dealing with this already in the format specifier, e.g.

	  printf ("%2$s is %1$s", "foo", "bar");
	  =| bar is foo

    and wondered if this would be worth adding this functionality to emacs's
    message function as part of the basic functionality for i18n in elisp
    packages.

I think it is a good idea to add some sort of feature for this purpose.

    Given the relative infrequency of messages in irc (on the order of less
    than 1/s most of the time, often there are minutes of idle time), this is a
    non-problem for the program we're talking about at the moment.

Then we agree.  Let's not concern ourselves with the speed issue.

      I am more
    concerned about preloading the entire contents of the message catalogs into
    memory at once, rather than lazy-loading entries as they are used.

That is a good point.  What method do you propose for lazy-loading them?

Re: IRC client for Emacs

[Noah Friedman]

>    I am more concerned about preloading the entire contents of the
>    message catalogs into memory at once, rather than lazy-loading entries
>    as they are used.
>
>That is a good point.  What method do you propose for lazy-loading them?

What do you think about providing persistent hashtables, via gdbm or
berkeley db? 

Re: IRC client for Emacs

[Eli Zaretskii]

> From: Noah Friedman <friedman@splode.com>
> Date: Tue, 20 Aug 2002 14:38:17 -0700 (PDT)
> 
> But I seem to recall that the C library's printf library has some feature
> for dealing with this already in the format specifier, e.g.
> 
>       printf ("%2$s is %1$s", "foo", "bar");
>       =| bar is foo
> 
> and wondered if this would be worth adding this functionality to emacs's
> message function as part of the basic functionality for i18n in elisp
> packages.

IMHO, such a functionality is a must for supporting bidirectional
languages such as Arabic and Hebrew.

Re: IRC client for Emacs

[Karl Eichwalder]

Noah Friedman <friedman@splode.com> writes:

> So if someone changed the (english) format string in the source code,
> suddenly none of the other catalogs would work anymore for that
> message.

The GNU gettext philosophy is: Better some English messages than
outdated translations.  Often you cannot say where a stylistic change
ends and where content correction start the translator must take into
account.

Thanks for explaining the background of the implementation -- looks
promising.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: IRC client for Emacs

[Richard Stallman]

    What do you think about providing persistent hashtables, via gdbm or
    berkeley db? 

It is not completely out of the question, but it sounds awfully
heavyweight.  Sinc ethis does need to run particularly fast,
we ought to be able to do something more simpler, using text
files directly.

Re: IRC client for Emacs

[Noah Friedman]

>    What do you think about providing persistent hashtables, via gdbm or
>    berkeley db? 
>
>It is not completely out of the question, but it sounds awfully
>heavyweight.  Sinc ethis does need to run particularly fast,
>we ought to be able to do something more simpler, using text
>files directly.

The solutions that come to mind involve generating a separate index for
those files and writing the lookup and loading routines in elisp.  This is
ok, but the disadvantages I see to that are:

    * it's another special-purpose API

    * Since the data is plain text, you either have to read the whole file
      into memory to scan for the relevant data, or else generate a
      separate index file.  Index files would need to be regenerated when
      the plain text file changes, so you have to check for this condition
      somewhere.

      The other alternative is to have a separate message per-file, but
      then performance is dependent on the implementation of the
      filesystem.  For example ext2fs has linear directory tables but xfs
      has b-tree indexed tables; so file name resolution on the former,
      especially in large directories, is slower.
  
    * all the routines for lookup and index generation would be in elisp,
      which is slower than adding C calls to gdbm/dbd.

Persistent hashtables might be useful for other things (such as BBDB), so
they seem worth considering for reasons beyond localization.  For
applications which frequently access the same data, they can cache it.
Perhaps that could even be a feature of hashtables which open the diskfile
in read-only mode, but in any case you could just copy values to a
non-persistent hash.

Re: IRC client for Emacs

[Daiki Ueno]

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

>>>>> In <20020821193900.557945.FMU965@piglet.prv.splode.com> 
>>>>>	Noah Friedman <friedman@splode.com> wrote:

> Persistent hashtables might be useful for other things (such as BBDB), so
> they seem worth considering for reasons beyond localization.

Why don't you consider reading *.mo files themselves?  Even now gettext
0.11.5 has a support to Emacs Lisp.  I have used my gettext.el for that
purpose in my IRC client (Liece) for several years.

Here is the example:

;; Before evaluating the following expressions, it is needed to run
;; ./prepare.sh (attached below) to generate prog.mo in the current
;; directory and to type M-x load-file gettext.el (also, attached below).

(setenv "LANG" "fr")
=> "fr"

(bind-text-domain "prog" ".")
=> (("prog" . "/home/ueno/fr/LC_MESSAGES/prog.mo"))

(dgettext "prog" "'Your command, please?', asked the waiter.")
=> "«Votre commande, s'il vous plait», dit le garçon."


[-- Attachment #2: prepare.sh --]
[-- Type: text/plain, Size: 429 bytes --]

cat <<EOF > fr.po
msgid ""
msgstr ""
"Content-Type: text/plain; charset=ISO-8859-1\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

msgid "'Your command, please?', asked the waiter."
msgstr "«Votre commande, s'il vous plait», dit le garçon."

# Reverse the arguments.
#, elisp-format
msgid "%s is replaced by %s."
msgstr "%2$s remplace %1$s."
EOF

mkdir -p fr/LC_MESSAGES
msgfmt -o fr/LC_MESSAGES/prog.mo fr.po

[-- Attachment #3: gettext.el --]
[-- Type: application/octet-stream, Size: 7125 bytes --]

;;; gettext.el --- GNU gettext interface
;; Copyright (C) 1999-2002 Daiki Ueno

;; Author: Daiki Ueno <ueno@unixuser.org>
;; Keywords: i18n

;; This file is not part of any package.

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.

;;; Code:

(defvar gettext-gmo-endian 1234)
(defvar gettext-message-domain-to-catalog-alist nil)
(defvar gettext-default-message-domain "emacs")
(defvar gettext-default-mime-charset 'x-ctext)
(defvar gettext-default-locale "C")

(defconst gettext-msgid-regexp "msgid\\s-*\"")
(defconst gettext-msgstr-regexp "msgstr\\s-*\"")

(defvar gettext-mime-charset-coding-system-alist
  (let ((coding-systems (coding-system-list 'base-only))
	mime-charset alist)
    (while coding-systems
      (if (and (setq mime-charset
		     (coding-system-get (car coding-systems) 'mime-charset))
	       (not (assq mime-charset alist)))
	  (setq alist (cons (cons mime-charset (car coding-systems)) alist)))
      (setq coding-systems (cdr coding-systems)))
    alist))

(defmacro gettext-hex-char-to-integer (character)
  `(if (and (>= ,character ?0) (<= ,character ?9))
       (- ,character ?0)
     (let ((ch (logior ,character 32)))
       (if (and (>= ch ?a) (<= ch ?f))
	   (- ch (- ?a 10))
	 (error "Invalid hex digit `%c'" ch)))))

(defun gettext-hex-string-to-integer (hex-string)
  (let ((hex-num 0))
    (while (not (equal hex-string ""))
      (setq hex-num (+ (* hex-num 16)
		       (gettext-hex-char-to-integer
			(string-to-char hex-string)))
	    hex-string (substring hex-string 1)))
    hex-num))

(defun gettext-gmo-read-32bit-word ()
  (let ((word (string-to-list (buffer-substring (point) (+ (point) 4)))))
    (forward-char 4)
    (apply #'format "%02x%02x%02x%02x"
	   (mapcar (lambda (ch) (logand 255 ch))
		   (if (= gettext-gmo-endian 1234)
		       (nreverse word)
		     word)))))
    
(defmacro gettext-gmo-header-revision (header)
  `(aref header 0))

(defmacro gettext-gmo-header-nn (header)
  `(aref header 1))

(defmacro gettext-gmo-header-oo (header)
  `(aref header 2))

(defmacro gettext-gmo-header-tt (header)
  `(aref header 3))

(defmacro gettext-gmo-header-ss (header)
  `(aref header 4))

(defmacro gettext-gmo-header-hh (header)
  `(aref header 5))

(defmacro gettext-gmo-read-header ()
  (cons 'vector
	(make-list 6 '(gettext-hex-string-to-integer
		       (gettext-gmo-read-32bit-word)))))

(defun gettext-gmo-collect-strings (nn)
  (let (strings pos len off)
    (dotimes (i nn)
      (setq len (gettext-hex-string-to-integer
		 (gettext-gmo-read-32bit-word))
	    off (gettext-hex-string-to-integer
		 (gettext-gmo-read-32bit-word))
	    pos (point))
      (goto-char (1+ off))
      (push (buffer-substring (point) (+ (point) len))
	    strings)
      (goto-char pos))
    (nreverse strings)))

(defun gettext-read-mime-charset (&optional header)
  "Return the MIME charset of PO file."
  (with-temp-buffer
    (insert header)
    (goto-char (point-min))
    (let ((case-fold-search t))
      (if (re-search-forward
	   "^\"Content-Type: *text/plain;[ \t]*charset=\\([^\\]+\\)"
	   nil t)
	  (intern (downcase
		   (buffer-substring (match-beginning 1) (match-end 1))))))))

(defun gettext-mapcar* (function &rest args)
  "Apply FUNCTION to successive cars of all ARGS.
Return the list of results."
  (let (result)
    (while (not (memq nil args))
      (push (apply function (mapcar #'car args)) result)
      (setq args (mapcar #'cdr args)))
    (nreverse result)))

(defun gettext-load-message-catalogue (file)
  (with-temp-buffer
    (let ((coding-system-for-read 'binary)
	  header strings charset coding-system gettext-obarray oott)
      (insert-file-contents file)
      (set-buffer-multibyte nil)
      (goto-char (point-min))
      (when (looking-at "\x95\x04\x12\xde")
	(setq gettext-gmo-endian 4321))
      (forward-char 4)
      (setq header (gettext-gmo-read-header)
	    strings
	    (gettext-mapcar* #'cons
			     (progn
			       (goto-char (1+ (gettext-gmo-header-oo header)))
			       (gettext-gmo-collect-strings
				(gettext-gmo-header-nn header)))
			     (progn
			       (goto-char (1+ (gettext-gmo-header-tt header)))
			       (gettext-gmo-collect-strings
				(gettext-gmo-header-nn header))))
	    charset (or (gettext-read-mime-charset
			 (cdr (assoc "" strings)))
			gettext-default-mime-charset)
	    gettext-obarray (make-vector
			     (* 2 (gettext-gmo-header-nn header))
			     0))
      (unless (setq coding-system
		    (cdr (assq charset
			       gettext-mime-charset-coding-system-alist)))
	(error "Unknown MIME-charset is used in `%s'" file))
      (while strings
	(set (intern (car (car strings)) gettext-obarray)
	     (decode-coding-string (cdr (car strings)) coding-system))
	(setq strings (cdr strings)))
      gettext-obarray)))

;;;###autoload
(defun dgettext (domain string)
  "Look up STRING in the default message domain and return its translation."
  (let ((oott (assoc domain gettext-message-domain-to-catalog-alist)))
    (when (stringp (cdr oott))
      (setcdr oott (gettext-load-message-catalogue
		    (cdr oott))))
    (or (symbol-value
	 (intern-soft string (or (cdr oott) (make-vector 1 0))))
	string)))

;;;###autoload
(defun gettext (string)
  "Look up STRING in the default message domain and return its translation."
  (dgettext gettext-default-message-domain string))

;;;###autoload
(defun bind-text-domain (domain pathname)
  "Associate a pathname with a message domain."
  (let* ((lang (or (getenv "LC_ALL") (getenv "LC_MESSAGES") (getenv "LANG")
		   gettext-default-locale))
	 (language (progn
		     (string-match "\\([^_.]+\\)\\(_[^.]+\\)?\\(\\.[^@]+\\)?"
				   lang)
		     (match-string 1 lang)))
	 (territory (match-string 2 lang))
	 (code-set (match-string 3 lang))
	 (lang-path (if lang
			(delq nil (list (if (and territory code-set)
					    (concat language territory
						    code-set))
					(if territory
					    (concat language territory))
					(if code-set
					    (concat language code-set))
					language))))
	 (file (concat domain ".mo"))
	 catalog)
    (while (and (setq lang (car lang-path))
		(setq catalog
		      (expand-file-name file
					(concat pathname
						"/" lang "/LC_MESSAGES")))
		(not (file-exists-p catalog)))
      (setq lang-path (cdr lang-path)))
    (when (file-exists-p catalog)
      ;;(file-exists-p (setq catalog (expand-file-name file pathname)))
      (push (cons domain catalog) gettext-message-domain-to-catalog-alist))))

(provide 'gettext)

;;; gettext.el ends here

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

-- 
Daiki Ueno

Re: IRC client for Emacs

[Richard Stallman]

	* it's another special-purpose API

We will certainly make a special-purpose Lisp interface
for this important job.

	* Since the data is plain text, you either have to read the whole file
	  into memory to scan for the relevant data, or else generate a
	  separate index file.

Perhaps we want to have all the data in core--both the "original"
strings, and whichever set or sets of translations are actually in
use.  The method that was presented, with a symbol per message,
effectively does this, but does it in a rather inefficient way.

The program that Daiki <ueno@unixuser.org> sent also seems to create
a symbol for each string.  I am not certain, though, because
it has very few comments.

Daiki, could you see if it runs fast enough if you store the
message catalog as a simple alist?

It might even be fast enough to store the message catalog as text in a
buffer--and that would use up much less space.

Re: IRC client for Emacs

[Daiki Ueno]

>>>>> In <200208240233.g7O2XW011692@wijiji.santafe.edu> 
>>>>>	Richard Stallman <rms@gnu.org> wrote:

> The program that Daiki <ueno@unixuser.org> sent also seems to create
> a symbol for each string.  I am not certain, though, because
> it has very few comments.

Yes, it doesn't bring striking performance in comparison with obarrays.
Sorry for any confusion.

> Daiki, could you see if it runs fast enough if you store the
> message catalog as a simple alist?

Yes, I'll try and let you know how it goes.

> It might even be fast enough to store the message catalog as text in a
> buffer--and that would use up much less space.

An MO file has its own internal hash table which is used to relate an
original string to the file position.  However, the hashing algorithm is
dependent on gettext internals (See "(gettext)MO Files" for details).
That is why I gave up the idea of searching in a buffer when I wrote
gettext.el.

Anyway, I really wish Emacs could have the feature to read *.mo files,
since it appears to be a standard way for localization of GNU software.

Regards,
-- 
Daiki Ueno

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: IRC client for Emacs

[Richard Stallman]

    An MO file has its own internal hash table which is used to relate an
    original string to the file position.  However, the hashing algorithm is
    dependent on gettext internals (See "(gettext)MO Files" for details).

This suggests another approach: keep the MO file as text in a buffer,
and write Lisp code to do the lookup using the MO file hash table.
The function to do a lookup could recreate the buffer (reading the
file into it) if the buffer does not exist.  This way, we could delete
these buffers occasionally (such as, when they have not been
used for 10 minutes), and they would be recreated when needed.
The buffer would serve as a cache for the file.

What do you think?


One interesting consequence of this approach is that we could delete
that buffer

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

[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: IRC client for Emacs

[Noah Friedman]

>    An MO file has its own internal hash table which is used to relate an
>    original string to the file position.  However, the hashing algorithm is
>    dependent on gettext internals (See "(gettext)MO Files" for details).
>
>This suggests another approach: keep the MO file as text in a buffer,
>and write Lisp code to do the lookup using the MO file hash table.
>The function to do a lookup could recreate the buffer (reading the
>file into it) if the buffer does not exist.  This way, we could delete
>these buffers occasionally (such as, when they have not been
>used for 10 minutes), and they would be recreated when needed.
>The buffer would serve as a cache for the file.
>
>What do you think?

I think this might be ok, but I'm uncertain whether implementing the hash
function in elisp is worth the computation time vs. just using C
hashtables, or whether it's better to memoize results parsed out of the MO
file into a hashtable for all future references.  I'd like to try it and
see.  Are there any existing tools for extracting strings from elisp source
to help build MO files?  I'm not very familiar with the format.

Regardless, I do like the idea of using gettext's API; the implementation
details of gettext.el are a secondary issue.

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: IRC client for Emacs

[Richard Stallman]

    I think this might be ok, but I'm uncertain whether implementing the hash
    function in elisp is worth the computation time vs. just using C
    hashtables, or whether it's better to memoize results parsed out of the MO
    file into a hashtable for all future references.

Using C hashtables would mean using a lot more space, I would expect.
Saving that space is the reason for reading directly out of the buffer
rather than making an Emacs hash table.  However, this depends on how
much excess space there is in an MO file.  You could do the computation
and see which one saves how much space.

I think we need the code to parse the MO file in any case, regardless
of whether you do this to look up each string or to parse the file
just once to put the data in an Emacs hash table.  So I don't see how
using the Emacs table avoids any code.

Using a hash table to memoize would not add too much space,
and might be worth doing if it really speeds things up.
However, I suspect things will be fast enough without it
so it isn't worth doing.

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]

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

[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

[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

[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

[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]

    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]

    "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

[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

[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.

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]

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

[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: 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.