Not quite sure why there are so many differences. Perhaps we’ve gotten
out of the habit of running clang-format after every change.
I guess it’d be best to have a travis hook that runs clang-format for us
and reports any problems on pull requests.
This has multiple effects:
1) The i3 codebase is now consistently formatted. clang-format uncovered
plenty of places where inconsistent code made it into our code base.
2) When writing code, you don’t need to think or worry about our coding
style. Write it in yours, then run clang-format-3.5
3) When submitting patches, we don’t need to argue about coding style.
The basic idea is that we don’t want to care about _how_ we write the
code, but _what_ it does :). The coding style that we use is defined in
the .clang-format config file and is based on the google style, but
adapted in such a way that the number of modifications to the i3 code
base is minimal.
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
This fixes a race where we created cursors on the Xlib connection, flushed,
then used the cursor on the XCB connection. Even though we flushed, the X
server did not process the requests yet and therefore returned a BadCursor
error.
This bugfix uses the Xlib connection for setting the root window cursor which
will ensure that the requests are properly serialized.
An easy test for this (on my machine) is the following ~/.xsession:
xsetroot -cursor_name cross
exec i3
If you see a cross cursor instead of the pointer, the race happens. You’ll see
a error_code=6 error in your ~/.xsession-errors.
Deiz