[cperl] Sub indentation trouble

[Julien K.]

Dear Emacs & Perl users,

[ This post is an updated version of a previous post on gnu.emacs.help that
didn't get any answer; sorry for those who read both groups]

I'm having trouble with 'sub' indentation with cperl mode (version > 4.32).
I think my problem does not depend on the emacs version but on cperl version
as I got the same behaviour on Linux and OsX both with last Emacs and XEmacs.

I'm using GNU-style indentation, the incorrect indentation happens after
the 'sub' closing statement.

With my current setting the following line is indented like the closing
brace of the 'sub':

<<<<<
sub mySub
{ my ($self) = @_ ;
# perl stuff
return ($var) ;
}
# Other stuff
sub myOtherSub
{ ...

^^ Extra indent
I'd like 'sub' block indentation be like 'foreach' or 'if' blocks, ie
return to column 0 for the next statement.

<<<<<
sub mySub
{ my ($self) = @_ ;
# perl stuff
return ($var) ;
}
# Other stuff
sub myOtherSub
{ ...
Any hints?

Cheers,

Julien

 

[smallpond]

Any hints?

If emacs were written in perl and not lisp, then this would be an
excellent
in which to post your question.

Perhaps you want to modify the indent variables when loading perl-
mode.el?

Various indentation styles: K&R BSD BLK GNU LW
perl-indent-level 5 8 0 2 4
perl-continued-statement-offset 5 8 4 2 4
perl-continued-brace-offset 0 0 0 0 -4
perl-brace-offset -5 -8 0 0 0
perl-brace-imaginary-offset 0 0 4 0 0
perl-label-offset -5 -8 -2 -2 -2

 

[Julien K.]

If emacs were written in perl and not lisp, then this would be an
excellent in which to post your question.

I'm aware of the off-topic part (half?) of my question, but:

1/ the author of cperl (thank you very much for that code) seems to
read this newsgroup,
2/ Perl coders sometimes use (X?)Emacs ;-)
3/ Some of those coders may have run into the same trouble...

Perhaps you want to modify the indent variables when loading perl-
mode.el?

Various indentation styles: K&R BSD BLK GNU LW
perl-indent-level 5 8 0 2 4
perl-continued-statement-offset 5 8 4 2 4
perl-continued-brace-offset 0 0 0 0 -4
perl-brace-offset -5 -8 0 0 0
perl-brace-imaginary-offset 0 0 4 0 0
perl-label-offset -5 -8 -2 -2 -2

That's what I tried before posting, based on informations from the cperl
minidocs but with not much luck, and to set cperl-close-paren-offset
to several negative values...

I also tried to track what changed before cperl-5.1 because my settings
did not changed during the past few years (if it's not broken...)

Thanks for your reply anyway,

Julien

 

[Ilya Zakharevich]

I also tried to track what changed before cperl-5.1 because my settings
did not changed during the past few years (if it's not broken...)

All changes should be documented in cperl-mode.el.

Yours,
Ilya

 

[Julien K.]

All changes should be documented in cperl-mode.el.

So let me rephrase this point:

I didn't find the change(s) that led to the modification in 'sub's
indentation within all the changes between cperl versions reported in the
beginning of cperl.el.

Cheers,

Julien

 

[Julien K.]

There should be something liek "Major rework of indentation engine".

Indeed, the cperl-5.0 indents subs with return to top-level, and the next
version available on your site does not.

So which variable should I customize to get the 5.0 behaviour back in
cperl-6.2?

1/4 ;-)

???

Cheers,

Julien

 

[Ilya Zakharevich]

Indeed, the cperl-5.0 indents subs with return to top-level, and the next
version available on your site does not.

Sorry, I do not understand this sentence...

So which variable should I customize to get the 5.0 behaviour back in
cperl-6.2?

The simplest solution would be to switch to a sane indentation style.
I have no idea what you WANT to see with your examples. And until I
know what is the intent, I can't classify this as a bug.

quarter of a smiley?

Ilya

 

[Julien K.]

Sorry, I do not understand this sentence...

I grabbed the differents cperl from this location:
<http://math.berkeley.edu/~ilya/software/emacs/>

As you said (and as I thought before my initial post ;-) the indentation
works ok for me up to cperl-5.0.

The simplest solution would be to switch to a sane indentation style.

I use the GNU perl-style with various settings like
cperl-extra-newline-before-brace and cperl-extra-newline-before-brace-multiline
set to true. Isn't it sane enough ? ;-)

I have no idea what you WANT to see with your examples.

Ok, I'll try to be more precise. I prefer the opening brace to be on a
separate line after the 'sub' statement. The closing brace of the 'sub'
declaration is on the same column that the opening one. So far so good.

But the next line _after_ the closing brace indents to the same column as
the closing brace itself:

<<<<
sub test
{ my ($self) = @_ ;
}
# the commment starts at col 2 instead of col 0
The if/else/... blocks don't behave like that:
<<<<
if (test)
{
}
# comment that starts at col 0 -- ok

And until I know what is the intent, I can't classify this as a bug.

I'm not sure it is a bug, maybe I didn't understand well the settings of
cperl.

I've been using cperl nearly every day for Perl programming for the
past five years, and I find it very useful. Thanks a lot for your work (and
now for your help).

Julien

 

[Uri Guttman]

JK> sub test
JK> { my ($self) = @_ ;
JK> }
JK> # the commment starts at col 2 instead of col 0

regardless of how you use cprerl mode, that is one fugly indent style!!



uri

 

[Julien K.]

JK> sub test
JK> { my ($self) = @_ ;
JK> }
JK> # the commment starts at col 2 instead of col 0

regardless of how you use cprerl mode, that is one fugly indent style!!

Hey, this very scheme is what I want to get rid of. Otherwise after six or
seven "sub" declaration I'll be very close to the right side of the
screen... ;-)

BTW what's wrong with this in your opinion:
<<<<<
sub test
{ my ($self) = @_ ;
# stuff
return ($var) ;
}

sub _init
{ my $self = shift ;
# ...
}
I find this indent scheme very easy to read.

Julien

 

[Uri Guttman]

JK> sub test
JK> { my ($self) = @_ ;
JK> }
JK> # the commment starts at col 2 instead of col 0
JK> Hey, this very scheme is what I want to get rid of. Otherwise after six or
JK> seven "sub" declaration I'll be very close to the right side of the
JK> screen... ;-)

i wasn't concerned with subs creeping to the right.

JK> BTW what's wrong with this in your opinion:
JK> <<<<<
JK> sub test
JK> { my ($self) = @_ ;
JK> # stuff
JK> return ($var) ;
JK> }

JK> sub _init
JK> { my $self = shift ;
JK> # ...
JK> }
JK> I find this indent scheme very easy to read.

you may find it easy but it is not close to the perl style (also K&R
from WAY back) that is most common on cpan and in the perl
community. but you can't easily argue about style any more than you can
about the usual wars like editors and langs. suffice it to say, you are
in the extreme minority (maybe the only one? with that style.

uri

 

[Julien K.]

JK> sub test
JK> { my ($self) = @_ ;
JK> }
JK> # the commment starts at col 2 instead of col 0

JK> Hey, this very scheme is what I want to get rid of. Otherwise after
JK> six or seven "sub" declaration I'll be very close to the right side
JK> of the screen... ;-)

i wasn't concerned with subs creeping to the right.

I am

JK> BTW what's wrong with this in your opinion:
JK> <<<<<
JK> sub test
JK> { my ($self) = @_ ;
JK> # stuff
JK> return ($var) ;
JK> }

JK> sub _init
JK> { my $self = shift ;
JK> # ...
JK> }

JK> I find this indent scheme very easy to read.

you may find it easy but it is not close to the perl style (also K&R from
WAY back) that is most common on cpan and in the perl community.

I'm aware of that point and I don't really mind since nobody else reads my
code. I've read code from various people, no one has the same indent scheme
and it doesn't matter: IMHO that's the editor job to indent according to the
user's needs (as all ident schemes will lead to the same execution).

but you can't easily argue about style any more than you can about the
usual wars like editors and langs.

or newsreaders... I won't, I'm over 14. You're on your own and so do I.

suffice it to say, you are in the extreme minority (maybe the only one?
with that style.

I'm not the only one, a friend of mine uses that style too, we're at least
two, beware ;-).

This is the GNU indent-style from cperl (well, it was until cperl-5.1).
It's not very different from the perl style one can find in perltoot, except
that it uses a newline before block opening brace (cperl has that kind of
feature).

Anyway, thanks for your advice,

Julien

 

[Uri Guttman]

JK> I'm aware of that point and I don't really mind since nobody
JK> else reads my code. I've read code from various people, no one has
JK> the same indent scheme and it doesn't matter: IMHO that's the
JK> editor job to indent according to the user's needs (as all ident
JK> schemes will lead to the same execution).

