1 |
On Wed, 04 Jun 2008 15:31:58 -0600 |
2 |
Joe Peterson <lavajoe@g.o> wrote: |
3 |
|
4 |
> William L. Thomson Jr. wrote: |
5 |
> > Just a quick thought looking over a couple ebuilds. It seems most |
6 |
> > times anyone does a error, elog, einfo, or similar. They start and |
7 |
> > end with a few blank lines. Calls with no arguments. |
8 |
> > |
9 |
> > Is there any reason not to make that a default? Other than |
10 |
> > difficulty of implementation. Anytime they are invoked back to |
11 |
> > back. Default blank lines are added at the beginning or end. |
12 |
> |
13 |
> I have run into the same dilemma - wanting to separate blocks of |
14 |
> warnings/logs/info by blank space. And the particular issue I've run |
15 |
> into is which calls to use (i.e. what color to make the "*"). For |
16 |
> example, I might have two possible warnings back-to-back, and each is |
17 |
> conditional: |
18 |
> |
19 |
> if ! use flac; then |
20 |
> ewarn "'flac' USE flag is not set. Blah, blah..." |
21 |
> ewarn "More blah blah..." |
22 |
> ewarn "" |
23 |
> fi |
24 |
> if ! use lame; then |
25 |
> ewarn "'lame' USE flag is not set. Blah, blah..." |
26 |
> ewarn "More blah blah..." |
27 |
> ewarn "" |
28 |
> fi |
29 |
> |
30 |
> Problem is, the blank line doesn't really belong in the "warning" |
31 |
> itself |
32 |
> - it's meant as a separator. And if both happen, it makes sense to |
33 |
> color the "*" logically (should it be yellow rather than, say, green? |
34 |
> If the next block of output is "green", it can look funny to see a |
35 |
> blank yellow as the separator, for example. |
36 |
> |
37 |
> Also, there is that question of whether to put the blank line before |
38 |
> or after the block, and if conditional, it can be tricky to make the |
39 |
> full output look nice for all possibilities. I tend not to want to |
40 |
> put a blank line at the very end of the output (trying to be |
41 |
> consistent with most other ebuilds), even though that might make |
42 |
> things more clear. Also, I don't know inside the conditional whether |
43 |
> it might be the last block of output or of another conditional might |
44 |
> follow (for example). |
45 |
> |
46 |
> So I am in favor of some smart code in portage to do "nice looking" |
47 |
> blank line logic that would also make reading the output more clear. |
48 |
> Something like "eblank" or "eseparator" could be aware of the previous |
49 |
> and next "color" and do the right thing. Putting a blank line |
50 |
> consistently at the end of the ebuild output but before portage's end |
51 |
> summary would be nice as well (and make it easier to spot problems |
52 |
> when looking at the output). Also, if the ebuild itself tries to |
53 |
> insert blanks at the start or end, portage could remove those and |
54 |
> enforce its own spacing rules... |
55 |
|
56 |
I just throw a couple echos around any output. |
57 |
|
58 |
echo |
59 |
elog "Your shoe is untied." |
60 |
elog |
61 |
elog "Please run this command again when your footwear is properly" |
62 |
elog "secured." |
63 |
echo |
64 |
|
65 |
I think doing any kind of automatic pretty-print formatting is |
66 |
overkill, but that's just my opinion. |
67 |
|
68 |
|
69 |
-- |
70 |
fonts, gcc-porting, by design, by neglect |
71 |
mips, treecleaner, for a fact or just for effect |
72 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |