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

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