William L. Thomson Jr. wrote:
> Just a quick thought looking over a couple ebuilds. It seems most times
> anyone does a error, elog, einfo, or similar. They start and end with a
> few blank lines. Calls with no arguments.
> 
> Is there any reason not to make that a default? Other than difficulty of
> implementation. Anytime they are invoked back to back. Default blank
> lines are added at the beginning or end.

I have run into the same dilemma - wanting to separate blocks of
warnings/logs/info by blank space.  And the particular issue I've run
into is which calls to use (i.e. what color to make the "*").  For
example, I might have two possible warnings back-to-back, and each is
conditional:

if ! use flac; then
        ewarn "'flac' USE flag is not set.  Blah, blah..."
        ewarn "More blah blah..."
        ewarn ""
fi
if ! use lame; then
        ewarn "'lame' USE flag is not set.  Blah, blah..."
        ewarn "More blah blah..."
        ewarn ""
fi

Problem is, the blank line doesn't really belong in the "warning" itself
- it's meant as a separator.  And if both happen, it makes sense to
color the "*" logically (should it be yellow rather than, say, green?
If the next block of output is "green", it can look funny to see a blank
yellow as the separator, for example.

Also, there is that question of whether to put the blank line before or
after the block, and if conditional, it can be tricky to make the full
output look nice for all possibilities.  I tend not to want to put a
blank line at the very end of the output (trying to be consistent with
most other ebuilds), even though that might make things more clear.
Also, I don't know inside the conditional whether it might be the last
block of output or of another conditional might follow (for example).

So I am in favor of some smart code in portage to do "nice looking"
blank line logic that would also make reading the output more clear.
Something like "eblank" or "eseparator" could be aware of the previous
and next "color" and do the right thing.  Putting a blank line
consistently at the end of the ebuild output but before portage's end
summary would be nice as well (and make it easier to spot problems when
looking at the output).  Also, if the ebuild itself tries to insert
blanks at the start or end, portage could remove those and enforce its
own spacing rules...

                                        -Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Reply via email to