[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Python
. . -> [Subject]  When is DeleteLines() fully processed?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

When is DeleteLines() fully processed?

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


Pages: 1 2  3  

Posted by Smorly   (31 posts)  [Biography] bio
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?
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] 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?
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] bio
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.
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] bio
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] bio
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] bio
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

Posted by Smorly   (31 posts)  [Biography] bio
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.
[Go to top] top

Posted by Nick Gammon   Australia  (21,324 posts)  [Biography] 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
[Go to top] top

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.


19,985 views.

This is page 1, subject is 3 pages long: 1 2  3  [Next page]

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

Go to topic:           Search the forum


[Go to top] top

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.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]