the current syntax for renaming a discussion is:

/rename -disc <old> <new>

At the time this was written, this was pretty much the only way to guarantee that you weren't trying to rename yourself oddly (-'s were still allowed in users names at that time.)

Recently, there has been interest in cleaning up this ugly syntax, which is a great idea. Here's a snippet of a conversation (warts and all) on RPI's -lily-dev that may serve as inspiration for someone who wants to clean this up.

# -> (21:18) From mjr [Evil(tm)], to lily-dev:
# - Oh, I noticed last night that /help needs to be updated to mention
# - /rename -disc
#         This has been done -coke
#
# -> (21:41) From Maker, to lily-dev:
# - We still haven't come up with a more reasonable syntax for that?
#
# -> (21:41) From Garance [goodnight], to lily-dev:
# -  the help hasn't been changed because there was some discussion about
# - changing the syntax.
#
# -> (21:42) From Garance [goodnight], to lily-dev:
# -  though I'm tired enough right now that I don't remember what we thought
# - would be best.  have it as a separate command perhaps?  /drename?
#
# -> (21:43) From Maker, to lily-dev:
# - I remember someone suggesting a separate command, but I still like the
# - notion of just "/rename -<disc> newname".
#
# -> (21:44) From Maker, to lily-dev:
# - In other words if new_name starts with a '-', assume it is a discussion to
# - be renamed rather than renaming yourself to that name, and require a
# - second argument in that case.
#
# -> (21:59) From Garance [goodnight], to lily-dev:
# -  the thing is, right now /rename is one of the commands which allows
# - blanks in a name without having to quote them, so that's still a little
# - problematic.  What we probably should do is say that /rename will behave
# - like the other commands, wrt handling names with blanks in them.
#
# ### It is now Thu Dec 18, 2003 ###
#
# -> (09:17) From Maker, to lily-dev:
# - [rename] Sorry - missed your reply last night. Spaces aren't a problem.
# - While it allows spaces, names shouldn't be allowed to begin with '-'. So,
# - if the first word begins with '-', it is a discussion. Do we allow spaces
# - in discussion names as well? If so, we'd have to require those to be
# - quoted, I guess. For regular user names, though, we'd preserve the ability
# - to enter those without quotes, as anything which didn't begin with '-'
# - would be treated like before, with the entire set of args just used as the
# - name.
#
# -> (09:18) From Will [meeting], to lily-dev:
# - Patches accepted!
#
# -> (09:19) From Deven, to lily-dev:
# - "/rename -discussion name with spaces -new discussion name" could be
# - parsed -- you'd only have to restrict " -" in the discussion names, and
# - even that could be allowed when quoted.
#
# -> (09:19) From Will [meeting], to lily-dev:
# - (which I've said before - the only reason we had this syntax was because
# - at the time it was written, there was no real alternative. other changes
# - have made alternatives possible. Feel free to clean it up. In the
# - meantime, someone should document the current option in the help so it's
# - not lost if no one gets to teh change. I'll do that right now.)
#
# -> (09:19) From Will [meeting], to lily-dev:
# - ... coming up with a NEW method of parsing is not a good idea.
# - reusing an existing one, however, is a great idea.
#
# -> (09:19) From Maker, to lily-dev:
# - I'd rather not document something if we know it is going away.
#
# -> (09:20) From Will [meeting], to lily-dev:
# - maker: is there a patch? no. Therefore, we don't know anything.
#
# -> (09:20) From Maker, to lily-dev:
# - If you are saying that no one will ever change this, fine.
#
# -> (09:20) From Maker, to lily-dev:
# - I'm getting really tired of that attitude.
#
# -> (09:20) From Will [meeting], to lily-dev:
# - I'm saying that no one has cared to in the 2-3 years this feature's been
# - on devcore. =-)
#
# -> (09:20) From Maker, to lily-dev:
# - Is there no concept here of being able to talk about WHAT to do without
# - someone whining about who will do it?
#
# -> (09:20) From Will [meeting], to lily-dev:
# - maker... I'm pretty sick of the "don't bother, someone will fix it"
# - attitude. =-)
#
# -> (09:21) From Will [meeting], to lily-dev:
# - I'm not whining. I'm saying that not documenting the current feature
# - because it will eventually go away is stupid.
#
# -> (09:21) From Maker, to lily-dev:
# - In that same time, I haven't heard anyone clamoring to rename discussions
# - very often, either.
#
# -> (09:21) From Maker, to lily-dev:
# - The current "feature" isn't a feature.
# - It was a prototype that was never finished.
#
# -> (09:22) From Will [meeting], to lily-dev:
# - Uh, being the person that WROTE the feature, Yes, it's feature complete,
# - and works as designed.
#
# -> (09:22) From Will [meeting], to lily-dev:
# - there. help is updated.
#
# -> (09:22) From Will [meeting], to lily-dev:
# - (the fixed help was probably one of the changes from devcore that didn't
# - quite make it over.)

-- CoKe - 18 Dec 2003

Fwiw, the help was deliberately not updated because I really wanted to switch to some better syntax for this feature. I did install the code as it was, so we could test it and make sure it worked correctly. But even at the time, I said we should decide on a different syntax, and there were several discussions at that time about what syntax would make the most sense. By then I was busy working on other (non-lily) projects, and I never got around to switching the syntax.

Fixing that syntax is something that I hope to finish before 2.8.0.

-- GaranceDrosehn - 18 Dec 2003

Understood. I just know how things go - it's better to have what's in place documented, in case we get distracted. Also, now we won't have to fend off the one person a week who says "you know, the help doesn't....". Regards.

 -- CoKe - 18 Dec 2003
to top