From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/46566 Path: main.gmane.org!not-for-mail From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.gnus.general Subject: Re: Incorporate message-utils.el? Date: Mon, 16 Sep 2002 21:32:56 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032228146 24724 127.0.0.1 (17 Sep 2002 02:02:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 17 Sep 2002 02:02:26 +0000 (UTC) Return-path: Original-Received: from karazm.math.uh.edu ([129.7.128.1]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17r7h2-0006QW-00 for ; Tue, 17 Sep 2002 04:02:24 +0200 Original-Received: from sina.hpc.uh.edu (lists@sina.hpc.uh.edu [129.7.128.10]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id OAA01325; Mon, 16 Sep 2002 14:33:52 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 16 Sep 2002 14:34:30 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id OAA23291 for ; Mon, 16 Sep 2002 14:34:17 -0500 (CDT) Original-Received: (qmail 21028 invoked by alias); 16 Sep 2002 19:33:29 -0000 Original-Received: (qmail 21023 invoked from network); 16 Sep 2002 19:33:29 -0000 Original-Received: from waldorf.cs.uni-dortmund.de (129.217.4.42) by gnus.org with SMTP; 16 Sep 2002 19:33:29 -0000 Original-Received: from lothlorien.cs.uni-dortmund.de (lothlorien [129.217.19.67]) by waldorf.cs.uni-dortmund.de with ESMTP id g8GJX1805783 for ; Mon, 16 Sep 2002 21:33:01 +0200 (MES) Original-Received: from lucy.cs.uni-dortmund.de (lucy [129.217.19.80]) by lothlorien.cs.uni-dortmund.de id VAA07193; Mon, 16 Sep 2002 21:32:56 +0200 (MET DST) Original-Received: by lucy.cs.uni-dortmund.de (Postfix, from userid 6104) id 469C63AFEA; Mon, 16 Sep 2002 21:32:56 +0200 (CEST) Original-To: ding@gnus.org Mail-Followup-To: ding@gnus.org In-Reply-To: (Reiner Steib's message of "Mon, 16 Sep 2002 20:01:47 +0200") Original-Lines: 58 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:46566 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:46566 Reiner Steib <4uce.02.r.steib@gmx.net> writes: > Sorry Kai, I haven't received your message in time before I started to > change `message.el' (I had no net connection during the weekend), but > I think we can always add your suggestion later. Up to now, I'm > scrupling, because of the following (but I guess you will convince me > finally ;-) ): It's the other way round, I guess. Read on. > - Currently, I have the following code: > > (defun message-reply [...] > (when gnus-list-identifiers > (setq subject (message-strip-list-identifiers subject))) > (setq subject (concat "Re: " (message-strip-subject-re subject))) > (when message-subject-trailing-was-query > (setq subject (message-strip-subject-trailing-was subject))) > > Should `message-strip-list-identifiers' be in > `message-make-reply-subject-functions' too? Then m-s-l-i has to > check for `gnus-list-identifiers' and we call m-s-l-i even if g-l-i > is nil. For `message-strip-subject-trailing-was' it's similar: > m-s-s-t-w does nothing when m-s-t-w-q is nil. This code looks good. It convinced me: this seems to be the right way to do it. Also, it appears to blend well with the gnus-treat-* variables which provide a similar interface for article treatment (though I don't know whether the implementation is similar). > - Assume we add new functions later and the user has changed the > default. If he used add-to-list it should be okay. What about > customize? Does it respect the (changed) default or does it apply > the (old) saved value? (Sorry, I don't use customize, so I don't > know.) This is the same for all list variables in Emacs, so it's not an argument, I think. Eventually, all these cases should be resolved in the same way. The current proposals from the emacs-devel list are: (a) Create two variables, one which contains the system-provided stuff and a variable for the user which is always empty by default. (b) Some nifty diff-list feature by Alex Schroeder (I think) which augments Customize. Then, Customize can remember items-to-add to, and items-to-remove from, the standard variable value. > Okay, what I have done so far is the following All of it looks good. It's useless to argue about little details ahead of time; they can still be changed if the users scream of agony... Good job! kai -- ~/.signature is: umop 3p!sdn (Frank Nobis)