|^^^ Yes, that can be used to delete trailing blank lines, but not leading blank lines, as would be the ones between the moved line and the prompt.|
You want to see server blank lines, you just said so.
I don't think I ever denied wanting to see blank lines, except in one case.
Let me guess that what is happening is that you have a prompt line, then some chats arrive which are moved to a different window. However a blank line after the chat now makes the prompt "jump" up a line, is that right?
No need to guess, it's exact problem I've been describing!
When a prompt comes from the server, there is no blank line following it.
When subsequent lines come from the server, it sends a blank line followed by the subsequent lines. If I remove said lines from the buffer, the output buffer should be effectively unchanged, i.e.: the prompt is still on the bottom line.
Can you explain why you're using DeleteLines in the first place? I don't understand why you would want or need to.
I'm using DeleteLines because the built-in trigger system is not flexible enough for my needs.
1) Triggers cannot delete themselves.
2) There is a bug where a one-shot trigger will fire twice if it is set to keep_evaluating under certain circumstances (which I have not fully determined).
1 + 2 = There is no reliable way to make a one-shot trigger that is keep_evaluating.
3) It is difficult to do substitution of information and keep processing. For instance, one trigger changing the data that subsequent triggers process WITHOUT changing the line itself, i.e.: transparent to the user.
You might decide to store the interstitial data in a variable for the later trigger, but what if the substitute trigger is not present? You will have created a strong dependency between the two triggers. I am trying to design something modular, loosely bound.
4) There is no way to conditionally stop trigger evaluation (that I am aware of).
Well, I suppose you could, but you would have to go disable every other applicable trigger and then re-enable them at a later point. Which means you need to know about them all and have a reliable method of re-enabling them. So again, strong binding, if this strategy would even work.
5) Omit does not work for situations where the trigger represents the final line of complex data output.
Let's say you want to capture all room information. You know that room titles are proper case, the desc ends with [Exits: .*], and there is an item list (might be nothing) and a mob list (also might be nothing) that follows, terminated with a prompt.
How do you write a trigger that copies all of these lines and omits them? A multi-line trigger might work, but what if a chat line appears between the mob list and the prompt, and that chat line is not deleted? Maybe don't trigger on the prompt, but try to include the null items and mobs, while somehow not capturing other things? That's going to be a pretty complex regular expression, which would be a pain to a) create, and b) debug.
Procedurally analyzing the output and selectively moving the lines is the simple approach. Find a prompt. Analyze the output buffer for a room title. Read forward, moving the title, the desc, the exits, the item list, the mob list. Done. If there were any chat lines in there, they remain.
Therefore I have a single trigger, (^.*$), that captures all lines from the server and performs its own pattern matching and processing.
It does grant me any processing I wish though, including:
1. On-the-wire substitution (synchronous)
2. Conditional/dynamic line omission
3. Conditional/dynamic keep evaluating / stop evaluation
It is a shame that the behaviour of DeleteLines is not fully documented or intuitive, but the alternative is wading through a mire of other problems and things I cannot control.