From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Risky local variable mechanism Date: Tue, 7 Feb 2006 23:48:09 -0600 (CST) Message-ID: <200602080548.k185m9424791@raven.dms.auburn.edu> 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> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1139377958 26919 80.91.229.2 (8 Feb 2006 05:52:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2006 05:52:38 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 08 06:52:33 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 1F6iFg-0005yl-LB for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 06:52:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6iFg-0006AC-5q for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2006 00:52:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F6iFU-00069Q-Oi for emacs-devel@gnu.org; Wed, 08 Feb 2006 00:52:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F6iFT-00067C-1R for emacs-devel@gnu.org; Wed, 08 Feb 2006 00:52:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6iFM-00066j-QC for emacs-devel@gnu.org; Wed, 08 Feb 2006 00:52:10 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F6iIY-0000T8-Qs; Wed, 08 Feb 2006 00:55:26 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id k185pwId017501; Tue, 7 Feb 2006 23:51:58 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k185m9424791; Tue, 7 Feb 2006 23:48:09 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: cyd@stupidchicken.com In-reply-to: <87r76eihbg.fsf@stupidchicken.com> (message from Chong Yidong on Tue, 07 Feb 2006 23:51:31 -0500) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Tue, 07 Feb 2006 23:51:58 -0600 (CST) 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:50192 Archived-At: Chong Yidong wrote: I don't see how this would help. As long as it is possible for a user to explicitly set a variable as safe, there will be some sort of risk of this sort. If a user knows what he is doing, it is up to him to think of the risks and decide whether he can live with them. Such a user can put (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. Most users are probably better off not to try to guess whether variables are safe to set to any value whatsoever or not. 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. 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. Sincerely, Luc.