well, writing code in a vacuum isn't a good idea. having others read
your code is one of the best ways for your code and your skills to get
better. this is one of my biggest issues when i do code review is how
so little code does get reviewed and usually very late in the process
(when it is time to rewrite it from scratch). so formatting your code so
most others will read it easily is a good idea. sure they can use
perltidy to reformat it but that is just more work. as people say here,
proper editing and quoting of posts is good since you save more global
work by letting others do less work. the same applies to coding styles.

JK> I'm not the only one, a friend of mine uses that style too,
JK> we're at least two, beware ;-).

wooh, a growing movement!

JK> This is the GNU indent-style from cperl (well, it was until
JK> cperl-5.1). It's not very different from the perl style one can
JK> find in perltoot, except that it uses a newline before block
JK> opening brace (cperl has that kind of feature).

it isn't K&R which is the 'standard' perl style. open brace on the end
of the code line, code indented one level (and use hard tabs as they can
be displayed/printed to any indent level) and closing brace at the same
indent as the opening line. that is all i care about. well, good white
space use is important too!

uri

 

[Julien K.]

JK> I'm aware of that point and I don't really mind since nobody
JK> else reads my code. I've read code from various people, no one has
JK> the same indent scheme and it doesn't matter: IMHO that's the
JK> editor job to indent according to the user's needs (as all ident
JK> schemes will lead to the same execution).

