No subject

        <flags> are detailed in the <newclient.h> file, which is common to both
        the client and server.  The flags of relevance to this command are the
        CS_QUERY flags.  <flags> are sent in plaintext form.

        The client is free to ignore the flags.  However, if the server just
        wants a single character as a reply, that is all it uses, even if the
        client sends a long string (Server will use the first character.)

        [text] is the question/prompt that should be printed.  Right now, it is
        typically just a ':'.  Client should display it no matter what is is,
        however.  Text is an optional field.  Note - as of 0.94.2, text may
        be multi line, delimited by newlines.  Client should handle this
        appropriately.


 So yes, the query can include extra text (ie, the question to ask).

 The reason it doesn't always is more based in history.  The first
client was basically the X11 (not gtk) client, which only had the one
draw info window with no popups.  And for that, it worked fine.

 Note the gtk client actually will present popups, a feature I find
really annoying.  But I did add and option to the gtk client which does
not use popups.

 Note that text by itself is not perfect.  The gtk client, for example,
tries to do some extra work to present a nicer form when swapping
stats (buttons to press).  IT basically does this by examining the
set of text (or last set of drawinfos).

 Right now, there are not actually a lot of places in the server
that take input.  And realistically, not all the queries have been
updated on the server side to include a text message.

 There could certainly be further enhacnements done.  Let the client
deal with this more - for example, we know for a fact that when you
connect to a new server, at minimum a name and password is needed.
Client could take care of both of those and send it to the server as
something like LOGIN <name> <password>.   Likewise, for stat swapping,
the client could send the two swapped values in one response, and not
one at a time.  This actually simplifies server code, and should make
the interface better on the client (the reason the client would
even ened to send the swapped stats at all and not just a final result
is so the player can see what raising is str does to damage for
example).

 I would file this under one of the improvements for client/server
communication.  There was a lot of stuff done in the original
server/client implementation that as we look back it is, isn't the
optimum solution.  It worked for the given client (x11), but doesn't do
a very good job now.