Sometimes people wrap long lines in their ebuilds to make it easier to
read, but this causes us issues when doing line-by-line checking. So
automatically unroll those lines before passing the full content down
to our checkers.

This seems to work, but maybe someone can suggest something simpler.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
pym/repoman/checks.py | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 65e7136..67f2b0a 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -750,11 +750,46 @@ _ignore_comment_re = re.compile(r'^s*#')
def run_checks(contents, pkg):
checks = _constant_checks
here_doc_delim = None
+ multiline = None

for lc in checks:
lc.new(pkg)
for num, line in enumerate(contents):

+ # Unroll multiline escaped strings so that we can check things:
+ # inherit foo bar
+ # moo
+ # cow
+ # This will merge these lines like so:
+ # inherit foo bar moo cow
+ try:
+ # A normal line will end in the two bytes: <> <
>. So decoding
+ # that will result in python thinking the <
> is being escaped
+ # and eat the single <> which makes it hard for us to detect.
+ # Instead, strip the newline (which we know all lines have), and
+ # append a <0>. Then when python escapes it, if the line ended
+ # in a <>, we'll end up with a <> marker to key off of. This
+ # shouldn't be a problem with any valid ebuild ...
+ line_escaped = (line.rstrip('
') + '0').decode('string_escape')
+ except:
+ # Who knows what kind of crazy crap an ebuild will have
+ # in it -- don't allow it to kill us.
+ line_escaped = line
+ if multiline:
+ # Chop off the and
bytes from the previous line.
+ multiline = multiline[:-2] + line
+ if not line_escaped.endswith(''):
+ line = multiline
+ num = multinum
+ multiline = None
+ else:
+ continue
+ else:
+ if line_escaped.endswith(''):
+ multinum = num
+ multiline = line
+ continue
+
# Check if we're inside a here-document.
if here_doc_delim is not None:
if here_doc_delim.match(line):
--
1.7.8.6

On 05/23/2012 09:06 PM, Mike Frysinger wrote:
> Sometimes people wrap long lines in their ebuilds to make it easier to
> read, but this causes us issues when doing line-by-line checking. So
> automatically unroll those lines before passing the full content down
> to our checkers.
>
> This seems to work, but maybe someone can suggest something simpler.

This code should come right after the line that says "We're not in a
here-document", because we only need it to trigger when we're not in a
here-document.

I think it's going to be cleaner to detect an escaped newline with a
regular expression, like r'(^|[^])$'.
--
Thanks,
Zac

On 24 May 2012 16:06, Mike Frysinger <vapier@gentoo.org> wrote:
> Sometimes people wrap long lines in their ebuilds to make it easier to
> read, but this causes us issues when doing line-by-line checking. *So
> automatically unroll those lines before passing the full content down
> to our checkers.
>


This may be a result of the default vim settings that get enabled if
you're editing an ebuild.

If you don't manually wrap the lines, vim will do it for you, because
the ebuild profile for vim ( app-vim/gentoo-syntax ,
/usr/share/vim/vimfiles/ftplugin/ebuild.vim ) sets textwidth=80

This in my personal experience is unhelpful, and every time the text
wrap fires it risks producing broken code, and I've resorted to
manually wrapping things with the proper escapes just to avoid being
attacked by the wrap.

( I had assumed that the forced 80 char text width was something that
was enforced by policy and wasn't game to try bucking the curve )

If there is no such policy, and a forced text-wrap at 80 characters is
not needed, I would love for that setting to be removed.



--
Kent

perl -e* "print substr( "edrgmaM* SPA NOcomil.ic@tfrken", $_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

On Thursday 24 May 2012 06:27:36 Kent Fredric wrote:
> ( I had assumed that the forced 80 char text width was something that
> was enforced by policy and wasn't game to try bucking the curve )
>
> If there is no such policy, and a forced text-wrap at 80 characters is
> not needed, I would love for that setting to be removed.

there is no policy dictating line length. but certainly lines that are 200+
chars should get wrapped ...

as for changing the vim settings, you'll have to file a request with the vim
maintainer.
-mike