1 |
On 7/23/06, John Jawed <johnjawed@×××××.com> wrote: |
2 |
> Nice work on this, it's looking good now. Is there a reason the |
3 |
> leading asterisk was dropped? Having it there might be good for |
4 |
> readability as well as keeping in line with the "look here" (einfo, |
5 |
> eerror, ewarn, etc) motif in portage. |
6 |
|
7 |
I was indeed attempting to keep with the established look and feel of |
8 |
Portage tools here, and in this case the appearance of the "emerge -a" |
9 |
prompt seemed a more appropriate model than the appearance of the |
10 |
non-interactive einfo(), ewarn(), and eerror() messages. The reason |
11 |
the latter are prefixed with colored asterisks is because they're |
12 |
non-interactive and need some way to catch the user's eye amidst other |
13 |
messages flying by in the terminal. |
14 |
|
15 |
In contrast, an interactive prompt such as "emerge -a" doesn't really |
16 |
need to stand out in the same way because it's going to sit there in |
17 |
the user's face until it receives input. |
18 |
|
19 |
I did make the prompt text bold to be consistent with the look of |
20 |
"emerge -a", and this consistency is what we should go for IMO because |
21 |
the only time users are likely to run into einput.eclass's prompts is |
22 |
when it's being called from an ebuild running in an "emerge" session. |
23 |
I feel it's quite arguable which style looks better (bolded or |
24 |
asterisked), and if it's decided to go with fuchsia asterisks for |
25 |
einput's prompts after all, emerge's prompts should also be changed to |
26 |
maintain consistency. |
27 |
-- |
28 |
gentoo-dev@g.o mailing list |