well, writing code in a vacuum isn't a good idea. having others read
your code is one of the best ways for your code and your skills to get
better.

I agree with you but nobody can review my code in my every day-job,
because I'm the only one able to write a piece of code (Fortran, Matlab
Perl...). Programming should not be a part of my job, but it makes me save a
lot of time (well I like to think so).

this is one of my biggest issues when i do code review is how so little
code does get reviewed and usually very late in the process (when it is
time to rewrite it from scratch). so formatting your code so most others
will read it easily is a good idea.

cperl has an indent-region function that indents the code according to the
current indent-style. Pretty impressing.

as people say here, proper editing and quoting of posts is good since you
save more global work by letting others do less work. the same applies to
coding styles.

And so does the proper use of uppercase letters. ;-)

Julien

 

[Ilya Zakharevich]

sub test
{ my ($self) = @_ ;
}
# the commment starts at col 2 instead of col 0

So the indent of `#' happens w.r.t. the `{', not w.r.t. `sub'.

The if/else/... blocks don't behave like that:
<<<<
if (test)
{
}
# comment that starts at col 0 -- ok

I'm not sure it is a bug, maybe I didn't understand well the settings of
cperl.

As you see, there is some code to detect that `{' follows `if', and
indent accordingly. Apparently, there is no such code to recognize
that `{' follows `sub'. This should be considered a bug (all
indentation of continuation lines which CPerl is putting itself should
be "undoable" when it tries to indent following lines).

