emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting multiline Package-Requires header


From: Phillip Lord
Subject: Re: Supporting multiline Package-Requires header
Date: Tue, 11 Aug 2015 22:05:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Artur Malabarba <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]