From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs 24 semantic C++ completion problem Date: Wed, 04 Jan 2012 23:43:31 -0500 Message-ID: References: <4EFCE3A1.7030302@siege-engine.com> <87hb0i9zxt.fsf@engster.org> <878vlu9ss2.fsf@engster.org> <87r4zm80kf.fsf@engster.org> <87mxa9963m.fsf@engster.org> <87fwg18zub.fsf@engster.org> <87r4zleygr.fsf@engster.org> <87aa65hpcb.fsf@engster.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1325738621 18372 80.91.229.12 (5 Jan 2012 04:43:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 04:43:41 +0000 (UTC) Cc: "Eric M. Ludlam" , emacs-devel@gnu.org To: Vyacheslav Gonakhchyan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 05:43:37 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RifAv-0005WW-IT for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 05:43:37 +0100 Original-Received: from localhost ([::1]:50846 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RifAu-0001sS-Si for ged-emacs-devel@m.gmane.org; Wed, 04 Jan 2012 23:43:36 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:45150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RifAs-0001sC-7D for emacs-devel@gnu.org; Wed, 04 Jan 2012 23:43:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RifAr-0006Us-AQ for emacs-devel@gnu.org; Wed, 04 Jan 2012 23:43:34 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RifAr-0006Uo-81 for emacs-devel@gnu.org; Wed, 04 Jan 2012 23:43:33 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIIpBU9MCoO8/2dsb2JhbABDrHGBBoFyAQEEAVYjEAsOJhIUGA0kLodftSWMEQSIOZpMhFI X-IronPort-AV: E=Sophos;i="4.71,460,1320642000"; d="scan'208";a="155351045" Original-Received: from 76-10-131-188.dsl.teksavvy.com (HELO pastel.home) ([76.10.131.188]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Jan 2012 23:43:32 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9A2E058C01; Wed, 4 Jan 2012 23:43:31 -0500 (EST) In-Reply-To: <87aa65hpcb.fsf@engster.org> (David Engster's message of "Mon, 02 Jan 2012 20:33:08 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147312 Archived-At: >>> We used to have the `semantic-lex-c-preprocessor-symbol-file' defcustom >>> autoloaded, but that would never get past the Monnier-filter. I'm not >> Could someone explain to me what is the problem? > The general problem is this: Say you have a custom variable V, belonging > to package P, which is initialized with some list of filenames. When you > require P, it will use V's value to set up some things, but will only do > so once. How should the user add further filenames to V in his .emacs? > If he first requires P, then any changes to V will be moot. Hence he has > to look up the default value of V and then use setq-default, with the > additional files added. The simplest solution (or rather: cop-out) is to > autoload the defcustom, but I remember you saying that this is a no-no. Real "no-no"s are hard to come by, and indeed autoloaded defcustoms are easy to find in Emacs. The best solution depends on how V is expected to change in time and on what kind of changes the user is expected to apply to the value. Note that if the var is modified via Custom, then Custom will store the chosen value and further changes to V's default will be ignored, so if that's considered bad, maybe it shouldn't be a defcustom at all. If elements are almost never removed from that var, maybe splitting it into two (a defcustom that defaults to nil and defvar which holds the default set) will make things easier. Stefan