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: Risky local variable mechanism Date: Wed, 08 Feb 2006 01:08:17 -0500 Message-ID: <87zml2e6eb.fsf-monnier+emacs@gnu.org> References: <87mzhbly89.fsf-monnier+emacs@gnu.org> <87r76fkth6.fsf@stupidchicken.com> <200602080149.k181nhQ21836@raven.dms.auburn.edu> <87mzh2ft7f.fsf-monnier+emacs@gnu.org> <87r76eihbg.fsf@stupidchicken.com> <200602080548.k185m9424791@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1139378945 29046 80.91.229.2 (8 Feb 2006 06:09:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2006 06:09:05 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org, rms@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 08 07:09:01 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F6iVb-00089f-Ia for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 07:08:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6iVa-0003Dx-KH for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 01:08:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F6iVG-0003CT-84 for emacs-devel@gnu.org; Wed, 08 Feb 2006 01:08:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F6iVD-0003BF-LD for emacs-devel@gnu.org; Wed, 08 Feb 2006 01:08:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6iVC-0003B1-W2 for emacs-devel@gnu.org; Wed, 08 Feb 2006 01:08:31 -0500 Original-Received: from [209.226.175.188] (helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F6iYP-0001XV-AR; Wed, 08 Feb 2006 01:11:49 -0500 Original-Received: from alfajor ([67.71.117.239]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060208060826.VUTR25777.tomts25-srv.bellnexxia.net@alfajor>; Wed, 8 Feb 2006 01:08:26 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id DE5ECD7568; Wed, 8 Feb 2006 01:08:17 -0500 (EST) Original-To: Luc Teirlinck In-Reply-To: <200602080548.k185m9424791@raven.dms.auburn.edu> (Luc Teirlinck's message of "Tue, 7 Feb 2006 23:48:09 -0600 (CST)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50194 Archived-At: > (put 'myvar 'safe-local-variable t) in his .emacs. There is, in my > opinion, no need to make this any more convenient than that, neither > the way you propose it nor the way Stefan proposes it. The convenience I'm looking at is at least as much to be able to easily say "yes, accept, and don't bother me about it again", as to be able to say "no, don't touch that, and don't ask me ever again". > There is no need to provide list variables defined with defcustom that > trick the user into setting these list variables effectively with > setq-default, which is definitely not what they should be doing. The automatic/interactive part of what I propose would be things that are only set by the user, so custom could be OK for them. > I believe that it is very bad to ask each time _two_ questions to the > user, first "do you want to set this variable to this value now" and > then "is it safe to set this variable to any value whatsoever any time > in the future?". > Constantly repeating that second question each time > the user visits the file, even though he may already have answered > 1001 times no to it before, is effectively not only encouraging, but > even pressuring, the reluctant user to finally say yes. Agreed. My suggestion tries to address both of those points. Stefan