From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/63009 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: New completion mode Date: Mon, 24 Apr 2006 17:55:51 +0900 Organization: Emacsen advocacy group Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145869301 593 80.91.229.2 (24 Apr 2006 09:01:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2006 09:01:41 +0000 (UTC) Original-X-From: ding-owner+m11536@lists.math.uh.edu Mon Apr 24 11:01:40 2006 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FXwws-00086q-3o for ding-account@gmane.org; Mon, 24 Apr 2006 11:01:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu ident=lists) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1FXwwi-0003RP-00; Mon, 24 Apr 2006 04:01:28 -0500 Original-Received: from nas01.math.uh.edu ([129.7.128.39]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1FXwrY-0003RK-00 for ding@lists.math.uh.edu; Mon, 24 Apr 2006 03:56:08 -0500 Original-Received: from quimby.gnus.org ([80.91.224.244]) by nas01.math.uh.edu with esmtp (Exim 4.52) id 1FXwrV-0006Zg-02 for ding@lists.math.uh.edu; Mon, 24 Apr 2006 03:56:08 -0500 Original-Received: from washington.hostforweb.net ([66.225.201.13]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1FXwrP-0000a9-00 for ; Mon, 24 Apr 2006 10:55:59 +0200 Original-Received: from [205.234.185.198] (port=45354 helo=mail.jpl.org) by washington.hostforweb.net with esmtpa (Exim 4.52) id 1FXwsp-0005pH-Ss for ding@gnus.org; Mon, 24 Apr 2006 03:57:28 -0500 Original-To: ding@gnus.org X-Hashcash: 1:20:060424:ding@gnus.org::7Dvk5lgu9O4DiQBH:00001jxY X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110005 (No Gnus v0.5) Emacs/23.0.0 (gnu/linux) Cancel-Lock: sha1:ri1ZF/R4cAU+orcW7AbvaVWoctw= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) Precedence: bulk Original-Sender: ding-owner@lists.math.uh.edu Xref: news.gmane.org gmane.emacs.gnus.general:63009 Archived-At: >>>>> In Lars wrote: > Katsumi Yamaoka writes: >> The regexp used in `message-put-addresses-in-ecomplete' causes >> an infloop in XEmacs. > Ok; done. Thanks. However, the present ecomplete code seems to be written only for Emacs. In XEmacs 21.4, I tried making aliases of some missing functions, e.g., line-beginning-position, read-event, etc., but the goal seems to be far beyond such workarounds. (I wish I had time to grapple with it, though.) >> The completions list appears only when a user invokes the >> `self-insert-command' command. Especially in Japan, people use >> various tools in order to write Japanese text. Some tools >> replace `self-insert-command' with the other command, e.g., >> `egg-self-insert-char', in many keys, and it is used even when >> writing ASCII text. So, we need to make changes in message.el >> like the following: >> >> (defcustom message-self-insert-commands '(self-insert-command) > Yup. I wonder whether there's a simpler solution to make this work > automatically. The point of the check for `self-insert-command' was > just to avoid having the code trigger on totally automatic header > setup stuff. (It would flash "No ecomplete matches" while generating > the header.) > But I don't see any obvious way to fix this, so I've installed your > change. So far I don't have an idea either, but I think it should be improved more so that it might ignore key events in some conditions[1]. I normally use two or more alphabet keys in a certain mode even to enter a single Japanese letter when I write recipient's full name in the To header, for example. In such a case, I don't want ecomplete to work, though it isn't so annoying at present. [1] It is not only the case where the FOO-minor-mode variable indicates the status but also the case where we have to use some function or other like `message-tamago-not-in-use-p' to detect the condition. We are using indeed various tools to enter Japanese text. So, things we can do might be a few after all. >> Therefore, I make a proposal to add a variable like >> `ecomplete-database-file-coding-system'. I think the best >> choice for the default value is `iso-2022-7bit' which all >> Emacsen (with Mule) support. > Ok; I'll make this change. Excellent. >> Putting the coding cookie to the rc file would also be good. It >> enables people to manually edit the rc file safely and informs >> non-Mule XEmacs whether the contents can be used and modified. > What should the cookie look like? It will be a line which looks like the following put at the beginning of a file: ;;; .ecompleterc -*- mode: emacs-lisp; coding: iso-2022-7bit -*- ;; This file is generated automatically by ecomplete.el. However, it seems now to be unnecessary if `iso-2022-7bit' is used. Because both Emacs and XEmacs-Mule are successful in detecting the coding system automatically. >> Mail-abbrevs is still useful. So, I use >> >> (add-hook 'message-setup-hook (if (featurep 'xemacs) >> 'mail-aliases-setup >> 'mail-abbrevs-setup)) >> >> even if I set `message-mail-alias-type' to `ecomplete'. How >> about making this option a list? > Will do. I'm going to confirm for a while whether it is really useful to use mail-abbrevs together with ecomplete, since it might be worrying unduly (and the name `message-mail-alias-type' is not suitable to a list ;-). Regards,