Gammon Forum : MUSHclient : Python : When is DeleteLines() fully processed?

Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Entire forum

MUSHclient

Python

When is DeleteLines() fully processed?

When is DeleteLines() fully processed?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

Smorly (31 posts)

Date

Reply #15 on Thu 21 Feb 2013 09:45 PM (UTC)

Message

Your suggestion does not meet my design goals, which are (in no particular order):

1. If the final line is a prompt, it should be on the bottom line, as the server intends.

2. There should be no consecutive blank lines.

3. Certain lines should be moved to a different world.

I have this completely functional already, except for one case: when all lines that have been received after a prompt have been moved, effectively leaving the prompt as the final line, the prompt is not on the bottom.

So your trigger does not meet design goal #1

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #16 on Thu 21 Feb 2013 10:24 PM (UTC)

Message

Smorly said:

Your suggestion does not meet my design goals ...

OK, but:

Smorly said:

The first strategy is no good, because I can't predict where the server will place blank lines, and I don't want to reconstitute information that is already available to me (i.e.: that the server inserted a blank line)

You want to see server blank lines, you just said so.

So if the prompt is followed by a blank line, then you reasonably should want to see it.

Quote:

1. If the final line is a prompt, it should be on the bottom line, as the server intends.

In this particular case, the server also intended a blank line, otherwise you wouldn't have this issue.

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?

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Fiendish USA (2,533 posts) bio Global Moderator

Date Reply #17 on Fri 22 Feb 2013 04:52 AM (UTC)

Message

Can you explain why you're using DeleteLines in the first place? I don't understand why you would want or need to.

This is how I block trailing blank lines after other blocked output. Any time you "move" a line of output, enable this trigger group.


<trigger
   enabled="n"
   match="^$"
   regexp="y"
   name="end_gag_omit"
   group="end_gag"
   omit_from_output="y"
   sequence="100"
   send_to="12"
>
<send>
   EnableTriggerGroup("end_gag", false)
</send>
</trigger>
    
<trigger
   enabled="n"
   match=".+"
   regexp="y"
   name="end_gag_keep"
   group="end_gag"
   omit_from_output="n"
   sequence="101"
   send_to="12"
>
<send>
   EnableTriggerGroup("end_gag", false)
</send>
</trigger>

https://github.com/fiendish/aardwolfclientpackage

Posted by

Smorly (31 posts)

Date

Reply #18 on Fri 22 Feb 2013 03:15 PM (UTC)

Amended on Fri 22 Feb 2013 03:23 PM (UTC) by Smorly

Message

^^^ 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.

Quote:

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.

Quote:

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.

Quote:

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.

Posted by Nick Gammon Australia (23,042 posts) bio Forum Administrator

Date Reply #19 on Sat 23 Feb 2013 12:18 AM (UTC)

Message

There is something odd about the output buffer behaviour, I'm looking into it.

Specifically, if you receive a line from the MUD, terminated by a newline, the extra blank line added by the code (as soon as it sees a newline) is not displayed.

However something (I'm not sure what, but deleting the last line seems to do it) makes the last blank line be displayed.

So, it's more of a display issue.

For example, typing this into the command window (with "/" as the scripting prefix, and Lua as the language):


/AppendToNotepad ("foo" , "count = " .. GetLinesInBufferCount ( ) .. "\r\n" )
AppendToNotepad ("foo" , "len = " .. GetLineInfo (GetLinesInBufferCount ( ), 2) .. "\r\n")

The last line is shown as length zero (as expected, as it adds a new empty line) however I am seeing the last line from the MUD at the bottom, not this blank line.

Try this:


/DeleteLines (1); DoCommand ("End")

That deletes the last line, and then scrolls down to the end of the buffer, invoking whatever logic that exists to hide that last blank line.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Smorly (31 posts)

Date

Reply #20 on Sat 23 Feb 2013 12:22 AM (UTC)

Message

Those two commands invoke the pause mode bug.

Posted by

Fiendish USA (2,533 posts)

bio Global Moderator

Date

Reply #21 on Sat 23 Feb 2013 12:58 AM (UTC)

Amended on Sat 23 Feb 2013 12:59 AM (UTC) by Fiendish

Message

Quote:
1) Triggers cannot delete themselves.

This is not actually true. They just can't delete themselves without a very small delay.

Quote:
Maybe don't trigger on the prompt

If you trigger on the prompt already anyway, you can use my suggestion above to delete the blank line following it.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #22 on Sat 23 Feb 2013 03:13 AM (UTC)

Message

Quote:

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).

I have not had this bug reported before.

Quote:

Those two commands invoke the pause mode bug.

