From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Supporting multiline Package-Requires header Date: Tue, 11 Aug 2015 22:05:07 +0100 Message-ID: <87fv3po7ss.fsf@russet.org.uk> References: <87si7rjqmp.fsf@newcastle.ac.uk> <87fv3rjogj.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439328193 30434 80.91.229.3 (11 Aug 2015 21:23:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2015 21:23:13 +0000 (UTC) Cc: Kaushal , Emacs developers To: Artur Malabarba Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 23:23:05 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 1ZPH0i-0005fq-1D for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2015 23:23:04 +0200 Original-Received: from localhost ([::1]:35903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPH0g-0004BP-Go for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2015 17:23:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPH0T-0004AC-K5 for emacs-devel@gnu.org; Tue, 11 Aug 2015 17:22:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPH0Q-0006xA-Eh for emacs-devel@gnu.org; Tue, 11 Aug 2015 17:22:49 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:55644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPH0Q-0006wB-9I for emacs-devel@gnu.org; Tue, 11 Aug 2015 17:22:46 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZPGjN-0006nh-9u; Tue, 11 Aug 2015 22:05:09 +0100 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZPGjM-0007R0-KP; Tue, 11 Aug 2015 22:05:08 +0100 In-Reply-To: (Artur Malabarba's message of "Mon, 10 Aug 2015 14:08:12 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:188736 Archived-At: Artur Malabarba writes: >> Indeed. But it's only accidentally a sexp, in the sense that it's not >> actually a sexp in the buffer -- it's a comment. > > It's a commented-out sexp, but it's still a sexp, and it has to be a valid one. No, it's a sexp once the comments have been removed. I'm not just being pedantic here! This has consequences. >> What is the failure behaviour of package.el for this at the moment? > > Package.el will signal an error during installation if it's not a > valid sexp. The error itself will depend on what the problem is. > Here's what you get if you miss a closing paren for instance: > package-read-from-string: End of file during parsing My issue with this is that, iff I see this error, my first port of call is going to be check-parens, and generally look for unbalanced parens in the relevant file. And there are not going to be any, because in the file, there is no invalid sexp. There is a commented out, pseudo sexp. Here are three bugs caused by exactly this problem. https://github.com/cask/cask/issues/304 https://github.com/cask/cask/issues/284 https://github.com/expez/evil-smartparens/pull/2/files The first is from me, when I screwed this up in one of my own files, and spent an hour tearing my hair out (and I don't have much left). The last one is in evil-smartparens which missed a closing paren in Package-Requires despite being a package for keeping parens balanced. So, making Package-Requires more complex (even for multiline) seems not the right way forward. Just my thoughts, I will leave the issue in your hands from there. Phil