-M options

-M options

[Zefram]

About a year ago, we discussed the possibility of several builtins
having the capability to display the state of things in the form of
commands to set up that state.  I believe the consensus was
favourable.  A couple of builtins, compctl and alias, now have that
capability, in the form of their -L options.  -L can't be used for all
the builtins, because it already has a different meaning to typeset, so
I suggested that we use -M instead.

What does everyone now think of this idea?  I personally like it -- I
use compctl -L quite a lot.  Can anyone think of a better option letter
to use?  I'd like to know people's opinions on this matter.

A while ago I posted patches to implement this option in several
builtins, but most of them didn't get into the baseline.  Richard,
could you say why you didn't use them?  Was it simply a matter of
avoiding adding new features, in preparation for the 3.0 release?

Zoltan, would you add this feature to the baseline, if I were to post
updated patches?  (Some of the patches I posted will no longer apply,
due to metafication changes.)

-zefram

Re: -M options

[Zoltan Hidvegi]

> Zoltan, would you add this feature to the baseline, if I were to post
> updated patches?  (Some of the patches I posted will no longer apply,
> due to metafication changes.)

I'd like to add these, and I have all of these letters saved.  I just do
not like -M since it is not intuitive enough.  ksh uses -p which seems to
be much better but it clashes with many other builtin option.  I did not
add these mainly because of this.

Zoltan

Re: -M options

[Zefram]

>I'd like to add these, and I have all of these letters saved.  I just do
>not like -M since it is not intuitive enough.  ksh uses -p which seems to
>be much better but it clashes with many other builtin option.  I did not
>add these mainly because of this.

I rationalised that -M could refer to coMMands.  It would also mean
that the two options meaning the same thing to several builtins would
be -m and -M, which makes it a little easier to remember.

-L (for List, I suppose) would be my first choice, if it were not for
the clash in typeset.  Maybe we could leave typeset as an exception,
though it is a rather large exception.

I don't see any better candidates than these two, unless we want to use
a digit (though that would also cause some confusion with typeset) or a
punctuation character.

-zefram

Re: -M options

[Goran Larsson]

----------ONLY HEADERS ABOVE THIS LINE------------

> I rationalised that -M could refer to coMMands.  It would also mean
> that the two options meaning the same thing to several builtins would
> be -m and -M, which makes it a little easier to remember.

Why does it have to be an option to all these commands? Why not
a make the command name an argument to another command, i.e.

  xxxx typeset

(where xxxx is a new command) or even better

  print -L typeset

instead of

  typeset -M

-- 
 Goran Larsson              Phone: +46 13 299588  FAX: +46 13 299022
 Approve AB                        +46 589 12810       +46 589 16901
 hoh@approve.se
           I was an atheist, until I found out I was God.

Re: -M options

[Richard Coleman]

> About a year ago, we discussed the possibility of several builtins
> having the capability to display the state of things in the form of
> commands to set up that state.  I believe the consensus was
> favourable.  A couple of builtins, compctl and alias, now have that
> capability, in the form of their -L options.  -L can't be used for all
> the builtins, because it already has a different meaning to typeset, so
> I suggested that we use -M instead.
> 
> What does everyone now think of this idea?  I personally like it -- I
> use compctl -L quite a lot.  Can anyone think of a better option letter
> to use?  I'd like to know people's opinions on this matter.
> 
> A while ago I posted patches to implement this option in several
> builtins, but most of them didn't get into the baseline.  Richard,
> could you say why you didn't use them?  Was it simply a matter of
> avoiding adding new features, in preparation for the 3.0 release?
> 
> Zoltan, would you add this feature to the baseline, if I were to post
> updated patches?  (Some of the patches I posted will no longer apply,
> due to metafication changes.)

There was nothing wrong with the patches.  I was just avoiding
adding new features.

rc