On Wed, Apr 09, 2008 at 08:42:01PM +0200, Jim Meyering wrote: > "Daniel P. Berrange" <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 09, 2008 at 02:40:13PM +0100, Richard W.M. Jones wrote: > >> On Wed, Apr 09, 2008 at 02:43:22PM +0200, Jim Meyering wrote: > >> > Please don't add the "tab-width: 4" specifier. > >> > Specifying a tab-width at all in a new file with "indent-tabs-mode: nil" > >> > is a contradiction. The latter says there should be no TABs, yet > >> > the former says "when there are, give them width 4." Coding style > >> > guidelines are universal in their recommendations to stick with 8-byte > >> > TAB stops, independent of whether you actually use TAB or spaces. > >> > >> Agreed, good idea. > > > > ACK. > > > > Could we get a make syntax-check test to look for these bogus tabs too > > I've done that. > Abbreviated patches below. > > However, there are some "issues" to consider. > Any global space-changing delta like these is going to cause > trouble (conflicts) for people with pending changes and on branches. > This one isn't too bad (as these things go), since the TAB-to-space > change affects fewer than 1500 lines in 37 files. However, the > new rule enforces the coding standard only in files with an existing > "indent-tabs-mode: nil" directive. There are currently 42 .[ch] files > that don't have such a directive (excluding gnulib/). > > $ git ls-files|grep -E '\.[ch]$'|xargs grep -L indent-tabs-mode|grep -v \ > gnulib|wc -l > 42 > > If I were to do the same for those remaining files, > the TAB-to-space change would modify an additional 2817 lines > in 28 files: > > $ git ls-files|grep -E '\.[ch]$'|xargs grep -L indent-tabs-mode|grep -v \ > gnulib|xargs grep -E '^ * '|wc -l > 2817 > $ git ls-files|grep -E '\.[ch]$'|xargs grep -L indent-tabs-mode|grep -v \ > gnulib|xargs grep -El '^ * '|wc -l > 28 > > My opinion is that if it's worth doing the first, it's also worth > finishing the job, ... but then I don't have any huge re-architecting > changes in my queue.
The only changes I have pending are the host device enumeration patches which are all new code, so unaffected, and the serial device support for QEMU which is easy enough to fix-up since its fairly isolated chunks of code. So I think its a net win to fix up everything. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list