From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: mark .dir-locals.el buffer or file as safe instead of variables as safe Date: Wed, 27 Jun 2018 18:36:23 +1200 Message-ID: References: <037e51edfe70cb450157d1fb6f0ace0d@webmail.orcon.net.nz> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1530081283 3643 195.159.176.226 (27 Jun 2018 06:34:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Jun 2018 06:34:43 +0000 (UTC) User-Agent: Orcon Webmail Cc: Emacs-devel , emacs-devel@gnu.org To: cdelia@dc.uba.ar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 27 08:34:39 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 1fY42E-0000mQ-Nc for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 08:34:34 +0200 Original-Received: from localhost ([::1]:56980 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fY44M-0008So-3b for ged-emacs-devel@m.gmane.org; Wed, 27 Jun 2018 02:36:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fY44B-0008RX-8o for emacs-devel@gnu.org; Wed, 27 Jun 2018 02:36:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fY44A-0002c2-Cn for emacs-devel@gnu.org; Wed, 27 Jun 2018 02:36:35 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:36431) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fY444-0002X5-Tr; Wed, 27 Jun 2018 02:36:29 -0400 Original-Received: from [10.253.37.70] (port=45500 helo=webmail.orcon.net.nz) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fY440-000693-4d; Wed, 27 Jun 2018 18:36:24 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Wed, 27 Jun 2018 18:36:23 +1200 In-Reply-To: X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 60.234.4.34 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:226760 Archived-At: A useful enhancement may be the ability for the user to confirm a value as trusted only for particular contexts. If the context was the directory of the .dir-locals.el file (or dir-locals-directory-cache entry), then the user could confirm (once) a trusted value for anything covered by that .dir-locals.el and have it automatically accepted in future for other files covered by the same .dir-locals.el; but they would still need to confirm/trust an identical value for the variable when specified in another .dir-locals.el file elsewhere. (This is of course different to trusting the .dir-locals.el file itself.) This functionality is facilitated to an extent by the user's ability to assign a custom safe-local-variable predicate to a variable (in which they could test whatever contexts they wish, and return non-nil if the context and value are agreeable). Arguably the `eval' pseudo- variable also gives them free rein to achieve such goals. Still, I can see utility in supporting such functionality in a more direct manner. Beyond that, I've often wished I could make a particular dir-local value "ignored" for a particular .dir-locals.el file from some codebase that I'm working with, without necessarily ignoring it elsewhere; so I'm now wondering whether as well as callback functions for "safe", there should be support for callback functions for "ignored" and "risky" as well? And similarly, if the aforementioned direct support for contextually-trusted values were to be added, it would make sense to allow contextual ignore/risky there too. (I'm not sure whether contextual-risky makes as much sense, but it would seem odd to exclude it.) As it is, unless I've missed something, there are cases where I must either continually answer "no" to the prompt for accepting local values (each time I visit a file associated with that .dir-locals.el), or else get fed up and edit or delete the .dir-locals.el file (which of course might be under version control, which is then awkward if I don't actually want my change to be committed). There are also cases when I'd like to mark *some* of the values as permanently trusted, but might want to ignore others. Perhaps as well as the y/n/! options, there could be a new binding to invoke a more advanced UI for deciding what to do with the values on a per-variable basis. Contextual behaviour options could be exposed in that UI. -Phil