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

Register forum user name Search FAQ

Gammon Forum

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

Mon 18 Feb 2013 07:26 PM (UTC)

Message

I notice that after calling DeleteLines, GetLinesInBufferCount has not changed. The lines that have been deleted are still valid indexes into the buffer, but are blank strings.

This causes havoc for trying to clean up after a script that has deleted lines - for instance deleting surrounding blank lines.

How can I call DeleteLines(), then at some point later in the same alias / trigger, get an up-to-date view of the buffer?

Posted by Nick Gammon Australia (22,982 posts) bio Forum Administrator

Date Reply #1 on Mon 18 Feb 2013 09:28 PM (UTC)

Message

As I said in another thread, the client always has a "current" line at the end of the buffer, that is, the buffer is always non-empty, and it always has a current line to which incoming text is appended.

So DeleteLines (1) would delete the current line, and then insert this "empty line" at the end, so the number of lines in the buffer would not change.

If you test something like this:


 DeleteLines (5 ) ;  print (GetLinesInBufferCount ( ))

The number of lines displayed will go down by 4 each time (because of that added line). So the number is being updated, it just isn't quite what you think it is.

Each line has a unique time-stamp ( GetLineInfo (x, 13) ) so you may be able to work out from that if this is an "old" line or one you put there yourself.

- Nick Gammon

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

Posted by Smorly (31 posts) bio

Date

Reply #2 on Mon 18 Feb 2013 11:23 PM (UTC)

Amended on Mon 18 Feb 2013 11:25 PM (UTC) by Smorly

Message

When the buffer looks like:


100 hp 100 ma 84 mv 100 wi BERSERK Player Homes >

100 hp 100 ma 84 mv 100 wi BERSERK Player Homes >

and I call DeleteLines(2), the buffer then looks like:


100 hp 100 ma 84 mv 100 wi BERSERK Player Homes >

Which is what I would expect. I note that my prompt sting has a CR on the end.

If the buffer look like THIS:


100 hp 100 ma 84 mv 100 wi BERSERK Player Homes >

and I call DeleteLines(1), the buffer remains the same:


100 hp 100 ma 84 mv 100 wi BERSERK Player Homes >

but if I call DeleteLines(2), the buffer becomes:

At this point, if I scroll up (or down), the buffer becomes paused, and will not scroll back down to the blank line, nor will it unpause until more data comes in from the MUD and you scroll down.

So while prompt lines can acheive the desired result, there's some consistency problems between prompt and non-prompt lines. Is there a way to treat all lines like prompt lines, maybe?

Or is there just no way to delete a single blank line on the end of a buffer without inducing a scrolling bug?

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #3 on Tue 19 Feb 2013 08:14 PM (UTC)

Message

What do you mean "becomes paused"? Does the word MORE appear in inverse on the status line?

Look, adding data to the output buffer (a doubly-linked list) was one of the first things I did in the client, after changing from a fixed 1000-line array.

As such, it is probably the most badly implemented part. I mean, it's reliable normally, but fiddling with it can have strange consequences. A while back I tried to change from using the Microsoft CTypedPtrList class (with its strange behaviour of the way you "walk" the list) into an STL dequeue type (which would have been better in many ways).

In doing that all sorts of odd things happened, for example the last line wouldn't be drawn, or it would crash, or some damn thing, so I went back to the older method.

One of the worst design decisions I made, I think, was having that "existing last line" thing, which is causing all your grief. For one thing, if the last line type is "output" and you type something it has to change its type from "output" to "user typing".

However having acknowledged that it's flaky, it generally works, unless you do something unusual, which --- dare to say --- doing DeleteLines is.

It isn't helped by the weird way Microsoft implemented lists, unlike the STL way, where to get the next element the pointer actually advances to the next one plus one. Ditto for getting the previous element.

If you can spot an obvious bug in the C++ code, fine, I'm happy to fix it. But I'm worried that fiddling with it will introduce more bugs than it fixes.

As a work-around, I suggest omitting all blank lines. I have a plugin that does just that.

And/or make a plugin that omits duplicate prompts (ie. it omits all prompts, and puts one back if it is different from the previous one).

- Nick Gammon

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

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #4 on Tue 19 Feb 2013 09:13 PM (UTC)

Message

This was in 1995, BTW, about 18 years ago. For a full history see:

http://www.gammon.com.au/relnotes

- Nick Gammon

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

Posted by

Smorly (31 posts)

Date

Reply #5 on Tue 19 Feb 2013 09:47 PM (UTC)

Amended on Tue 19 Feb 2013 09:50 PM (UTC) by Smorly

Message

Yes, the word MORE appears, and the 'paws' are depressed. I have since discovered that this bug only happens when i call DeleteLines using the script prefix on the input line, but the remainder of the problem... remains.

As to the nature of your buffer, it's a shame. Should I find the time to investigate the source, I will do so, but as you mentioned, I'd be opening a can of worms.

