[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU ELPA
Re: GNU ELPA
Sun, 24 Mar 2013 00:52:59 +0400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
On 23.03.2013 23:44, Stefan Monnier wrote:
I'd also like to know the current state of affairs.
It's described in elpa/packages/README.
company-pkg.el was updated ~12 hours ago, yet the new version of the
package still hasn't been built.
The cron job is run once per day, so you may have to wait up to 24h.
Also, the cron job may fail if the copyright lines aren't right.
Thank you. The rebuild interval doesn't seem to be mentioned in README,
It says "nightly", which I thought was clear enough (tho it doesn't say
which timezone is used, so it ends up meaning little more than once per day).
Ah, sorry. I found the "nightly" bit when I first read your previous
reply, but couldn't find it today, having opened elpa/README instead.
Could you also advise on my current problem with company/.dir-locals.el?
I don't understand what is the problem with it:
I added it to the repository, because Emacs committers sometimes install
changes into elpa branch directly.
Seems OK, yes. Actually, we could/should even place one in
I think so. Though that would force all packages with different
formatting to grow a similar file.
And yesterday I added there a setting for
`emacs-lisp-docstring-fill-column', to honor the existing formatting
in docstrings, and it's not safe-local by default.
Hmm... feel free to mark it as safe-local, but of course that won't help
users of Emacs<=24.3.
My thoughts exactly.
Should I remove the file, the variable from it, or can we add an
exception to not add .dir-locals.el to packages?
It doesn't seem to warrant such measures.
After all, the user can just say "accept and consider this value as safe
from now on".
I have a report that the prompt appears during the installation, in some
Probably an issue with some third-party package, but if Steve Purcell
has it, then any of the hundreds of people who base their Emacs
configuration off of his are likely to encounter it, too.
Maybe that's also acceptable, I haven't decided yet.