Gnus development mailing list
 help / color / mirror / Atom feed
From: Didier Verna <didier@lrde.epita.fr>
Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
Subject: RFC: solutions for the custom / gnus-xmas-redefine problem
Date: 02 Jan 2001 15:21:28 +0100	[thread overview]
Message-ID: <muxofxq9grb.fsf@uzeb.lrde.epita.fr> (raw)


        This is something I have raised a very long time ago. Let me just
remind everybody of the problem: when XEmacs is used, the function
`gnus-xmas-redefine' is called, which performs several operations like calling
`add-hook' on many variables.

        The problem is that this function might be called before some gnus
libs are loaded, hence some of these variables are not defcustom'ed. In that
case, the user customizations for such variables are lost. Gnus must hence
ensure that all variables affected by `gnus-xmas-redefine' are properly
defcustomed beforehand.

        What we can do about that is:

1/ Brute force: doing a 'require in `gnus-xmas-redefine' for all libs
defcustom'ing affected variables. This is the simplest solution, but you might
end up with loaded libraries that you're not going to use anyway.

2/ Brute Cleverness: for each concerned gnus lib, create a file
`<lib>-xmas.el' containing the required variables definitions (removed from
the lib itself). Then, both the gnus <lib> and the function
`gnus-xmas-redefine' should do:

| (unless (featurep '<lib>-xmas)
|   (require '<lib>-xmas))

        This is a cleaner solution, but it might not be worth it. Before I
commit anything, I'd like to know if someone has a strong opinion on this.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /        EPITA / LRDE         mailto:didier@lrde.epita.fr
/_/ / /_/ / /__ /      14-16 rue Voltaire        Tel. +33 (1) 53 14 59 47
                   94276 Kremlin-Bicêtre cedex   Fax. +33 (1) 44 08 01 99



                 reply	other threads:[~2001-01-02 14:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=muxofxq9grb.fsf@uzeb.lrde.epita.fr \
    --to=didier@lrde.epita.fr \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).