Re: GNU ELPA

[Dmitry Gutov]

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,
> > though.
>
> 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
> elpa/.dir-locals.el.

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 
circumstances: https://github.com/company-mode/company-mode/issues/4

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.