|As I mentioned while replying in another thread, I've been toying with my own codebase lately. And it just makes me cringe to see how some 'clients' butcher standards. MS Telnet is particularly horrible in how it claims to do its own echoing, while completely denying to do so. :(|
Anyway, this is the MUSHclient forum so on to my 'beef' here.
First problem is the 'Keep commands behind prompt' option. It should by default be ON, since the entire point in nearly all muds I have played is to have a 'status line' of sorts and behind it you can type what you want. Linux telnet and other clients also treat it as such. New players, or new people, will rarely find that option. Hell, I used MUSH for 5 years now, coded it into extremes I suspect most other people haven't, and I found out about it today.
But my biggest and foremost problem is with the 'Convert IAC EOR/GA to newline' option, which is a complete hack as it is now (sorry). I used to be able to put up with it, since the muds I played had prompts but I didn't really care where my typed text ended up, or I even had the echos turned off.
But now that I am playing with my own codebase, I feel it is of bigger importance to have such behaviour correctly. Testing other clients made me realize how much I enjoy having the commands behind my prompt. Yet, there is NO way to do this while still be able to trigger the prompt while it comes in (as opposed to when you finally finish the line by typing something). So right now, people have two choices:
1) Commands on the same line, or
2) Triggering the prompt.
In many muds, especially PK related ones, spam is heavy, so you want to have such commands on the same line, while you still want to see them ('oh, I made a mistake here by doing X, should have done Y instead'). For people looking for this, there is no proper alternative. To boot, triggering on the prompt always has had this annoying behaviour of spawning extra newlines into existence.
However, I hate making complains without offering fixes. So, my (codish) suggestions to fix this behaviour are as follows:
1) Display the current line the moment IAC EOR/GA comes in. I assume that internally, MUSH needs the newline, so that can stay.
2) Add a prompt flag to this line so you can tell it apart.
3) When typing stuff yourself (+echoing it), append to the end of the previous line IF it has the prompt flag, or a new line if it does not.
4) When mud output comes in right after the prompt without us sending/echoing data on the prompt, show it on the same line as the prompt flag. This new content will have a \r\n somewhere due to the mud believing it needs to finish the prompt (although I am sure there are muds who will first add some stuff to the prompt, and THEN add a newline). Thus avoiding the extra newlines the old 'fix' kept giving. Unless you want to implement the optional change to triggers way at the bottom of this post, I suggest the second time this line is 'completed' (by \r\n this time) you do not test it against triggers or you'd get prompts that get triggered twice.
Now, this might/will give some complications with existing scripts, but I have a suggestion for those too:
5) Any and all user commands will ends up on a new line (Tell, Note, etc) if a prompt was the last thing there was. This would probably be no change in behaviour assuming MUSH added the newline it wanted behind the prompt (see point 1)
6) Add the following commands:
AtPrompt() returns boolean if we are currently on a prompt (check the flag we set)
ContinuePrompt() removes the newline MUSHclient added to the end of the prompt line before it, allowing other echoing commands to append to the end of the prompt. It will also remove the prompt flag (for simplicity). This would FAIL if AtPrompt() returned false.
CompletePrompt() will finish the current line and add a newline like Note() would. However, it will also SET the prompt flag for the line you finished, effectively simulating the IAC GA or IAC EOR commands.
This way, we are keeping the current behaviour while also adding functionality. As MUSHclient is now, you can't adjust the prompt while keeping the 'keep commands after prompt' working, unless you dig through the packet. And that can only change basic text (no full RGB color, no hyperlinks unless the server supports MXP, etc). So with this change, you could:
1) keep your commands after your prompt,
2) trigger on your prompt, and
3) replace your prompt
ALL at the SAME time.
Another optional improvement that could be made would be to add a three-way prompt flag to triggers like the textstyle flags. That way, you could trigger on prompts ONLY, non-prompts and both. It isn't really necessary, but I think it might be nice to add.
Even more efficient a solution would be, rather than to set the flag on the line of the prompt, to keep the 'prompt flag' in your connection-state-machine of sorts.
Could both these suggestions (default setting / changed prompt behaviour) be implemented? Pretty please?