From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Two problems with directory-local variables Date: Wed, 19 Sep 2018 18:42:42 -0700 (PDT) Message-ID: References: <87a7ogzgul.fsf@mbork.pl> <1d2129643cecde529cb9b47e4e015c48@webmail.orcon.net.nz> <87y3c0xh44.fsf@mbork.pl> <87k1njyav9.fsf@mail.linkov.net> <475f19d58094495c2a56d829bb7bbdd5@webmail.orcon.net.nz> <87sh27eizs.fsf@mail.linkov.net> <874leldw44.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1537407686 16003 195.159.176.226 (20 Sep 2018 01:41:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2018 01:41:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Juri Linkov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 20 03:41:22 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 1g2ny6-00043g-2q for ged-emacs-devel@m.gmane.org; Thu, 20 Sep 2018 03:41:22 +0200 Original-Received: from localhost ([::1]:47937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2o0C-0007Hq-HF for ged-emacs-devel@m.gmane.org; Wed, 19 Sep 2018 21:43:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2nzY-0007HW-OI for emacs-devel@gnu.org; Wed, 19 Sep 2018 21:42:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2nzV-0005Ic-HR for emacs-devel@gnu.org; Wed, 19 Sep 2018 21:42:52 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:41792) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g2nzV-0005Gj-24 for emacs-devel@gnu.org; Wed, 19 Sep 2018 21:42:49 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8K1dJ3k114033; Thu, 20 Sep 2018 01:42:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=FQVBzSJSpSTeAtKeHySBY63uyHOXz2Nua1Xw7sztXWM=; b=J1yk51n9Nr57L3135LvM7XmM11glGGt4cetNfUMFKjfnkpu5n0lumGBgqAk7Apl2z+XQ LIzbcLymHb+gaWabj9T6vvUkBj0ElavrLcjT6h/mVS3xKsRw671v+q7ul2UKPVucuv4w 6kTiib6zJhH8o/qjEPcX6QCV1eU6Y0FsbUxBWVJRVhmbmzHt8vv/mBvcD+RR7DhoQQB2 PX6mC8yhbA5XrVm13IqyEoYPM+rflU5zZ0MDjX8OGar3nsRk1vJW4siqKkbqm+CG1z1b Ib1qGobcni/GP0MEnoCFZy2QzOIwYZSG3G43FqorhbPWJcVMbUWtNyeiqVUhef7l0eid bA== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2mgtqr67x6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Sep 2018 01:42:47 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w8K1gjG0026511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 Sep 2018 01:42:45 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8K1ghEt003159; Thu, 20 Sep 2018 01:42:44 GMT In-Reply-To: <874leldw44.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9021 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=828 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809200016 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 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:229974 Archived-At: > Given that, I don't see what would be a good choice for generalization: >=20 > 1. Since requirements for this feature are too vague, it doesn't seem > to fit well into low-level printing functions. >=20 > 2. Reformatting the printed output in pp-buffer to add dots where necessa= ry > also doesn't look like an elegant solution. >=20 > 3. Implementing print-alist poses a question how to define at which level= s > to print alists with dotted syntax. >=20 > 4. Since only add-dir-local-variable knows the semantics of used data > structures, the simplest way would be to implement printing of each le= vel > explicitly in add-dir-local-variable. I don't think there's a good design for this. Whatever some designer's inte= ntion beforehand might be, the result will be misleading in at least some context= s. And the problem is that when it's misleading (showing some dots but not others it can be even more confusing for users than consistently doing eith= er what we do now - no dots for a list cdr, at all levels - or adding dots at = all levels. I think (so far, but I might change my mind if I see a good argument) that = this is really something that users of Lisp just have to get used to. It can be = a gotcha - like getting used to quoting (when to quote and when not to). Lisp has a few such gotchas. We could I suppose have `print-dot-levels', like we have `print-level', to = give code control over the level (top-down). That might be a little better than `print-dotted' (Boolean). But is it really worth it (needed)? I tend not to think it's worth it to have just a top-level `print-alist', in any case (an= d the alist might not be at top level). As Stefan said, "only the human coder can know which cons cell should be printed dotted and which shouldn't." I'd change "cell" to "cells", but otherwise I pretty much agree.