From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Question about defcustom and :set-after Date: Mon, 30 Apr 2018 17:00:28 -0700 Message-ID: <87vac8z1lv.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1525132925 7316 195.159.176.226 (1 May 2018 00:02:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 May 2018 00:02:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 01 02:02:00 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fDIk4-0001jW-Ih for ged-emacs-devel@m.gmane.org; Tue, 01 May 2018 02:02:00 +0200 Original-Received: from localhost ([::1]:34255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDImB-0000u6-Fo for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2018 20:04:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDIlT-0000u1-Nm for emacs-devel@gnu.org; Mon, 30 Apr 2018 20:03:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDIlP-0007Jg-Rb for emacs-devel@gnu.org; Mon, 30 Apr 2018 20:03:27 -0400 Original-Received: from [195.159.176.226] (port=36591 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fDIlP-0007JH-LH for emacs-devel@gnu.org; Mon, 30 Apr 2018 20:03:23 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fDIjE-0000qV-4p for emacs-devel@gnu.org; Tue, 01 May 2018 02:01:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:TDOwYLsWaQmylMspdaIXW2sVWZY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225000 Archived-At: I've been trying to do some fairly deep refactoring to Gnus, and have been frustrated by the fact that it's very difficult to set up a clean test environment for Gnus that also has some data in it to work with. So I started writing support for a Gnus mock environment: you call `gnus-mock' and it starts up a Gnus session completely independent of your own Gnus customizations, that has some dummy data in it that gets flushed and restored each time you restart the mock session. That involves saving all relevant customizations (and some defvars) and putting them aside, then setting all customization options (and some defvars) back to their default values, and starting Gnus. It isn't working quite right for me, I think because some customization options depend on other customization options, and if they're set in the wrong order, things don't get overwritten cleanly. In particular I'm looking at options like this one: (defcustom gnus-directory (or (getenv "SAVEDIR") (nnheader-concat gnus-home-directory "News/")) "Directory variable from which all other Gnus file variables are derived. Note that Gnus is mostly loaded when the `.gnus.el' file is read. This means that other directory variables that are initialized from this variable won't be set properly if you set this variable in `.gnus.el'. Set this variable in `.emacs' instead." :group 'gnus-files :type 'directory) `gnus-home-directory' is also an option. Shouldn't this option declare a :set-after dependency on `gnus-home-directory'? There have also been bug reports over the years about weirdness in this area, and I wonder if it isn't all related. Is this what :set-after is for, and would it make sense to add that property to all Gnus options that depend on other options? Eric