"Daniel P. Berrange" <berra...@redhat.com> writes: > On Tue, Sep 15, 2015 at 09:31:08AM -0600, Eric Blake wrote: >> ping >> >> On 08/24/2015 06:15 PM, John Snow wrote: >> > >> > >> > On 06/18/2015 10:05 AM, Markus Armbruster wrote: >> >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >> >> >>> On 18 June 2015 at 10:28, Markus Armbruster <arm...@redhat.com> wrote: >> >>>> However, I can't see how I could define a new C style there without >> >>>> pushing the "local variables" feature well beyond its intended use, and >> >>>> triggering the confirmation prompts. >> >>> >> >>> We wouldn't want to define a new C style, but in general the items >> >>> I have in my config over the Stroustrup defaults are going to be there >> >>> because I've noticed something where Stroustrup doesn't indent right... >> >> >> >> As far as I can see, the difference bwteen stroustrup style and yours is >> >> a few tweaks to c-offsets-alist and c-hanging-braces-alist. I'm not >> >> sure how to do that from .dir-locals.el. >> >> >> >>>> If we take Dan's patch, every Emacs user who hasn't already configured a >> >>>> suitable style profits. Users who have may have to adjust their >> >>>> configuration to work with or around Dan's patch. >> >>> >> >>> Is there some way to tell whether your emacs has picked up the local >> >>> style info rather than the one you have in your .emacs ? >> >> >> >> The obvious way is to check the buffer-local variables. Buffer-local >> >> variable c-indentation-style is the name of the style in use. Without >> >> anything in .emacs or local variables, it's "gnu". With your >> >> (c-add-style "qemu" qemu-c-style) in .emacs, it should be "qemu". With >> >> Dan's .dir-locals.el, it should be "stroustrup". >> >> >> >> When you can't or don't want to create or modify a .dir-locals.el, you >> >> can do something like this instead: >> >> >> >> (dir-locals-set-class-variables 'qemu '((c-mode >> >> . ((c-file-style . "qemu"))))) >> >> (dir-locals-set-directory-class "~/work/qemu" 'qemu) >> >> >> >> This *overrides* .dir-locals.el in my testing. >> >> >> > >> > ping -- any love for this for 2.5? > > So just to re-cap..... > > My original proposed .dir-locals.el was pretty short: > > ((c-mode . ((c-file-style . "stroustrup") > (indent-tabs-mode . nil)))) > > IIUC, the quote above says it is possible to override this with more > developer custom styles if desired, so it shouldn't cause any obvious > disadvantage / problem to contributors to have this set by default. > > I have tried an alternative .dir-locals.el that contains all of > Peter's rules (from http://wiki.linaro.org/PeterMaydell/QemuEmacsStyle) > which looks like this: > > > ;; Based on https://wiki.linaro.org/PeterMaydell/QemuEmacsStyle > ;; which aims to apply CODING_STYLE guidelines > ((c-mode . ( > (c-file-style . "stroustrup") > (indent-tabs-mode . nil) > (tab-width . 8) > (c-comment-only-line-offset . 1) > (c-hanging-braces-alist . ((substatement-open before after))) > (c-offsets-alist . ( > (statement-block-intro . +) > (substatement-open . 0) > (label . 0) > (statement-cont . +) > (innamespace . 0) > (inline-open . 0) > )) > (c-hanging-braces-alist . ( > (brace-list-open) > (brace-list-intro) > (brace-list-entry) > (brace-list-close) > (brace-entry-open) > (block-close . c-snug-do-while) > ;; structs have hanging braces on open > (class-open . (after)) > ;; ditto if statements > (substatement-open . (after)) > ;; and no auto newline at the end > (class-close) > )) > ))) > > The main downside/problem I found with having this more comprehensive > .dir-locals.el file, is that emacs will raise a warning at launch time: > > "The local variables list in /home/berrange/src/virt/qemu > contains vlaues that may not be safe (*). > > Do you want to apply it? You can type > y -- to apply the local variables list. > n -- to ignore the local variables list. > ! -- to apply the local variables list and permanently > mark these values (*) as safe (in the future, they > will be set automatically)" > > It will ask this every time it launches unless you say "!" > whereupon it modifies your $HOME/.emacs to disable the warning > > Personally I be fine with both the minimal approach or the more > comprehensive approach of Peter's, but I'd probably tend towards > the minimal approach to avoid the warnings problem.
Seconded. The "minimal approach" has been on the list since June, and it has my R-by. It's clearly better than nothing. Let's commit it now. We can always improve on it later.
