Hello, On Fri, Jul 10, 2009 at 07:10:07PM +0200, Carl Fredrik Hammar wrote: > On Fri, Jul 10, 2009 at 04:17:23AM +0200, olafbuddenha...@gmx.net wrote: > > > > > + /*Opens the port on which to set the new translator */ > > > > > + error_t > > > > > + open_port > > > > > + (int flags, mach_port_t * underlying, > > > > > + mach_msg_type_name_t * underlying_type, task_t task, void > > > > > *cookie) > > > > > > > > AFAIK open_port should not be indented, and the parameter list should > > > > start on the same line. > > > > > > I read in the GCS that emacs should be considered as an expert in GCS > > > indentation, and it indents things like this. Which authority should > > > I comply with? > > > > In general, the existing code is the authority. From what I've seen so > > far, this is handled very consistently in all existing Hurd code, and > > unionfs in fact has many examples. > > Also most code I've seen in the hurd has the return type on the same line. > The reasoning to have the return type on a seperate line is to get the > function name in column 0 so it can be easily grepped. But that > obviously can't be applied to nested functions.
Yeah, right. Thanks for pointing this out! I didn't really remember this detail until I actually came over other nested functions in unionfs. I guess the fact that emacs did this weird indentation is due to the fact that I didn't position the name of the function on the same line as its return value. Regards, scolobb
