Trying to get jaws to read partial lines using the existing plugin

Hello everyone,
I'm trying to get jaws to read partial lines, since it only seems to read lines when they end with a newline, so if there's a line with a prompt, or a question that needs you to input data after it, it's not going to read it unless I review it with the mouse cursor.
So I decided to try and build something using this new? OnPartialLineReceived callback, but it's reading the lines twice, one with the normal functiont hat it's always been using and one for the partial line, but it seems to be reading all the lines not just partial ones with this method, so I tried to use a variable that if the line was the same as the one it had read with the other function it wouldn't read it again, but it still does it. Here's what I did

'this event fires when new text is drawn from the mud. **
sub OnPluginScreendraw (t, log, line)
if (t = 0 or t = 1) and TTSReadNew = 1 then
ttsline = line
TTSObject.sayString line, 0
end if
end sub
'This event is called when a partial line is received.
sub OnPluginPartialLine (sText)
if Not (SText = ttsline) and TTSReadNew = 1 then
TTSObject.sayString SText, 0
end if
end sub

First, I would do the test the other way around. The function OnPluginPartialLine is called first, when a line partially arrives, and then OnPluginScreendraw will be called later. Thus I would save the line in OnPluginPartialLine and check if it is the same in OnPluginScreendraw.

Next, there might be a simpler solution ...

Do these partial lines normally arrive at one time (when initially logging in?). If so, you could set a flag (eg. in OnPluginConnect), and for a while only read out partial lines. Then when completely logged in (ie. you get a welcome screen) turn that flag off, and then just read out whole lines.

This has been a very irritating issue for a long time, especially on MUDs with
incomplete prompts (some lp's just print ">", also logon prompts). How do
other clients handle this? I think that
we could just add a newline after all of the received packets, but when I tested that a while ago it seemed to have a few problems:
1. There's a limit of 999 bytes per packet. This is far less than the usual 4096 or 8192 that I think is more commony used.
2. There's no way to tell when recv() has no more bytes to receive.
If we had this, I think it would be a simple matter of batching everything until we can't receive any more, then
telling MC to process whatever it just received as a line.

The problem is, this isn't really solvable at the network level. Because of the nature of TCP/IP, being a streaming protocol, there may be network latency as packets are dropped and retransmitted.

There may be no more data from the network at a given moment, but you have no way of knowing that another packet is about to arrive in one millisecond. And, this packet may be the rest of a partial line (eg. a room description).

I don't know what limit of 999 you are talking about. Is that some reference to a perceived limit in MUSHclient? If so, I don't know of any such limit.

The issue about prompts has been covered many times, see: http://mushclient.com/faq point 11.

Rather than trying to muck around with adding newlines to random packets, something I think will fail in annoying ways, I would be addressing the handful of things from a MUD that are not terminated by a newline and deal with those. For example, the prompts I have already mentioned. If no other method works, a modification of a packet that appears to have a prompt in it, to add a newline after the prompt, would be one solution.

For other things, like the initial prompts (name, password, class, race etc.) my other suggestion of reading out from OnPluginPartialLine would work, and then switch that off when you are into the MUD proper.