However, since I hate such indentation styles [*], I try not to pay a lot
of attention when viewing such code. As a result, I'm not completely
sure EXACTLY WHICH constructs should be recognized before `{' to see
that `{' starts a "continuation line".

[*] IMO, the purpose of indentation style is to maintain
easy-to-visualize matching of paired delimiters, while
preserving as much as possible the scarce resources - such as
screen real estate. (E.g., I cuddle my `else's.)

Yours,
Ilya

 

[Julien K.]

As you see, there is some code to detect that `{' follows `if', and
indent accordingly. Apparently, there is no such code to recognize
that `{' follows `sub'.

Like Uri said in another part of the thread, this is not observable when
one writes:
<<<<<
sub test {
# stuff
}

This should be considered a bug (all indentation of continuation lines
which CPerl is putting itself should be "undoable" when it tries to indent
following lines).

Correct me if I'm wrong, but a prototyped 'sub' should behave like a if
block alone:
<<<<<
sub test ($$)
{ my ($a,$b) = @_ ;
#...
}

if ($a<0)
{ # ...
}

However, since I hate such indentation styles [*], I try not to pay a lot
of attention when viewing such code. As a result, I'm not completely
sure EXACTLY WHICH constructs should be recognized before `{' to see
that `{' starts a "continuation line".

[*] IMO, the purpose of indentation style is to maintain
easy-to-visualize matching of paired delimiters, while
preserving as much as possible the scarce resources - such as
screen real estate. (E.g., I cuddle my `else's.)

"easy-to-visualize matching of paired delimiters" is exactly why I like
this style, the corresponding braces are vertically aligned, as nothing
crosses their column. Well, having matching delimiters colored helps too...

Cheers,

Julien

 

[Peter J. Holzer]

JK> BTW what's wrong with this in your opinion:
JK> <<<<<
JK> sub test
JK> { my ($self) = @_ ;
JK> # stuff
JK> return ($var) ;
JK> }

[...]

This is the GNU indent-style from cperl (well, it was until cperl-5.1).
It's not very different from the perl style one can find in perltoot,

Hmm?


sub population {
my $self = shift;
if (ref $self) {
return ${ $self->{"_CENSUS"} };
} else {
return $Census;
}
}

looks very different to me:

* The opening brace is at the end of the line with sub/if/...
* The closing brace is at the same indentation as sub/if/...
* The first line of the block is in a new line

hp

 

[Ilya Zakharevich]

Like Uri said in another part of the thread, this is not observable when
one writes:
<<<<<
sub test {
# stuff
}

Very observable. Just have `{' at start of line. ;-)

Correct me if I'm wrong, but a prototyped 'sub' should behave like a if
block alone:
<<<<<
sub test ($$)
{ my ($a,$b) = @_ ;
#...
}

I have no idea what your "should" means here...

"easy-to-visualize matching of paired delimiters" is exactly why I like
this style, the corresponding braces are vertically aligned, as nothing
crosses their column. Well, having matching delimiters colored helps too...

This is not easier to visualize than when `}' matches `sub', but
breaks other requirements... Hmm, on the other hand, since you cuddle
the code after `{', it takes the same amount of lines as when `{' us
cuddled after `sub'... So, when following my requirements, the only
problem with your style is that the minimal indent is 4, which is not
in any way critical.

Yours,
Ilya

 

[Tad J McClellan]

^^^^^^^^
^^^^^^^^

It is bad form to masquerade as a domain that you do not have
permission to use...

BTW what's wrong with this in your opinion:
<<<<<
sub test
{ my ($self) = @_ ;
# stuff
return ($var) ;
}

That appears to be a (poor) modification to the Whitesmiths style.

http://en.wikipedia.org/wiki/Indent_style

I find this indent scheme very easy to read.

<religion>
If it ain't 1TBS, it ain't shit.
</religion>