Re: [PATCH][RFC] Add a rule for indenting labels

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

 



On 03/21/2014 08:49 AM, Daniel P. Berrange wrote:
> On Fri, Mar 21, 2014 at 08:19:42AM -0600, Eric Blake wrote:
>> On 03/21/2014 07:11 AM, Ján Tomko wrote:
>>> Indent labels by one space.
>>>
>>> Add the rule to HACKING and enforce it by syntax-check.
>>> ---
>>> Adding a space helps git's function context detection, but the fallout
>>> patch is over 800K.
>>>
>>> My reasoning for also indenting labels in nested code is that
>>> vim's cinoptions don't have a separate option for these labels
>>> (or I haven't searched hard enough?).
>>
>> Alas, I don't know enough on vim to help there.

Okay, I've spent some more time on the emacs side; emacs has the option
of a c-label-minimum-indent, but applies it only to top-level labels
(and not to nested code labels).  Where it gets weird is that
c-label-minimum-indent is applied by default only for gnu mode indent,
but not other modes.  We want libvirt in K&R mode indent.  Emacs is
customizable, so you can request other indent modes to also use label
minimum indent by setting c-special-indent-hook, but as a hook it is
deemed dangerous when set via .dir-locals.el and warns the user on every
file that you open, making that particular customization harder to set
as a project-level default.

>> This doesn't do what you want; it sounds like you want to require all
>> labels to have (4n+1) spaces, so you want 4n+{0,2,3} to be forbidden.

Emacs does not have an easy way to enforce (4n+1) spaces, only a minimum
indent.  Furthermore, it is only the top-level labels that interfere
with git function locations; so at this point, I'm leaning towards a simpler

@prohibit='^[_a-zA-Z0-9]+):$$'

and just not worry about nested indent (we have fewer nested labels anyway).

>> The rest of this makes sense, if I can figure out why my emacs settings
>> aren't doing this already, and if we update .dir-locals.el in the same
>> patch.
> 
> FWIW, my emacs is doing the right thing wrt this proposed hacking
> rule and I don't have any .emacsrc file at all on this machine - just
> plain default settings.

I found the difference between Dan's setup and mine - in my ~/.emacs, I
actually created a new style mode libvirt-c-mode (I created it back in
2010, with Jim Meyering's help, before we had .dir-locals.el).  Although
my mode and the settings in .dir-locals.el appear identical [basically:
(defun libvirt-c-mode ()
  "C mode with adjusted defaults for use with libvirt."
  (interactive)
  (c-set-style "K&R")
  (setq indent-tabs-mode nil) ; indent using spaces, not TABs
  (setq c-indent-level 4)
  (setq c-basic-offset 4))
(add-hook 'c-mode-hook
	  '(lambda () (if (string-match "/libvirt" (buffer-file-name))
			  (libvirt-c-mode))))
], where it gets different is that c-label-minimum-indent defaults to
only applying to gnu style.  In creating my own style, I left gnu style,
so the minimum no longer applied to me.  But adding:
  (setq c-special-indent-hook c-gnu-impose-minimum) in the list of
settings in my mode fixed things so it behaves the way Dan was seeing;
as did completely removing my custom mode and instead relying on
.dir-locals.el.  c-special-indent-hook won't work in .dir-locals.el, but
now that I know the cause of the difference and how to work around it on
my end, I'm okay if we force a minimum indent.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]