Hi,
On Wed, 09 Jun 2010, Guillem Jover wrote:
> > > set listchars=tab:»-,trail:·
> > > `---
> > >
> > > to assist me spot those.
> >
> > Thanks, I find this setting too much annoying. I just added this to catch
> > common mistakes:
> > let c_space_errors=1
> > highlight EightSpaces ctermbg=lightred guibg=lightred
> > match EightSpaces /\(^\|\t\) /
> >
> > I find this less intrusive than seeing weird chars for all tabs.
>
> I've just got used to seeing them, and actually when I use an
> editor which does not show them, I feel naked. :)
Eventually I went for:
set listchars=tab:→ ,trail:·
It's much less intrusive and is acceptable for me.
> Personally I think that using tabs for indentation and spaces for
> aligning, is the only style which is sane and democratic! :), it has
> the nicest properties of them all, it just seems to me tools might be
> lacking.
>
> It preserves the structure of the text when quoting, it does too when
> changing the tab size (so it caters for different tastes). If you have
> them visible, it also helps (like if it was a ruler) see where each
> indentation level begins. Using tabs (instead of spaces) for indenting
> is the easiest way to guarantee there's always the correct amount of
> spacing (not more or less, as in a missing space).
I agree it's nice but I really don't care of people who try to use tabsize
different from the standard of 8 chars and the occasionnal bad indent
shown while quoting the code in a mail is really not much of a burden.
When I do a review, I concentrate on the code not on what kind of spaces
are used to align the wrapped line. As long as it's well aligned in my
editor that is...
> I don't think a checker will be able to catch all stylistic problems
> anyway w/o understanding C in some cases, and having taste in others :).
It should simply catch the most common problems. It's just work that
I don't want to have to do, reviewing the style in every details for every
patch. I want people to be able to get it mostly right without me and I
want to be able to quickly verify it.
> I don't actually mind entirely meanwhile having to fix those after the
> fact, or when applying them myself. So I'd really like to keep the
> style as it is. And just for reference (but I think I might have
I have no problem keeping it as is, but I prefer to not have to enforce
it.
And really I would prefer if you could review more patch because you
don't feel obliged to replace tabs with spaces on submitted code. But
then, that's your call. :-)
> > No, if the line is empty (not even a newline), fgets() returns NULL.
>
> It will be empty if the line starts with a literal NUL character (w/ or
> w/o newline).
Right, fixed.
> Hmm, maybe something like (completely untested):
Ok, adopted.
> I've skimmed over the branch. The asprintf might fail so it would need
> to get wrapped too.
Done.
> intent of the loop. The case of while loops with empty bodies usually
> needs code reestructuration, which depending on if it clarifies or
> complicates the code might not be worth it.
Would you prefer something like this to make it more obvious that
the action is really in the test?
while (do_something)
/* do nothing */;
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100609213831.ga1...@rivendell