Deleting ALL blank lines is not an option. It's hard to read, ugly, and the server already offers that option if a user wants it. And it's trivial to accomplish if I had wanted to.

And prompt deduplication? I do that already. This bug is related to keeping the prompt as the LAST line in the window, not a blank line. I could try omitting and pasting it back. I'll let you know how that goes.

I'm 99% to where I want to be. Full ANSI line move/copy with blank line and prompt deduplication. I guess I'll have to live with the 1 little bug that's left.

Posted by

Smorly (31 posts)

Date

Reply #6 on Tue 19 Feb 2013 09:59 PM (UTC)

Message

And with that little test, the answer:
calling DeleteLines(3), then AnsiNote(prompt) still produces the extra line after the prompt.

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #7 on Tue 19 Feb 2013 11:08 PM (UTC)

Message

Smorly said:

Deleting ALL blank lines is not an option. It's hard to read, ugly, and the server already offers that option if a user wants it.

I know I shouldn't have to suggest work-arounds for buggy code, but here goes ...

First, omit all blank lines. Then have an algorithm that notes a blank line when certain conditions are satisfied (eg. before a prompt). The algorithm would remember that it had just done that, and wouldn't add two in a row.

Or even this ...

Match on blank lines (like the omit blank lines plugin does). Omit them (in the trigger). However under certain circumstances, put one back. That way you aren't calling DeleteLines.

- Nick Gammon

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

Posted by

Smorly (31 posts)

Date

Reply #8 on Wed 20 Feb 2013 02:47 AM (UTC)

Amended on Wed 20 Feb 2013 02:57 AM (UTC) by Smorly

Message

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)

The circumstance for inserting a blank line in the second strategy is:

1. A blank line was last sent (track from omit)
2. A nonblank line has arrived.

This will require triggering on all nonblank lines and then inserting a line before the triggered line. How could this be accomplished?

Alternately, you could omit ALL lines and AnsiNote them back, with blank lines inserted when appropriate. Can you still scrape style information from a line that was omitted from the buffer?

edit: Evidently not. Just tried it.

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #9 on Wed 20 Feb 2013 05:10 AM (UTC)

Message

You should be able in send-to-script, not send-to-script-after-omit.

Quote:

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)

Er, yes, but if you get the line count (line from server count) then you should be able to detect that this is a singleton blank line.

Something like this:

Omit all blank lines
In the trigger processing, see if we just omitted a blank line previously (based on line-count-from-server)
If not, note a blank line (ie. put it back)

- Nick Gammon

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

Posted by Nick Gammon Australia (22,982 posts) bio Forum Administrator

Date Reply #10 on Wed 20 Feb 2013 05:28 AM (UTC)

Message

This seems to work (in Lua, sorry):


<triggers>
  <trigger
   enabled="y"
   match="^$"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>
if GetLineInfo ( GetLinesInBufferCount ( ) - 1, 2) &gt; 0 then
  Note ("")
end -- if
</send>
  </trigger>
</triggers>

That is omitting all blank lines, but if the previous line was not blank, then it puts the blank line back.

- Nick Gammon

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

Posted by

Smorly (31 posts)

Date

Reply #11 on Wed 20 Feb 2013 01:19 PM (UTC)

Amended on Wed 20 Feb 2013 01:42 PM (UTC) by Smorly

Message

That solution does not solve my problem, as it still leaves the final line blank EXCEPT when the last line from the server is a prompt.

So unless I find I way to make other lines like prompt lines, or I append a blank line AFTER a prompt from the server, there will always be an inconsistency with the last line.

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #12 on Wed 20 Feb 2013 08:31 PM (UTC)

Message

What's the problem exactly? The last blank line? It's always blank isn't it? Can you post a screenshot?

- Nick Gammon

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

Posted by

Smorly (31 posts)

Date

Reply #13 on Thu 21 Feb 2013 05:22 PM (UTC)

Message

This is how the buffer looks when a prompt comes in:

http://imgur.com/rRECH0y

If any other line comes in, there's no way to return the buffer to that state.

Posted by

Nick Gammon Australia (22,982 posts)

bio Forum Administrator

Date

Reply #14 on Thu 21 Feb 2013 08:02 PM (UTC)

Message

Yes, but that's by design. A prompt line is (usually) not terminated by a newline, so you don't see the extra (blank) line.

Once other data arrives, it is terminated by a newline, and thus you see the blank line at the bottom of the buffer, which the start of the next line. In other words, it has shown the newline.

I think I see what you are saying. If you get a prompt, it will sit at the bottom (as there is no newline). Then if some blank lines arrive the prompt jumps up one line.

But you said you wanted to see blank lines from the server. If you omit all of them, the problem goes away. My suggested trigger omits all but one, but as requested, you see at least one.

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

96,676 views.

This is page 1, 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 )