Bug 91906

Summary: source formatter inserts unexpected linefeed
Product: [Applications] kdevelop Reporter: Rutger ter Borg <rutger>
Component: AstyleAssignee: kdevelop-bugs-null
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Rutger ter Borg 2004-10-22 16:44:40 UTC 
Version:           3.1.0 (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
OS:                Linux

When I use the option "Reformat source", an expected indentation occurs. 
I am using the "Kernighan & Ritchie" style of C++ reformatting.

The following input case

ublas::vector<Type> one_vector( K.size1() );
atlas::set( 1.0, one_vector );

will become after formatting:

ublas::vector<Type> one_vector( K.size1() );
atlas::set
   ( 1.0, one_vector );

The expected behaviour is that the atlas::set remains on the same line. 
It is reproducable at all times. After experimenting I noticed that "set(a,b)" gets an additional line feed as well.
Comment 1 Matt Rogers 2004-12-14 22:42:34 UTC 
we'll need to know what settings you've used in the source formatter in order to reproduce this.
Comment 2 Rutger ter Borg 2004-12-16 18:11:30 UTC 
I'm using "Kernighan & Ritchie", which disables any further choices for the source formatter. Or do you mean something different?
Comment 3 Matt Rogers 2004-12-16 19:53:16 UTC 
nope, that's exactly what i meant. thanks. :)
Comment 4 Rutger ter Borg 2005-02-06 12:36:24 UTC 
Another case, which indents too much after the first {:

template<int N, typename Vector>
class gaussian: public std::binary_function<Vector,Vector,typename kml::power_return_type<N,Vector>::type> {
public:
};

in this case, the whole class is indented with about 8 spaces... If you change the return type of the std::public_function to something without ::'s (e.g. just a plain double), it is done correctly again.
Comment 5 Matt Rogers 2005-10-20 02:30:31 UTC 

*** This bug has been marked as a duplicate of 89543 ***