From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-27741-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 8044 invoked by alias); 21 Feb 2010 21:17:45 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 27741
Received: (qmail 5320 invoked from network); 21 Feb 2010 21:17:44 -0000
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
	version=3.2.5
Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-id: <100221131740.ZM24810@torch.brasslantern.com>
Date: Sun, 21 Feb 2010 13:17:40 -0800
In-reply-to: <87d3zy8ib8.fsf@ft.bewatermyfriend.org>
Comments: In reply to Frank Terbeck <ft@bewatermyfriend.org>
 "Re: PATCH: vcs_info: Set NO_warn_create_global option" (Feb 21,  9:06pm)
References: <1266764004-15068-1-git-send-email-ft@bewatermyfriend.org>
	<100221092514.ZM24056@torch.brasslantern.com>
	<87d3zy8ib8.fsf@ft.bewatermyfriend.org>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: PATCH: vcs_info: Set NO_warn_create_global option
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii

On Feb 21,  9:06pm, Frank Terbeck wrote:
}
} > d) Suppress warn_create_global for the parameters "reply" and "REPLY"
} >    at all times.  In fact it probably ought to be suppressed for STTY
} >    and a few others in the "Parameters Used By The Shell" section of
} >    the manual.
} 
} You're probably right that this should always apply to `reply', `REPLY'
} and the like. I don't know how to do that, though. Would you always have
} such parameters be available globally, even after an `unset'?

No, leaving them available would violates some of the other rules of
"non-special" parameters.
 
} Any ideas where to apply the leverage?

In Src/params.c, assignsparam() and assignaparam(), I suppose, by a
check of v->pm->node.nam against a list (which doesn't exist yet) of
parameters that don't require warnings.  I further suppose that list
could itself be controlled by a parameter, but that'd have to be
handled carefully to avoid fetching a value while setting it.

I see PWS has already applied your (a) patch from 27731, so perhaps
this discussion is moot ...