[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
Paul Cochrane
# Please include the string: [perl #40361]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40361 >
Hi,
This is a patch of more Perl files that I missed with my previous
patch concerning the perl coding standards coda (the last patch was
only .pl files, this one patches as many of the .t files that I could
find). Some of the files affected by this patch have also been
converted from dos to unix line endings. I've also noticed some test
files that are Perl but don't have the shebang line; should this line
be in all Perl files and therefore be a Cage task?
Files affected by this patch:
t/pmc/signal.t
t/pmc/mmd.t
t/pmc/boolean.t
t/pmc/file.t
t/pmc/timer.t
t/pmc/globals.t
t/pmc/fixedstringarray.t
t/pmc/eval.t
t/pmc/sub.t
t/pmc/fixedpmcarray.t
t/pmc/config.t
t/pmc/complex.t
t/pmc/fixedintegerarray.t
t/pmc/array.t
t/pmc/resizablepmcarray.t
t/pmc/os.t
t/pmc/n_arithmetics.t
t/pmc/threads.t
t/pmc/namespace.t
t/pmc/resizableintegerarray.t
t/pmc/sarray.t
t/pmc/resizablefloatarray.t
t/pmc/coroutine.t
t/pmc/prop.t
t/pmc/freeze.t
t/pmc/ro.t
t/pmc/intlist.t
t/pmc/key.t
t/pmc/orderedhash.t
t/pmc/multiarray.t
t/pmc/fixedbooleanarray.t
t/pmc/undef.t
t/pmc/builtin.t
t/pmc/string.t
t/pmc/io.t
t/pmc/sys.t
t/pmc/resizablebooleanarray.t
t/pmc/object-meths.t
t/pmc/fixedfloatarray.t
t/pmc/env.t
t/pmc/objects.t
t/pmc/pair.t
t/pmc/exception.t
t/pmc/object-mro.t
t/pmc/managedstruct.t
t/pmc/multisub.t
t/pmc/resizablestringarray.t
t/pmc/tqueue.t
t/pmc/nci.t
t/pmc/delegate.t
t/pmc/ref.t
t/pmc/bigint.t
t/stress/gc.t
t/src/basic.t
t/src/hash.t
t/src/sprintf.t
t/src/intlist.t
t/src/string.t
t/src/io.t
t/src/exit.t
t/src/compiler.t
t/src/list.t
t/dynpmc/gdbmhash.t
t/dynpmc/sparse_perlarray.t
t/dynpmc/perlarray.t
t/dynpmc/foo.t
t/dynpmc/perlhash.t
t/dynpmc/quantumreg.t
t/dynpmc/dynlexpad.t
t/dynpmc/sub.t
t/dynpmc/perlstring.t
t/compilers/pge/pge_globs.t
t/compilers/pge/pge-hs.t
t/compilers/pge/03-optable.t
t/compilers/pge/pge_util.t
t/compilers/pge/pge_examples.t
t/compilers/pge/pge.t
t/tools/pbc_merge.t
t/tools/pmc2c.t
t/perl/Parrot_IO.t
t/perl/Parrot_Docs.t
t/perl/Parrot_PIR_Formatter.t
t/perl/Parrot_Distribution.t
t/perl/Parrot_Test.t
t/dynoplibs/dan.t
t/dynoplibs/myops.t
t/stm/basic.t
t/stm/basic_mt.t
t/stm/runtime.t
t/stm/queue.t
t/stm/llqueue.t
t/distro/manifest.t
t/distro/test_file_coverage.t
t/distro/manifest_skip.t
t/run/exit.t
t/doc/pod.t
t/doc/opcode-doc.t
t/native_pbc/number.t
t/native_pbc/header.t
t/native_pbc/integer.t
t/native_pbc/string.t
t/op/01-parse_ops.t
t/examples/pasm.t
t/examples/past.t
t/examples/subs.t
t/codingstd/code_coda.t
t/codingstd/cppcomments.t
t/codingstd/fixme.t
t/codingstd/tabs.t
t/codingstd/linelength.t
t/codingstd/cuddled_else.t
languages/python/t/pmc/pyclass.t
languages/python/t/pmc/pybuiltin.t
languages/python/t/pmc/pycomplex.t
languages/python/t/pmc/pyint.t
languages/python/t/pmc/pyfunc.t
languages/jako/t/examples.t
languages/HQ9plus/t/basic.t
languages/pugs/t/pmc/bit.t
languages/pugs/t/pmc/num.t
languages/pugs/t/pmc/undef.t
languages/pugs/t/pmc/module.t
languages/pugs/t/pmc/any.t
languages/pugs/t/pmc/str.t
languages/pugs/t/pmc/tuple.t
languages/pugs/t/pmc/int.t
languages/pugs/t/pmc/code.t
languages/pugs/t/pmc/bool.t
languages/pugs/t/pmc/mapping.t
languages/lua/t/expr.t
languages/lua/t/boolean.t
languages/lua/t/repeat.t
languages/lua/t/nil.t
languages/lua/t/lexico.t
languages/lua/t/assign.t
languages/lua/t/table.t
languages/lua/t/iterator.t
languages/lua/t/if.t
languages/lua/t/object.t
languages/lua/t/fornum.t
languages/lua/t/string.t
languages/lua/t/io.t
languages/lua/t/functions.t
languages/lua/t/scope.t
languages/lua/t/pmc/boolean.t
languages/lua/t/pmc/nil.t
languages/lua/t/pmc/function.t
languages/lua/t/pmc/string.t
languages/lua/t/pmc/table.t
languages/lua/t/pmc/thread.t
languages/lua/t/pmc/userdata.t
languages/lua/t/pmc/number.t
languages/lua/t/examples.t
languages/lua/t/basic.t
languages/lua/t/os.t
languages/lua/t/forlist.t
languages/lua/t/function.t
languages/lua/t/constructor.t
languages/lua/t/debug.t
languages/lua/t/number.t
languages/lua/t/math.t
languages/lua/t/strings.t
languages/lua/t/metatable.t
languages/lua/t/coroutine.t
languages/lua/t/while.t
languages/lua/t/userdata.t
languages/lua/t/tables.t
languages/lua/t/closure.t
languages/WMLScript/t/pmc/integer.t
languages/WMLScript/t/pmc/boolean.t
languages/WMLScript/t/pmc/float.t
languages/WMLScript/t/pmc/string.t
languages/WMLScript/t/pmc/invalid.t
languages/WMLScript/t/expr.t
languages/WMLScript/t/examples.t
languages/WMLScript/t/boolean.t
languages/WMLScript/t/literals.t
languages/WMLScript/t/lang.t
languages/WMLScript/t/runtime.t
languages/WMLScript/t/invalid.t
languages/WMLScript/t/statements.t
languages/WMLScript/t/pragmas.t
languages/WMLScript/t/libfloat.t
languages/WMLScript/t/integer.t
languages/WMLScript/t/libstring.t
languages/WMLScript/t/float.t
languages/WMLScript/t/string.t
languages/WMLScript/t/functions.t
languages/WMLScript/t/logical.t
languages/ook/t/basic.t
languages/scheme/t/arith/logic.t
languages/scheme/t/arith/basic.t
languages/scheme/t/arith/nested.t
languages/scheme/t/io/basic.t
languages/scheme/t/logic/defines.t
languages/scheme/t/logic/lists.t
languages/scheme/t/logic/basic.t
languages/befunge/t/basic.t
Regards,
Paul
Jerry Gay
> # New Ticket Created by "Paul Cochrane"
> # Please include the string: [perl #40361]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40361 >
>
> patch concerning the perl coding standards coda (the last patch was
> only .pl files, this one patches as many of the .t files that I could
> find). Some of the files affected by this patch have also been
> converted from dos to unix line endings. I've also noticed some test
> files that are Perl but don't have the shebang line; should this line
> be in all Perl files and therefore be a Cage task?
>
one, though, for a few reasons.
firstly, line endings are unrelated to this effort and should be a
separate patch. that's no biggie, and alone wouldn't stop me from
applying.
more importantly, perl test files simply cannot be limited to 100
character lines, for reasons i'll explain in a moment. the vim coda
does not specify a max line length, but it seems the emacs coda does,
if i interpret 'fill-column: 100' correctly. (please correct me if i'm
wrong, emacs users of the world) *vim rocks* ;-)
test functions require ordered parameters (instead of unordered, named
params--something not familiar in perl testing anyway.) the suite also
makes liberal use of heredocs, the first of which (due to a perl5
limitation) *always* begins immediately after the first newline. that
is:
pir_output_is(<<$pre.'CODE'.$post,<<'OUTPUT','some really long but
necessary and comprehensive test description');
may exceed 100 characters. it seems foolish to me to make a test
developer code around this by creating a $description variable and
stuffing the contents of the description in a separate line of code.
therefore, i'm invoking the "exceptional circumstances" clause in the
definition of "must" in pdd07 for parrot tests written in perl.
for similar reasons, it's not welcome to allow an editor to modify
spaces to tabs, as they may be important in the test. this
circumstance is more unusual, and can possibly be limited to specific
test files (t/compilers/pge in particular.)
oh, one more small nit: the coda you specified did not match the
indentation of the coda in pdd07. again, i'm not an emacs user, so i
don't know if this has any effect (probably not) but i'd hate to apply
it and have to apply a fix later.
this can be resolved (and the patch applied) if the minor nits are
fixed, and i'm told that the emacs coda does not limit the line
length, or the line length part of the coda is removed, or chip tells
me to stuff it and make the test files conform to the standard. as for
space/tab issues, we can deal with them on a file-by-file basis.
oh, and yes, i believe the shebang should be in all perl files... but
this isn't specified *yet* in pdd07. if you can enter the ticket, that
would be fantastic, and we'll get a ruling from chip.
~jerry
Paul Cochrane
> firstly, line endings are unrelated to this effort and should be a
> separate patch. that's no biggie, and alone wouldn't stop me from
> applying.
I can do that in a separate patch if you want. That's not a major
problem, and probably a good idea.
<snip - tests and coda>
I'd not realised some of the issues you brought up (e.g. extra long
lines, tabs etc.) and I would say it would be a good idea not to apply
the patch. I've noticed that I should have added the coda to the .pm
files as well, so it's definitely a good idea not to apply the patch.
I've got a couple of questions concerning perl files in the parrot
source tree: It's obvious that .pl and .pm files are perl, however,
some of the .t files are perl and some are parrot. Is there an easy
way to make a distinction between .t files as to what is actually
running the test? One could test for the perl shebang line, however,
since that's not in there in all the files necessarily one can't use
that (also it might be a good idea to make a test for the shebang line
in perl .t files anyway, so one can't really have another test relying
on the shebang line). So, how in general can one decide if a file
is perl? It is easy to check for c files and headers (this is done in
Parrot::Distribution, which the code_coda.t test is based on, and
which I'm trying to see how to extend to perl) via the file's
extension, but one can't do this for perl beyond .pl and .pm (have I
missed any others?). Should one have a list of directories which are
just perl files? This would seem too restrictive to me as then
parrot-run tests and perl-run tests couldn't reside in the same
directory. Can one have a mime type of some description and then let
svn work it out? I'm not sure how to achieve this in general. Any
ideas of a good solution to extend Parrot::Distribution and therefore
code_coda.t?
> oh, and yes, i believe the shebang should be in all perl files... but
> this isn't specified *yet* in pdd07. if you can enter the ticket, that
> would be fantastic, and we'll get a ruling from chip.
Ok, I'll add a ticket (it'll give me good experience with RT :-) ).
Thanks heaps for your feedback!
Regards,
Paul
Jerry Gay
> > firstly, line endings are unrelated to this effort and should be a
> > separate patch. that's no biggie, and alone wouldn't stop me from
> > applying.
> I can do that in a separate patch if you want. That's not a major
> problem, and probably a good idea.
>
> <snip - tests and coda>
> I'd not realised some of the issues you brought up (e.g. extra long
> lines, tabs etc.) and I would say it would be a good idea not to apply
> the patch. I've noticed that I should have added the coda to the .pm
> files as well, so it's definitely a good idea not to apply the patch.
>
ok, glad you agree :)
> I've got a couple of questions concerning perl files in the parrot
> source tree: It's obvious that .pl and .pm files are perl, however,
> some of the .t files are perl and some are parrot. Is there an easy
> way to make a distinction between .t files as to what is actually
> running the test? One could test for the perl shebang line, however,
> since that's not in there in all the files necessarily one can't use
> that (also it might be a good idea to make a test for the shebang line
> in perl .t files anyway, so one can't really have another test relying
> on the shebang line). So, how in general can one decide if a file
> is perl? It is easy to check for c files and headers (this is done in
> Parrot::Distribution, which the code_coda.t test is based on, and
> which I'm trying to see how to extend to perl) via the file's
> extension, but one can't do this for perl beyond .pl and .pm (have I
> missed any others?). Should one have a list of directories which are
> just perl files? This would seem too restrictive to me as then
> parrot-run tests and perl-run tests couldn't reside in the same
> directory. Can one have a mime type of some description and then let
> svn work it out? I'm not sure how to achieve this in general. Any
> ideas of a good solution to extend Parrot::Distribution and therefore
> code_coda.t?
>
i suggest that all .t files must have a shebang line. this is how
parrot's test engine determines what program should be used to run the
tests. on unix, the shell reads the shebang, and on windows, perl
reads the shebang, and calls the appropriate program. therefore, in
order to work correctly:
~ all non-perl test files must have a shebang
i strongly suggest that this be extended to cover all test files.
then, as you say, it can easily be tested, and it's value can be used
in other tests to determine it's file type. if you wish to submit a
patch to implement this (and one to test it would be wonderful too,)
i'll happily apply, and we'll patch up pdd07 real soon now.
> > oh, and yes, i believe the shebang should be in all perl files... but
> > this isn't specified *yet* in pdd07. if you can enter the ticket, that
> > would be fantastic, and we'll get a ruling from chip.
> Ok, I'll add a ticket (it'll give me good experience with RT :-) ).
>
yay!
> Thanks heaps for your feedback!
>
anytime, paul. thanks so much for keeping our bird clean.
~jerry
Paul Cochrane
> oh, and yes, i believe the shebang should be in all perl files... but
> this isn't specified *yet* in pdd07. if you can enter the ticket, that
> would be fantastic, and we'll get a ruling from chip.
This is going to sound rather silly, but... how does one enter a new
ticket to RT? I've got an account, but can't see anywhere on
rt.perl.org where one can add a new ticket. There's also no help link
I can go to to work out what to do. Should I use parrotbug to do
this? I'm not sure, so thought it best to ask.
Thanks heaps in advance,
Paul
Jerry Gay
> ticket to RT? I've got an account, but can't see anywhere on
> rt.perl.org where one can add a new ticket. There's also no help link
> I can go to to work out what to do. Should I use parrotbug to do
> this? I'm not sure, so thought it best to ask.
>
it's what we've got :-)
~jerry
Paul Cochrane
> all new rt tickets are created via parrotbug. it may not be sexy, but
> it's what we've got :-)
I'm not 100% sure if it worked, as parrotbug gave this warning:
Use of uninitialized value in concatenation (.) or string at
./parrotbug line 525, <STDIN> line 7.
and the ticket doesn't seem to have appeared on RT (could be a time
delay though). Also, I might be restricted sending email from my
machine directly on our network, so it might not get through at all.
You might have to add the ticket for me!
Anyway, thanks for your help!
Regards,
Paul
Jerry Gay
you meant 'parr...@perl.org', which is where you send mail to if you
want to create a ticket. i do see a new ticket for line endings in rt
(http://rt.perl.org/rt3/Ticket/Display.html?id=40364) so i think it
succeeded. it does take some time for rt to get around to letting the
list know something's changed there, so the lack of email is probably
just a delay.
~jerry
Chromatic
> ~ all non-perl test files must have a shebang
>
> i strongly suggest that this be extended to cover all test files.
> then, as you say, it can easily be tested, and it's value can be used
> in other tests to determine it's file type. if you wish to submit a
> patch to implement this (and one to test it would be wonderful too,)
> i'll happily apply, and we'll patch up pdd07 real soon now.
This could be a bit tricky for the Pheme tests. This is not an objection
(it's a good idea), just an admission that I'm not sure what to use as the
shebang line there.
-- c
Will Coleda via RT
For the purposes of this discussion anything that doesn't have "perl" in it is fine for now. For
what it's worth, partcl is using:
#!../../parrot tcl.pbc
Paul Cochrane via RT
The attached patch to the coding standards pdd concerns how we handle
the parrot emacs/vim coda in perl source files when the files contain
__END__ or __DATA__ blocks. The reason for the patch is that vim looks
at only the first or last five lines of a file to see if there is any
style/settings information. If the exception to the coding standard is
accepted, I'll apply this patch, and update the
CodeLayout::UseParrotCoda policy to match.
Comments most definitely welcome,
Paul
Paul Cochrane via RT
We could close this ticket if a decision were made as to whether or not
the emacs/vim formatting information can be put at the *beginning* of a
file in the case where __END__ or __DATA__ blocks are used within a
perl source file.
What are people's opinions? Would it be too ugly to put the "coda" at
the beginning of the file just after the shebang line?
Paul
Chris Dolan
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes.
See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
for more details:
http://search.cpan.org/~cdolan/Perl-Critic-More-0.12/lib/Perl/Critic/
Policy/Editor/RequireEmacsFileVariables.pm
Chris
--
Chris Dolan, Software Developer, http://www.chrisdolan.net/
Public key: http://www.chrisdolan.net/public.key
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Bob Rogers
Date: Sun, 17 Dec 2006 13:22:53 -0600
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote:
> Hi all,
>
> We could close this ticket if a decision were made as to whether or
> not
> the emacs/vim formatting information can be put at the *beginning*
> of a
> file in the case where __END__ or __DATA__ blocks are used within a
> perl source file.
>
> What are people's opinions? Would it be too ugly to put the "coda" at
> the beginning of the file just after the shebang line?
>
> Paul
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes
. . .
That will still be true for Emacs 22, BTW. However, this wouldn't be
hard to hack around in a cperl-mode hook function. Since we already
insist that people load editor/parrot.el for editing C code, this would
amount to zero additional burden on Parrot hackers. And in that case,
we could put the "Local Variables:" section anywhere we like, so we
might as well keep it at the end of the code, just before any __END__ or
__DATA__ blocks.
I think I would like to write this anyway; it would be a useful
addition to cperl-mode. But in that case, we would also need a
customized Perl::Critic::Policy::Editor::RequireEmacsFileVariables
policy. WDOT?
-- Bob Rogers
http://rgrjr.dyndns.org/
Bob Rogers
Date: Sun, 17 Dec 2006 15:03:10 -0500
From: Chris Dolan <ch...@chrisdolan.net>
Date: Sun, 17 Dec 2006 13:22:53 -0600
. . .
Be aware that you cannot use the verbose form of Emacs settings at
the beginning of a file, unless the file is shorter than 3000 bytes
. . .
That will still be true for Emacs 22, BTW. However, this wouldn't be
hard to hack around in a cperl-mode hook function . . .
Here it is, plus a bonus of auto-mode-alist hackery. Comments?
-- Bob
Paul Cochrane
> the beginning of a file, unless the file is shorter than 3000 bytes.
> See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
> for more details:
So this means we need to put the emacs and vim settings at the end of
the file. Vim sets a similar restriction in that its settings should
be in the first or last 5 lines. The problem that I'm trying to solve
here is: how do we add the settings information to perl language files
such that it doesn't cause problems with __END__ and __DATA__ blocks,
is testable by perlcritic, emacs *and* vim pick up their settings
values, and it doesn't interfere with the visual structure of the
file. I've hit a bit of a brick wall in trying to satisfy all these
conditions; any ideas as to how we can achieve this?
Many thanks in advance,
Paul
Chris Dolan
>> Be aware that you cannot use the verbose form of Emacs settings at
>> the beginning of a file, unless the file is shorter than 3000 bytes.
>> See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy
>> for more details:
>
> So this means we need to put the emacs and vim settings at the end of
> the file.
No, it means that if you want to use the verbose form of Emacs file
variables, then it has to be at the end of the file.
> Vim sets a similar restriction in that its settings should
> be in the first or last 5 lines. The problem that I'm trying to solve
> here is: how do we add the settings information to perl language files
> such that it doesn't cause problems with __END__ and __DATA__ blocks,
> is testable by perlcritic, emacs *and* vim pick up their settings
> values, and it doesn't interfere with the visual structure of the
> file. I've hit a bit of a brick wall in trying to satisfy all these
> conditions; any ideas as to how we can achieve this?
Not really... The only elegany approach is:
# -*- parrot -*-
and insist that parrot-mode.el be installed. That may annoy some
people, but I don't see another way without crufting up the top of
the file or requiring that you de-cruft <DATA> everywhere.
Allison Randal
> The problem that I'm trying to solve
> here is: how do we add the settings information to perl language files
> such that it doesn't cause problems with __END__ and __DATA__ blocks,
> is testable by perlcritic, emacs *and* vim pick up their settings
> values, and it doesn't interfere with the visual structure of the
> file. I've hit a bit of a brick wall in trying to satisfy all these
> conditions; any ideas as to how we can achieve this?
My vote is on removing all emacs and vim settings from our source code
files.
Allison
Lee Duhem
> files.
Patrick R. Michaud
I'm curious, why is that? We're already discouraging (if not
disallowing) hard tabs in the Parrot source tree -- are there
other items that make the code appear "really bad"?
I totally agree with Allison -- let's get rid of the editor-specific
settings in the source code files.
Pm
Paul Cochrane
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The coda is added to all C-language files; the problem is only with
Perl-language files with __END__ and __DATA__ blocks. Why don't we
just let them be an exception which doesn't require such editor hints?
Just my $0.02
Paul
Allison Randal
> Having editor hints in the source can have value as it can reduce the
> cage cleaning load by getting the editor to indent people's code
> consistently (admittedly this only helps people who use emacs and vim
> in this case) so in that sense it is worthwhile having them around.
> The coda is added to all C-language files; the problem is only with
> Perl-language files with __END__ and __DATA__ blocks.
The editor hints aren't actually very helpful, but they do add clutter
to every source file, and a maintenance burden. Both vim and emacs allow
top-level settings of these preferences, which is a more appropriate
place for them.
The coding standards tests need to check the format of the source code
files directly anyway (for developers who don't use vim or emacs).
> Why don't we
> just let them be an exception which doesn't require such editor hints?
It's best to be consistent. If every file has the hints, people rely on
them. If none of them do, people know they have to define top-level
preferences. Anything in between is messy.
Allison
Chromatic
> The editor hints aren't actually very helpful, but they do add clutter
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
I agree; I use Vim and these hints have never prevented me from checking in
literal tabs.
I can see adding the coda to *generated* files, in an attempt to make them
read-only, however.
-- c
Nicholas Clark
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
This assumes that all the projects you use the editor for have the same
standard. (assuming that you're meaning to set the defaults for C and Perl
formatting modes, rather than to use custom parrot-mode variants)
Nicholas Clark
Allison Randal
All it does is turn on cperl mode for emacs, and set tabs to 4 spaces
for vim and emacs. Not likely to significantly interfere with any
repository you work on. (I actually gave up on the tab key in vim years
ago. I type literal spaces, and my brain automatically adjusts my
indenting to the surrounding code. I don't even think about it anymore.)
If either emacs or vim were smarter about options, you could have a
single preferences file in the top-level of the parrot repository and it
would cover all the subdirectories. (Vim offers one .vimrc per
directory, but it doesn't recurse into subdirectories. I don't know
about emacs.)
I do like Chris's parrot-mode solution better than including the literal
option commands in every file. It at least reduces the clutter and
maintenance headaches.
Allison
Nicholas Clark
> Nicholas Clark wrote:
> >On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> >
> >>to every source file, and a maintenance burden. Both vim and emacs allow
> >>top-level settings of these preferences, which is a more appropriate
> >>place for them.
> >
> >This assumes that all the projects you use the editor for have the same
> >standard. (assuming that you're meaning to set the defaults for C and Perl
> >formatting modes, rather than to use custom parrot-mode variants)
>
> All it does is turn on cperl mode for emacs, and set tabs to 4 spaces
> for vim and emacs. Not likely to significantly interfere with any
> repository you work on. (I actually gave up on the tab key in vim years
To seek clarification - having those as global settings for cperl isn't
likely to be an issue? Or having them in editor blocks?
> I do like Chris's parrot-mode solution better than including the literal
> option commands in every file. It at least reduces the clutter and
> maintenance headaches.
This seems good. emacs (or at least one version) quietly warns that it's
ignoring the unknown mode, then carries on as if the mode line wasn't there.
Nicholas Clark
Allison Randal
>
> To seek clarification - having those as global settings for cperl isn't
> likely to be an issue? Or having them in editor blocks?
I meant globally.
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl files with
__END__ or __DATA__ blocks.
Mark it as a cage cleaner task for some point down the road: figure out
how to encourage good formatting habits, without assuming that everyone
uses emacs or vim, and with minimal clutter in our source code.
Allison
Lee Duhem
> for vim and emacs. Not likely to significantly interfere with any
> repository you work on. (I actually gave up on the tab key in vim years
> ago. I type literal spaces, and my brain automatically adjusts my
> indenting to the surrounding code. I don't even think about it anymore.)
>
> If either emacs or vim were smarter about options, you could have a
> single preferences file in the top-level of the parrot repository and it
> would cover all the subdirectories. (Vim offers one .vimrc per
> directory, but it doesn't recurse into subdirectories. I don't know
> about emacs.)
>
> I do like Chris's parrot-mode solution better than including the literal
> option commands in every file. It at least reduces the clutter and
> maintenance headaches.
editor option commands in *many* source files. And not everyone use Vim
or Emacs, so good code standard test is essential.
Paul Cochrane
> just make an exception and leave the hints out of Perl files with
> __END__ or __DATA__ blocks.
> Mark it as a cage cleaner task for some point down the road: figure out
> how to encourage good formatting habits, without assuming that everyone
> uses emacs or vim, and with minimal clutter in our source code.
This is a good idea. Some kind of repository-wide hints thingy would
be great, but if we can't do that now it's not a big problem.
Apologies about the amount of dust this topic threw up - I just wanted
to close the ticket for bug day. :-/ Nevertheless, thanks everyone
for their comments, it seems it wasn't such a simple problem to solve
after all.
Regards,
Paul
Nicholas Clark
> Nicholas Clark wrote:
> >
> >To seek clarification - having those as global settings for cperl isn't
> >likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
Ah. There have been times when it would have been "fun". For instance at
Fotango, I was editing perl 5 source (hard tabs, 1 sort of indenting)
parrot source (spaces, different) and Fotango's own source (different again)
in the same editor. Richard helpfully made a custom hook for cperl mode that
enforced that Fotango standard, but using this really messed the perl 5 source
so I had to disable it.
> It's really not a big deal, though. For the immediate problem, let's
> just make an exception and leave the hints out of Perl files with
> __END__ or __DATA__ blocks.
>
> Mark it as a cage cleaner task for some point down the road: figure out
> how to encourage good formatting habits, without assuming that everyone
> uses emacs or vim, and with minimal clutter in our source code.
Is PerlTidy trustworthy enough to run as a pre-commit hook?
One thing we have found in perl 5 is that adding editor blocks saying "read
only" in generated files tends to act as a good reminder to people not to
edit them; far more effective than a comment at the top, if you've jumped
straight to a line in the middle following a compiler error.
Nicholas Clark
Paul Cochrane via RT
> Nicholas Clark wrote:
> >
> > To seek clarification - having those as global settings for cperl
isn't
> > likely to be an issue? Or having them in editor blocks?
>
> I meant globally.
>
> It's really not a big deal, though. For the immediate problem, let's
> just make an exception and leave the hints out of Perl files with
> __END__ or __DATA__ blocks.
Added a note about this in pdd07.
> Mark it as a cage cleaner task for some point down the road: figure
out
> how to encourage good formatting habits, without assuming that
everyone
> uses emacs or vim, and with minimal clutter in our source code.
A CAGE ticket has been generated in RT for this.
Is it ok to close the current ticket now?
Paul