From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master db828f6: Don't rely on defaults in decoding UTF-8 encoded Lisp files Date: Mon, 28 Sep 2015 08:08:32 -0700 Organization: UCLA Computer Science Department Message-ID: <560957F0.8040504@cs.ucla.edu> References: <20150921165211.20434.28114@vcs.savannah.gnu.org> <83fv27mt7r.fsf@gnu.org> <83wpvfix7i.fsf@gnu.org> <83fv23hr0z.fsf@gnu.org> <5605CB6B.4000102@cs.ucla.edu> <83twqhhf0g.fsf@gnu.org> <5606AC48.7090801@cs.ucla.edu> <83zj09fbzp.fsf@gnu.org> <5606C140.6090309@cs.ucla.edu> <878u7trwlb.fsf@fencepost.gnu.org> <5606E995.2000102@cs.ucla.edu> <83si61ezxd.fsf@gnu.org> <2FCA0DAD-831B-4B0A-B948-9F31DE52B6F0@gmail.com> <87twqgrgtv.fsf@fencepost.gnu.org> <56077423.6030800@cs.ucla.edu> <87pp14qvkf.fsf@fencepost.gnu.org> <5608A8E0.8080201@cs.ucla.edu> <83pp13dogv.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443475917 12016 80.91.229.3 (28 Sep 2015 21:31:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 21:31:57 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 23:31:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zgg1S-0005W8-FQ for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 23:31:46 +0200 Original-Received: from localhost ([::1]:41006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgg1R-0004wl-PD for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2015 17:31:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zga2i-0004sL-N8 for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:08:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zga2h-0003G4-Uu for emacs-devel@gnu.org; Mon, 28 Sep 2015 11:08:40 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:60224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zga2c-0003F3-7B; Mon, 28 Sep 2015 11:08:34 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F3977160E57; Mon, 28 Sep 2015 08:08:32 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7D3Rbin_TgSz; Mon, 28 Sep 2015 08:08:32 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4CD55160E58; Mon, 28 Sep 2015 08:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G7w1uYQ5RH99; Mon, 28 Sep 2015 08:08:32 -0700 (PDT) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 349A5160E57; Mon, 28 Sep 2015 08:08:32 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 In-Reply-To: <83pp13dogv.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:190440 Archived-At: On 09/27/2015 11:53 PM, Eli Zaretskii wrote: > The best solution we have now is to have a coding cookie in each such > file, and the question is how can that be avoided. > > IOW, the solution should IMO be independent of user's preferences. Here's an idea: improve the handling of .dir-locals.el so that it could contain something like this: ((nil . ((coding . 'utf-8) (tab-width . 8) (fill-column . 70))) (c-mode . ((c-file-style . "GNU")))) This specification for "coding" would take precedence over coding inferred from environment settings. It would not take precedence over an explicit coding cookie in the file. Currently .dir-locals.el cannot specify 'coding', but I suspect that's mostly just due to the intricacies of the current implementation, not due to any specific desire to reject the use of 'coding' in .dir-locals.el.