On Sun, Sep 17, 2017 at 09:31:14PM +0200, Benedikt Morbach wrote:
> Hi,
>
> On Thu, Sep 14, 2017 at 6:09 PM, Bo Ørsted Andresen <[email protected]> wrote:
> > Hello,
> >
> > Couple years ago support for descriptions for alternatives was introduced.
> > E.g.:
> >
> > ALTERNATIVES_cc_DESCRIPTION="System-wide C compiler"
> > ALTERNATIVES_vi_DESCRIPTION="Default provider for the vi text editor"
> >
> > in the bottom of alternatives.exlib. More alternatives need to start using
> > this
> > but it's a start. If you run `eclectic` these descriptions are shown. If you
> > run `eclectic vi help` the vi alternative description is also shown.
> >
> > If you run `eclectic vi` it is, however, not shown. That's dumb. Attached in
> > 0001-Show-description-by-default-in-eclectic-alternative-.patch for ::arbor
> > is
> > a solution to that. The normal default action is usage. Help prints the
> > description and then usage. So seems okay.
>
> Agreed.
> Additionally I would change the formatting a bit because I for one would
> never have seen that description in this:
>
> Default provider for the vi text editor
> Usage: eclectic vi <action> <options>
>
> At least a newline before the "Usage:..." bit, maybe some color or
> underline as well?
>
> But we can bikeshed that separately afterwards.
If someone else writes the patch. ;)
> > been discussed. Attached in
> > 0001-Show-contents-of-_description-file-if-it-exists-in-e.patch for
> > ::eclectic
> > and 0002-Add-alternatives_for_with_description-which-allows-s.patch for
> > ::arbor
> > is a way to show provider descriptions in `eclectic ${alternative} list`
> > output.
>
> That seems sensible. Though I'd make the first loop start at 0 as well and do
> $((n+1)) for the list index instead of n-1 everywhere else, if only to
> be consistent
> with the second loop
Alright, done.
> > To specify provider description has been added a new
> > `alternatives_for_with_descriptions` function which takes a fourth
> > description
> > argument and puts it in
> > /etc/env.d/alternatives/${alternative}/${provider}/_description similar to
> > how
> > importance is stored.
> >
> > Does anybody have suggestions for a better name for
> > `alternatives_for_with_description`? Comments?
>
> I'd just add another argument to alternatives_for. It can/should be empty for
> many things, like python3 versions, but it would be more consistent and more
> people would know that it exists, compared to a rarely used
> _with_description version.
I'd like to get more comments on whether to break stuff to get wider adoption
or make it opt in at the risk of noone using it.. ;)
--
Bo Ørsted Andresen
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
