Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The recent topic regarding where text is displayed made me think of 2 possible preferences that might be worth adding.
1. Delay display of local echo.
When set commands would only be displayed right after testing prompt triggers. This could cause the local echo to be dropped into the middle of a line sometimes, because packets that don't end in a new line sequence cause prompt testing. It should be off by default. If the user has set matching information in Session|Prompt then delayed display would occur on a match after all other prompt triggers had been tested. Testing for matches before display is needed to allow $ to be used in patterns as end of text marker.
2. Exclusively use GA/EOR for prompt
When set packets that don't end in a new line sequence would not cause prompt testing. Only reciept of the EOR/GA sequence would cause testing. This might provide a small speed gain for users playing on muds that provide this sequence. It should be a suboption of the existing "Use GA/EOR for prompt" in the Session|Emulation section.

Users that can get clean prompt detection could turn both on. This would cause thier commands to always show up in the right spot and would cause text received that the mud expects to be at a new line to actually be at the beginning of the line.

Posted: Sun Mar 08, 2009 3:25 pm

I'm not sure exactly what you mean and exactly what the benefits are of the first one, but I believe the second is already on the wishlist.

With the first, do you mean it to be a solution to the problem where, if you're lagging and time it just right, commands can be sent in the middle of a line, between two packets? Instead, with that option on, the command would only be echoed once prompts had been checked? If that's the case, I think these two preferences should be rolled into one - there's no point at which you'd be able to enable the first option without having the second one enabled (because if you're not on a MUD that uses GA/EOR, your prompts are indistinguishable from packet breaks) and if you're using the second one, you'll always want the first one as well (to stop the problem I just described).

Essentially, what I think this should be is one preference - when checked, prompt triggers are only processed when a GA/EOR is received, and commands will not be echoed after a line with no terminating sequence - only when lines end in CRLF or GA/EOR.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Irregardless of whether the first prefertence is check or unchecked commands would still be sent immediately upon issuance.

The first preference is entirely meant to move the local echo of commands, controlled by Scripting|Echo Commands, to a better spot. Nearly all servers of Telnet based connections expect user commands to occur after a prompt. Just as many use the logic that the local echo will leave the cursor at the start of line as the basis for not putting a newline sequence at the start of a packet that is a response to a command. It is irresponsible of both client and server to make assumptions about unnegotiated behaviors, yet it has become a common practice.

Two additional ways to look at it are: CMud responds to the user raising an OnPrompt event through thier own triggers by dumping the delayed local echo, and a match occurring in response to data in the Session|Prompt preferences raises an OnPrompt event. Both would make OnPrompt a standard name, which has actually been suggested since the advent of events.

It should be up to the user to make the prompt distinguishable from other packet breaks, and CMud already has a mechanism for this. As I said using the Session|Prompt preferences allows the user to tell CMud what is a prompt. The second preference only limits when CMud tests prompt triggers for matching.

It is likely that non-mud based servers will actually use the EOR/GA sequences that existed since the original Telnet specification, and may save TeSSH users from having to set the extra data. I would even go a step further and say that if a packet ends in an EOR/GA within the first 10 packets of a session then the second preference should automatically enable. The automatic enabling would only occur if the preference was still at default.

These 2 things are neither mutually inclusive nor mutually exclusive; they are complimentary.

Posted: Mon Mar 09, 2009 5:43 pm

I need to think more about the first option possibility.

On the second option, it seems like if the existing EOR/GA option is enabled that this should be how it works. I haven't seen any MUDs that only "sometimes" use the EOR/GA options. So if CMUD sees that EOR/GA is being used by the MUD, then it seems like that should always control the way prompt triggers fire. In other words, I can't think of a situation where you'd want the second option disabled.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I just tried it in the untitled session. I made sure "Use GA/EOR for prompt" was checked then created the trigger, #TRIGGER {abc} {#SHOW def} "" {prompt}
I then entered "#SHOWP abc" at the command line and the resultant display was "abcdef".

The current option doesn't make it so that GA/EOR is required for prompt testing. It is also enabled by default, making it require the GA/EOR could break some users triggers. Having the options seperate allows the current one to be enabled by default, which might be able to pick up an EOR/GA sequence in the middle of a packet. When a user is more savy they can enable the exclusive option because they know the system they are interacting with always supplies the sequence.

Posted: Mon Mar 09, 2009 10:51 pm

Yes, I know it doesn't currently require GA/EOR. What I'm saying is: What if your 2nd option was more internal to CMUD. It would default to false (prompt triggers don't require GA/EOR to fire). If CMUD sees that the existing GA/EOR option is enabled and then *detects* a GA/EOR from the MUD, then the internal flag would get set to true (GA/EOR is now required for prompt triggers). Turning off the existing GA/EOR option would also reset this internal flag.

In other words, I don't think we need another "visible" option that will just confuse people. Seems like I can handle it internally.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

That sounds even better. I really don't see how any properly implemented server would only use the sequence part of the time. Of course we all recognize that "properly" is the operative word there.