Member Discussions

This is something of a short topic, but a thought has occurred to me as I program: Am I making unnecessary extra work for myself by always having line ends in string literals done as "\r\n" instead of just "\n"? I realize that it's just two extra chars to type, and that adding a filter to the socket send methods to automatically add in the extra "\r" introduces extra and perhaps unnecessary overhead to the sending methods, but as I think about it I wonder; shouldn't I just only use "\n" for breaks in the literals in the code and let the sending method do the rest?

I figure that since I'm already using Python and trying to ignore the majority of under-the-hood costs in favor of easier/faster ways of doing things, that this might be another thing I ought to consider changing.

Thoughts?

I use \n in all my server internals for strings, internal editors, message data and database storage.

When receiving from sockets, I accept \r\n, \n\r, \r\0, and \n as line terminators translating those to \n before handing the input to the mud.

When sending to sockets, I translate \n to \r\n.

I try to follow the old network rule: Be liberal in what you receive and conservative in what you send.

Doesn't using line breaks for various bits of text to be sent to the player mean you have to strip them out if you want to acommodate any kind of non-standard width of screen?

Istarian wrote:
Doesn't using line breaks for various bits of text to be sent to the player mean you have to strip them out if you want to acommodate any kind of non-standard width of screen?

You can either leave them out and let the client handle the wrapping, or detect the screen width with NAWS and insert the newlines accordingly. Personally I prefer to stick with an 80 character width and use any extra screen space for other stuff.

Alter Aeon does the same thing Tyche described. We have a streams-style output stack for sockets, which handles CR/LF generation, ANSI color conversion, page breaking, line inversion, and various filters like grep/head/tail/wc.

One curious AA fact: \n marks the beginning of a line, not the end. In the olden days before I knew what I was doing, I decided to use that convention so as to make prompting more natural; I was used to having the cursor on the same line as the prompt, similar to a standard DOS/unix command shell. Now there's ten thousand strings using this convention, and in the cases where we want to reverse it, it's easier to toss a line inversion filter on the socket stack than to rewrite the code.

-dentin

Alter Aeon MUD
http://www.alteraeon.com