From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Noah Friedman Newsgroups: gmane.emacs.devel Subject: Re: IRC client for Emacs Date: Tue, 20 Aug 2002 14:38:17 -0700 (PDT) Sender: emacs-devel-admin@gnu.org Message-ID: <20020820143817.816033.FMU965@piglet.prv.splode.com> References: <873ctot40n.fsf@emacswiki.org> <20020809223753.955308.FMU31823@piglet.prv.splode.com> <200208110355.g7B3tOo06247@wijiji.santafe.edu> <877kixtg8w.fsf@emacswiki.org> <20020811160610.424772.FMU9022@piglet.prv.splode.com> <87fzxhs1ia.fsf@emacswiki.org> <200208151954.g7FJsut07968@wijiji.santafe.edu> Reply-To: Noah Friedman NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1029879564 26093 127.0.0.1 (20 Aug 2002 21:39:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 20 Aug 2002 21:39:24 +0000 (UTC) Cc: alex@emacswiki.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17hGih-0006mk-00 for ; Tue, 20 Aug 2002 23:39:23 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17hHAm-0006zh-00 for ; Wed, 21 Aug 2002 00:08:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hGjn-0007Lw-00; Tue, 20 Aug 2002 17:40:31 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hGi7-0007KD-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 17:38:47 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hGi4-0007Jw-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 17:38:46 -0400 Original-Received: from scones-of-silence.splode.com ([216.27.180.143] helo=piglet.prv.splode.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hGi4-0007Jq-00; Tue, 20 Aug 2002 17:38:44 -0400 Original-Received: (from friedman@localhost) by piglet.prv.splode.com (8.9.3/8.9.3) id OAA10708; Tue, 20 Aug 2002 14:38:17 -0700 Original-To: rms@gnu.org In-Reply-To: <200208151954.g7FJsut07968@wijiji.santafe.edu> (rms@gnu.org Thursday, 15 Aug 2002 13:54:56 -0600) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6689 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6689 > 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?