1 |
William L. Thomson Jr. wrote: |
2 |
> Just a quick thought looking over a couple ebuilds. It seems most times |
3 |
> anyone does a error, elog, einfo, or similar. They start and end with a |
4 |
> few blank lines. Calls with no arguments. |
5 |
> |
6 |
> Is there any reason not to make that a default? Other than difficulty of |
7 |
> implementation. Anytime they are invoked back to back. Default blank |
8 |
> lines are added at the beginning or end. |
9 |
|
10 |
I have run into the same dilemma - wanting to separate blocks of |
11 |
warnings/logs/info by blank space. And the particular issue I've run |
12 |
into is which calls to use (i.e. what color to make the "*"). For |
13 |
example, I might have two possible warnings back-to-back, and each is |
14 |
conditional: |
15 |
|
16 |
if ! use flac; then |
17 |
ewarn "'flac' USE flag is not set. Blah, blah..." |
18 |
ewarn "More blah blah..." |
19 |
ewarn "" |
20 |
fi |
21 |
if ! use lame; then |
22 |
ewarn "'lame' USE flag is not set. Blah, blah..." |
23 |
ewarn "More blah blah..." |
24 |
ewarn "" |
25 |
fi |
26 |
|
27 |
Problem is, the blank line doesn't really belong in the "warning" itself |
28 |
- it's meant as a separator. And if both happen, it makes sense to |
29 |
color the "*" logically (should it be yellow rather than, say, green? |
30 |
If the next block of output is "green", it can look funny to see a blank |
31 |
yellow as the separator, for example. |
32 |
|
33 |
Also, there is that question of whether to put the blank line before or |
34 |
after the block, and if conditional, it can be tricky to make the full |
35 |
output look nice for all possibilities. I tend not to want to put a |
36 |
blank line at the very end of the output (trying to be consistent with |
37 |
most other ebuilds), even though that might make things more clear. |
38 |
Also, I don't know inside the conditional whether it might be the last |
39 |
block of output or of another conditional might follow (for example). |
40 |
|
41 |
So I am in favor of some smart code in portage to do "nice looking" |
42 |
blank line logic that would also make reading the output more clear. |
43 |
Something like "eblank" or "eseparator" could be aware of the previous |
44 |
and next "color" and do the right thing. Putting a blank line |
45 |
consistently at the end of the ebuild output but before portage's end |
46 |
summary would be nice as well (and make it easier to spot problems when |
47 |
looking at the output). Also, if the ebuild itself tries to insert |
48 |
blanks at the start or end, portage could remove those and enforce its |
49 |
own spacing rules... |
50 |
|
51 |
-Joe |
52 |
-- |
53 |
gentoo-dev@l.g.o mailing list |