>>>>> "AM" == Alan Millar <email@example.com> writes:
AM> Actually, "which" was probably a bad example for me to pick in that
Not really. It makes sense to question what proper behavior is in this
AM> I like this idea much better than overloading multiple arguments to
AM> approve. Although by having a separate "listname" command like this,
AM> we could still use the word "approve" for the first one. As long as we
AM> make sure we don't overload it; like you say we'll need to think it
As someone else pointed out, the intelligent thing to do is come up with a
keyword to use to set command parser state variables like this. Hence I've
used "default", giving rise to "default password blah" and "default
AM> I don't think I proposed the comma separated options, but I can't
AM> recall who did.
That was me.
AM> We should think that one through also, because we don't have any other
AM> places in MJ syntax where we do that.
Well, the problem is that nowhere else to we specify any kind of property
list, or give two types of arguments to a command. (Unless you count
"subscribe list address", and look at the potential trouble we get into
because list is optional.) I think we have to do something like a
delimiter-separated list, or simply rely on naming to distinguish the
argument types. Unfortunately I already blew that (somewhat on purpose),
as "comments" is a config variable _and_ a modifier to the konfigshow
AM> I'm almost partial to leaving out the equals sign, and just using space
AM> as the delimiter like every other command. Or perhaps make the equals
AM> sign optional.
It's really easy to make it optional. It's nice to have it, though,
because it mirrors the way the config currently works and it preserves some
orthogonality with the << of multiline values.
AM> Will it require a complete rewrite?
To do it properly, yes. To hack it in, no. I don't think anyone wants
another set of hacks grafted on.
AM> I know nothing is ever as simple as first envisioned, but I thought
AM> configset could be something fairly simple like "update the value in
AM> memory and do writeconfig to write it back out".
It's the parser that needs to be rewritten. That tricky "<< END" syntax is
a complete break from the way things are done now. Plus, like I've said,
I've already rewritten the parser once so it shouldn't be a big deal.