I can't reproduce that. It just seems to work for me.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #23 on Sat 23 Feb 2013 05:39 AM (UTC)

Message

Quote:

Therefore I have a single trigger, (^.*$), that captures all lines from the server and performs its own pattern matching and processing.

It seems to me that you are fighting the client here. Having a single trigger, and doing it all in there, is throwing away all the trigger sequencing, omitting, scripting, etc. that are designed into them.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Smorly (31 posts)

Date

Reply #24 on Sat 23 Feb 2013 01:15 PM (UTC)

Message

Quote:

Having a single trigger, and doing it all in there, is throwing away all the trigger sequencing, omitting, scripting, etc. that are designed into them.

Exactly. Because, as I said above:

Quote:

the built-in trigger system is not flexible enough for my needs.

I have designed my own sequencing and omission. It works better than the built-in one (excepting this thread topic). A key feature missing from the built-in system:

Conditional, dynamic keep / stop evaluating

I any trigger processing code can signal trigger processing to stop for the given line. How could I do this in MUSHclient's triggers?

For instance: You cannot see!

You have two trigger handlers, one of which casts 'cure blindness' and one of which eats a pill of cure blindness.

How do you write these two triggers so that they remain independent (no strong binding) but only one will fire if its conditions are met? You obviously would not cast if the room were hushed or you were out of mana, you would eat the pill. Likewise, you wouldn't eat the pill if you could spellcast.

Now for the solution you're thinking of, extend it to also support wearing an earring of cure blindness, or applying a salve of cure blindness, or any number of further actions.

None of the code can reference the other triggers, because the software is modular, and the user might not have any of those items (or want to use them, or have the salve use module loaded, or...), or the ability to cast that spell.

It's ridiculous to do this without conditional trigger termination.

I also mentioned 2 other things that MUSHclient triggers don't do. So yes, I am throwing away the built-in trigger system.

Quote:

I have not had this bug reported before.

From my experience, if you have two matching triggers at the same priority, both of them keep_evaluating and one of them one_shot, the one_shot trigger will fire twice. Again, I have not fully discovered the conditions where this is true. I recall that the non-oneshot was in a plugin while the one-shot was not.

Quote:

This is not actually true. They just can't delete themselves without a very small delay.

Let me rephrase that, then: triggers cannot delete themselves synchronously. It's inelegant to set a timer to delete a trigger, and opens a window for a race condition. In my system, I can delete any (internal) trigger at any time with no ill effect.

Quote:

If you trigger on the prompt already anyway, you can use my suggestion above to delete the blank line following it.

Okay, I think you took what I said out of context. I was talking about the room capture scenario, not the blank line omission. If you want to respond to the room capture scenario, please flesh out what you're saying, because it doesn't make sense here.

And, as I mentioned, your solution does NOT solve the thread topic problem. I'm trying to delete a leading blank line, not a trailing one. The trailing lines delete fine with a single call to DeleteLines()

Posted by

Smorly (31 posts)

Date

Reply #25 on Sat 23 Feb 2013 01:51 PM (UTC)

Message

Quote:

I can't reproduce that. It just seems to work for me.

As soon as I execute that command, the 'Paws' Button depresses, and it says MORE at the bottom. This only occurs after I have connected to a server.

Here is a video of it occurring:

http://youtu.be/dJ1syii7NLs

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #26 on Sat 23 Feb 2013 08:34 PM (UTC)

Message

Check (set) the output option "unpause on send" and that problem seems to go away.

I'll look into what that is about.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by Nick Gammon Australia (23,042 posts) bio Forum Administrator

Date Reply #27 on Sat 23 Feb 2013 09:10 PM (UTC)

Message

OK, I found the "paws" problem. When a line (or lines) were deleted it was not updating the scrollbar information (ie. there are now less lines). This had the side-effect of making the scroll bar thumb move up a line. That caused it to go into "paws" mode, and if you didn't have "unpause on send" it stayed paused.

So now, doing this seems to correctly delete the last line:


DeleteLines (1)
DoCommand ("End")

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Smorly (31 posts)

Date

Reply #28 on Sat 23 Feb 2013 09:16 PM (UTC)

Message

That video was taken with the option "Unpause on send" already checked.

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #29 on Sat 23 Feb 2013 09:17 PM (UTC)

Message

Actually you shouldn't have to do the "end" thing.

I've redone it to call "addedstuff" which adjusts scroll bars etc. and has the side-effect of scrolling to the bottom, if not paused. So this should work fine.

So now, doing DeleteLines (1) should correctly delete the last line, and scroll so that the previous line is now at the bottom.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

105,101 views.

This is page 2, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )