Stuff in here might not be dealt with until after the 1.0 release:

* The debugger's add_expression method uses a brute-force and not very good
  approach for compacting the set of trace and skip expressions. Improving
  this will improve speed while debugging is on.

* Standardize on \n after every entry in fields. Right now it is sometimes
  left off the last one by some bindings, and there is ugly code in
  builder/safechange and in setfield.c and probably elsewhere to deal with
  this.

  (It would be nice to have a proper regression test before making this
  change.)

* Too much special purpose code to deal with symlinks vs sticky lists.
  Separate the data types. It's a symlink if the field can only contain one
  value, that is a ref. A link to /dev/null or something will be a null
  ref. If the field can contain multiple or no references, it will be a
  sticky list. No auto-promotion between types.

  One question is, how does the set_reference_verb know what to do for a
  new field? Probably it just defaults to sticky list.

* Do lantern demo object

   - Er, how? It needs to register with the topmost room, whe it is moved,
     but it also includes when the avatar carrying it moves. Or I need a
     way to not need to so register. Let's see.....

     I could make it register only with the avatar carrying it. Then they
     could see. But others in the room could not, unless it were put down.

     Maybe that's ok.. if there were some way for others in the room to be
     told hey, there's a light here, but it's bobbling around erratically
     as the user uses it and you cannot see much.

     I could make a command to point it at an object. This would probably
     make visual messags going from the object be stronger, so it's
     visible, and messages going to it weaker (it's blinded a bit by the
     light). But again this needs to be changed when the lantern is moved.

     I could make physics move inform interior objects of moves too. Ugh.
     Or a way for objects to request to be told when other objects move.

* Currently only rooms, containers, and furniture support detail objects.
  This should really be extended to avatars, but that is kinda hard, since
  then we get into details that would look one way if the object was worn by
  an avatar, and another way if carried, and a third if it was just in the
  room. One approach would be detail_carried and detail_worn. Mh.

* Details are currently only visual, but it would be better if all senses
  were supported. A smell or sound can be a hook for a detail too, after
  all.

* Repurpose numeric status codes returned by methods as exceptions. So to
  throw an exception a method might print the reason, and exit 1.

  Before this can be done, verbs must be changed to not use statues, the
  various methods that use #!/bin/false must be changed, it must be
  documented, and the whole code base audited.

  (As a side effect, some verbs that currently must do
  $this->exec->super(@_) or $this->exec->other_verb(@_) will be able to
  lose the exec, since it is only there to make return code propigation
  work.)

* Since linux 2.4.18 and up or so have 32 bit uids, mood could default to
  somewhere in high uid space that is less likely to conflict.

* Do same stuff for volume as for mass, except most containers do not
  change volume as stuff is added to them -- avatars do though; so does
  putting stuff under or on or behind and object, eh? Bleh.

* Nick argues that there should be a way to mark a field as a reference,
  even if it is currently a null reference, and differentiate this from an
  empty field that could be a string, or whatever. One field that could
  really use this is location.
     - note that methods like setfield can only tell if a field should be a
       ref if they are passed a ref. This implies a need for mooix:/dev/null
       type thing for a null object reference.

* Parameterize spoof marking; only do it if the avatar to get the message
  has a field set. I guess this goes in notify.. Pity it will mean another
  field access to slow things down a bit more.

* lockable containers (with keys)
  - really needs true mixin support so I can use the same code as used in
    doors (doors would override the mixin a bit for special door stuff)

* duck and ball, if doing their thing when the moo goes down, will still
  have the fields set when it comes back up. It so happens that this is ok,
  because to restart themm, they get picked up, which calls onmove, which
  resets the fields. Still, this means look cannot count on the fields
  reflecting their state. For parrot, I solved this by making it register
  with the startuplist.

* Maybe I should generate the programmer's tutorial, so you can read it for
  one particular language? This would make it shorter.

* Better behavior on zero free space circumstances. Object location
  integrity can get screwed, so can sessions.

* The object referred to by "it" should not change if the preposition is
  used in a single command. Similar for other prepositions. For example:

  > open it
  You open the birdcage.
  > put the key into it
  You put the key into the birdcage.
  > close it
  You can't do that.
  
  Here on the second command, it should remain pointing to the birdcage.

* Use Lingua::EN::Inflect to convert stuff like "alias" to
  "aliased". 
  To avoid confusion, make fields that can hold lists have official names
  that are plural, and just support the singular forms as fields as
  alternatives, like so:

  	my alias is "fred"		# sets aliases[0]
	my second alias is "bob"	# aliases[1]
	show my aliases
	show my alias			# lists aliases

  This would probably go in the parser, but would only have to be tried for
  fields, so would not yeild a slowdown in general.

* tab completion can show the objects in the room even if it's dark or you
  are unconcious.

* If a container gets too much weight on it/in it, it should suffer damage
  and perhaps break. Avatars already have a maxweight and their masschange
  drops stuff if over, just generalize from that for containers.

* Store LC_CTYPE in tty session, restore before running readline and editor
  stuff. Also needs to handle LANG and LC_ALL somehow, either by storing or
  deriving LC_CTYPE from them before storing. Needed for utf-8.

* socket session editing offers no way to escape ".\n", if a file contains
  that, and the tf macros don't deal with it either.

* Python binding has to close child's stderr in background or Nick reports
  hangs. Why? Nothing should wait on stderr. Nick desribes the problem as:
   > Actually, this has to do with __runmeth hanging from a subsequent call
   > to background() in the method

* The html session does not currently protect against cross-site scripting.
  It needs to before it gets used for anything more elaborate than spitting
  out the known-ok help texts it is used for now.

* The parser could deal a bit better with compound direct objects that have
  no separators:

  > look me mooadmin watch
  It's not clear what you mean by "watch".
  > look me mooadmin and watch
  You can't do that.
  > look me and mooadmin and watch
  A very bland-looking person.
  ...
  > look me, mooadmin, watch
  A very bland-looking person.
  ...

* Toading doesn't work as well if the avatar has a description of their
  own, or a maxweight field of their own. The resulting toads might not be
  very toad-like. It would be better to override these fields, which would
  entail saving them until the avatar was de-toaded.

* Consider making the C binding's getallvals return value and runmethod
  params be linked lists. I find I often want to append something to an
  existing parameter list, and it's too hard with the current data
  structures.

* Internationalize mass and volume fields; make a weight field that changes
  mass, and accepts lbs or kilograms. Make a flag on the avatar say which
  systems of units they want to see, or use LC_whatever from the login
  environment for this?

* Contents mass tracking for furniture and any other object that allows
  placing stuff under it is wrong. Stuff underneath should not contribute
  to total mass, but currently does.

* Once CallStack/libmoocallstack is firmly entrenched, I could go to a
  binary format for the stack files themselves. Just dump out the structs..
  This would probably be a good optimization. Have to be careful that it
  doesn't let mooadmins present a bogus file to mood and crash or root it.
  Probably input files would still have to be in text representation.

* If you're being carried by someone else, you don't get autolooks when
  they move around.

* I suppose that if someone is sitting on the couch, and they change
  location (leave the room, sit on something else, whatever), it should
  really say "Fred gets up from the couch." first. 

* The way that users are logged out of the moo if the moo is being taken
  down is bad, since the shutdown method runs, removing the session, and
  possibly the avatar (guests), and then leaves anything that's running,
  like the parser, or a running verb, to make the best of it. This can
  result in various odd messages seen by the user, as objects that were
  expected to be there go away. A better approach might be to first SIGINT
  the topmost method (be it the prompt method, a verb, or the parser).

* The notify method could be motimized. It currently re-expands the same
  message for every object the message goes to, and the result is the same
  often (except when it's putting in stuff like "you"). If it could skip
  doing the expansion if it knows the result will be the same for the object
  it's expanding for, that'd be a good speedup.

* The guest pileup on kite happens when there are guests that somehow don't
  have any sessions. So the reap stuff on moo startup doesn't reap them.
  I'm not sure how it happens that guests occur w/o sessions w/o
  self-destructing; need to figure that out.

  The piled up guests are sleeping and have no lastlogin field. So, they
  must have never finished connecting..

  Perhaps what's happening is the guest is made, but connection dropped
  before the guest can be logged in? This needs more investigation.

* If there is an exit named "exit", saying "exits" takes the exit.

* If there is a penny under the couch, and I've just logged in, and I'm
  holding a penny, and I look at it, won't I see both? Isn't this a step
  backwards from where I was before recursive object detection? Should be
  fixable.

* What happened to the other objects I asked to be put, then? It should put
  them, and then ask the question.

  > put duck and ball and penny into box
  Do you mean the 1971 penny you're holding, the bent 1964 penny inside the
  treehouse, or the dull penny inside the fishbowl?
  > 1
  You put a penny into the box.

* If I put the toy duck on the couch, it does not move around. OTOH, if I
  am sitting on the couch, and I put it down, it does, and it ends up on
  the couch. Hmm. I probably need a flat_surface property or something,
  which a floor provides, and a couch may or may not.

* This fails:

> take the lint from the box, then put the lint in the box
You take the lint.
You can't do that.

  OHH. It's because this is all parsed in one pass, and so it parses it
  like:

  sent1:
  	verb = take
	do = lint (from the box)
  sent2:
   	verb = put
	do = lint (in the box)

  So the 'put' verb gets no indirect object. Ugh. This is why it works ok
  if I run the two commands as two separate commands, not one.

  Here is a similar problem unrelated to containers:

  > teleport mooix:portfolio/box to here and look box
  It's not clear what you mean by "box".
  > teleport mooix:portfolio/box to here
  The box appears.
  Teleported.
  > look box
  A very bland-looking container.
  Contents: the fishbowl
  
  This would seem to indicate that perhaps I should move execution into the
  grammar, so as soon as it finds a sentence, it executes it, then it moves
  on to the next sentence, which may only make sense in the new context.
  Hmm. The big problem with doing that is I may execute some sentence
  fragment that does the wrong thing, and then the parser fails to parse
  the tail end of the sentence. Doing things as we do now, we know that the
  whole sentence successfully parsed before anything is done, which is much
  safer.

Mixins:
* Runmeth does not know about mixin inheritence. This can wait -- I'm not
  100% sure mixin fields are done evolving yet.
* should the fields method list mixin fields too? Probably so (so show
  will, too..)
* I am wondering if the current $obj->mixin_foo thing is best, or if I
  should just make it look for a mixin for each unfound field/method after
  consulting parents. If you look at the new gender mixins, it'll be odd to
  have to say $avatar->gender_subject_pronoun, when there is no (obvious)
  connection between subject pronoun and gender. The catch is that if I go
  this route I really need a "hey, this reference is a mixin!" flag, so I
  don't pseudo-inherit stuff from the location reference, the owner
  reference, and so on. Maybe I can use a .gender-mixin file to note that,
  or something? Other catch is name space conflicts.

  Or I could use a mixins field that has a list of mixins for the object
  (and is sticky so it's an object list).
  
  Doing this also has the advantage that when the parser wants its grammer,
  it can use $this->grammar, rather than the awkward $this->parser_grammar.

  I suspect that there are so many other uses I just need to do this.
  Mixins are good for many things extending avatars, plus similfying the
  current objects by breaking chunks out into optional mixins, and maybe
  even flattening the tree, by making programmers and maybe builders just
  be a mixin (which would reduce the lookup depth for common methods for
  programmers).
