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, confirm your email, resolve issues, 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 ➜ General ➜ Character \b
Character \b

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

Pages: 1 2  

Posted by Greven   Canada  (835 posts)  Bio
Date Thu 06 Jan 2005 05:00 PM (UTC)

Amended on Thu 06 Jan 2005 05:01 PM (UTC) by Greven

Message
Maybe I'm missing something, but is there a reason that MUSHclient doesn't seem to support the \b character? I don't know if this is complicated to do, or if it can be turned on somewhere that I'm not aware of, but as default I beleive that MUSHclient ignores this character, at least if it's sent from a mud.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Thu 06 Jan 2005 05:15 PM (UTC)
Message
Why would a MUD send a \b character? Trying to erase a line and start it over or something?

I think that Nick doesn't want to support \b for much of the same reasons he doesn't want to support most telnet cursor movements, because for instance it can make for quite a few logging headaches.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #2 on Thu 06 Jan 2005 05:21 PM (UTC)
Message
Well, in this specific case the mud uses the \b character to make something like the windows hour glass in a characters prompt when they are in a add_timer type state. After packet debugging login, I saw how they did it, and would send a series of characters like | / - \ in a row, erasing the previous one to make it look like the line is spinning. An interesting idea in my opinion, but some clients don't like the character, so the mud allows you to toggle it.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #3 on Thu 06 Jan 2005 05:47 PM (UTC)
Message
Yeah. I think it's very cool indeed. I think this might be another case where a compromise such as the one I suggested in my thread about clear-screen should be adopted.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #4 on Fri 07 Jan 2005 05:13 AM (UTC)
Message
Again, this is trying to make a MUD client into a telnet client. I can envisage all sort of complications, like backspacing over style run boundaries, or removing a hyperlink that MXP had just put there. Effectively the client would have to have a whole heap of extra code to undo adding stuff into its internal structures.

Say, you had a line which had wrapped - not because of a newline, but because it hit the wrap column. Also it might have colour changes.

For each backspace, you have to decrement the number of characters in the line, and in the style run, and then when the style run becomes zero remove the style. Then when the line becomes empty, remove the line, and so on. It's a lot of work, and potential bugs, for a nice swirling counter, that is someone trying to emulate something they saw in Unix.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Greven   Canada  (835 posts)  Bio
Date Reply #5 on Fri 07 Jan 2005 05:16 AM (UTC)
Message
Ok, heh, yeah didn't realize it was quite so compilcated. Not big, just thought I would ask.
Nobody ever expects the spanish inquisition!

darkwarriors.net:4848
http://darkwarriors.net
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #6 on Fri 07 Jan 2005 07:19 AM (UTC)
Message
Is there any way you could have this as an option, 'enable at your own risk', that worked if and only if the server used it in a well-behaved manner, e.g. only erasing characters that are actually present. But if the server uses it incorrectly, MUSHclient makes no guarantees as to what will happen (most likely a crash.)
Quote:
Again, this is trying to make a MUD client into a telnet client. I can envisage all sort of complications, like backspacing over style run boundaries, or removing a hyperlink that MXP had just put there.
Isn't MXP trying to make a MUD client into something it didn't use to be, though? And isn't a MUD client really a telnet client to begin with? That's how it started, after all. *grin*
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #7 on Fri 07 Jan 2005 05:43 PM (UTC)
Message
> Again, this is trying to make a MUD client into a telnet client.

Mud clients are telnet clients. The fact that most muds have never bothered to take advantage of some telnet features is just a design decision. But some do attempt to take advantage of them, so I have never been sure what your point is about this issue Nick. Imho, all that assuming such things are totally unneeded does is limit the client, and thus force the mud developers to limit the muds themselves, even if they don't want to, because of the expectation that no one will have a client that does support such things. Of course, if other clients can do it, then you hang yourself instead. It really doesn't make a lot of sense to support only subsets of features, that someone might have the unmitigated gall to then use anyway. lol
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #8 on Fri 07 Jan 2005 08:58 PM (UTC)
Message
These are all part of the same idea:


  • Backspacing

  • Full-screen cursor addressing

  • Clear screen


This is what the telnet protocol supports, however a MUD client is not really a telnet client. If you want a telnet client, go ahead and download one.

But you really want a telnet client which also has:


  • Separate command window

  • Triggers

  • Aliases

  • Timers etc.

  • Logging

  • Long scrollback buffer

  • Word-wrap at edge of buffer

  • MXP with hyperlinks etc.

  • High speed


Some of these are quite tedious to do if you allow the user to willy-nilly move the cursor around (eg. clear screen, backspace, cursor address).

What happens with a triggered line, if the triggering text is changed by backspacing it, or cursor addressing into the middle of it?

Say I have something like this:

FOO\n\b\b\b\bBAR\n

If I have a trigger on FOO and one on BAR which one triggers? One? Both?

Some of these questions are going to come down to the word "compromise" - or maybe "user option" - or maybe "bug", if it doesn't work perfectly.

The point is, that for right or wrong reasons, it isn't easy to change now. For speed and space-saving reasons, internally things are stored in linked lists, style runs, cached MXP actions, and so on.

MXP for instance is parsed on-the-fly, not even at a newline.

So, imagine something like <b> (text is now bold) followed by \b\b\b <i> (text is now italic).

To allow this I have to not only handle the backspaces, but the effect of changing styles from bold to italic.

It just isn't cost effective to tackle things like this. I might spend many, many hours getting something like this coded, debugged, and go through maybe 5 release cycles whilst minor glitches are removed, and then it would only be for maybe a handful of users whose MUDs send backspaces.

Quote:

But if the server uses it incorrectly, MUSHclient makes no guarantees as to what will happen ...


Yes, but what will happen is that once a feature is added, you may not care if it isn't perfectly implemented, but 6 months later I will get a message (from someone else) saying "Your client claims to support backspace but here is some test data to prove it doesn't. I refer you to RFC xyz which shows your implementation is flawed. I suggest you fix it up straight away".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Flannel   USA  (1,230 posts)  Bio
Date Reply #9 on Fri 07 Jan 2005 09:18 PM (UTC)

Amended on Fri 07 Jan 2005 09:26 PM (UTC) by Flannel

Message
Couldn't a plugin be made to do this?
Well, if it were all on one line.
I would think backspacing over newlines would be a huge problem.
But write a plugin to handle it, and I would think the best way of doing it would be to treat backspaces as if they meant to erase the character prior. Not pieces of styles, nor styles themselves. abc if backspaced twice, would be a not ab(no-bold). If you only backspaced once you would get either ab(bold) or ab(no-bold) depending on how you felt it should act.

Couldnt this be done with a plugin? Partial lines, and then you colortell the text? And just keep colortelling the full text?

(On receiving a backspace character, the plugin adds a newline, which allows it to be caught (and omitted) via a trigger, you store that in a variable somewhere, which you can manipulate however you like (you can treat styles as you wish) and then colourtell every time you need it to change (another backspace character). If you get to the end of your line... well, you're not going back up a line, so it's blank. And once you get a newline, you finish off your line, and start listening for the initial backspace character again.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
Top
Posted by Flannel   USA  (1,230 posts)  Bio
Date Reply #10 on Fri 07 Jan 2005 09:25 PM (UTC)

Amended on Fri 07 Jan 2005 09:27 PM (UTC) by Flannel

Message
(This was an edit to that post, but it got long enough to support it's own post)

Sorry, wasn't thinking. This would require you to be able to get rid of those lines your colortelled. Thought hadn't even crossed my mind. Nick, what about if we could remove a random line from the buffer? Just the display buffer. Whether it was a note, or output, or whatever.
We have the tools to get the amount of lines in the buffer already, so we have everything else to be able to do this.

Although, there are obvious problems with that. Like what about if something else tries to get a line that has changed numbers?
Actually, would anyone be doing that? Since a simple note would throw off their count, they'd have to be checking before getting the information anyway, if they wanted to know it was the right line.

So, maybe that is a feasible command. Obviously, it would only remove it from the buffer, it would still be in the log as it were.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #11 on Fri 07 Jan 2005 09:50 PM (UTC)
Message
That could possibly be done, but it still isn't as simple as it sounds.

MUSHclient potentially has a 500,000 line buffer. To quickly index into that (eg. when you scroll the window) it also has a "directory" which points to batches of 100 lines.

If it didn't have that, moving from end-of-buffer to line 250,000 would potentially mean scanning the linked list of lines for 250,000 iterations.

Now, if you remove even a single line, the directory would be "out" and have to be rebuilt, or adjusted somehow.

For now I am trying to get a stable release that I can call version 4, so things that might potentially introduce heaps of bugs, like omitting lines, backspacing etc. will have to wait.

Having said that, there is no real reason you can't make a "backspace processor" for the OnPluginPacketReceived which simply scans through, and if it finds a backspace removes the previous character, however I doubt that will work for the case raised in this thread.

Greven wants to use backspace to remove characters like | / - \ in a row, which is presumably shown over a lengthy operation, so each would be in its own packet.

In that case the OnPluginPacketReceived idea wouldn't work, as each packet would be separate.



Greven, what you could do to handle this case of the "timer display" is detect the specific sequence, and omit it from the packet altogether, eg. match on:


Processing: |


You would delete that part entirely, and show it on the status line.

Then when you get a second packet:


\b /


You would also delete that, but update the status line, and so on until the sequence ends.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #12 on Fri 07 Jan 2005 11:33 PM (UTC)

Amended on Fri 07 Jan 2005 11:35 PM (UTC) by Shadowfyr

Message
Quote:
Say I have something like this:

FOO\n\b\b\b\bBAR\n

If I have a trigger on FOO and one on BAR which one triggers? One? Both?


On BAR. FOO would be on a seperate line. The \b command does not, in any client I have ever seen, treat line breaks as a character that can be reversed over, so the \b\b\b part would simply not do anything at all. You can't delete what is on a line you are not on and such commands deal with 'lines' not the entire range of text sent.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #13 on Fri 07 Jan 2005 11:33 PM (UTC)
Message
Quote:
Yes, but what will happen is that once a feature is added, you may not care if it isn't perfectly implemented, but 6 months later I will get a message (from someone else) saying "Your client claims to support backspace but here is some test data to prove it doesn't. I refer you to RFC xyz which shows your implementation is flawed. I suggest you fix it up straight away".
Sure, I see what you mean. But is there really no way to delegate this to plugins? I don't think MUDs will send random or useless backspaces such as the examples you give, so the average user will never run into problems.

If some bozo makes the claim that you don't fully support backspaces, then just say that indeed you don't and never claimed that you do. It's an "at your own risk, this does not fully work" kind of plugin. It just seems that it would be really nice (and not that hard) to just pop off characters one at a time from the end of the output buffer, and simply leave behavior undefined if the backspaces cross over non-printable characters (or MXP or whatever.)

If you stress that it doesn't work completely, and remind people that it's for very specific purposes - and recall that MUD servers won't just randomly send backspaces - it should all work out.

All this of course assuming that there isn't some technical reason for not being able to simply pop off a character from the output buffer.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #14 on Fri 07 Jan 2005 11:42 PM (UTC)
Message
As I said, that assumes backspace can even cross between lines in the first place. The only times I have 'ever' seen it do so is when it was actually a bug and incorrectly ignored where the line started. I may be wrong, but I don't think so, since it makes no sense from the standpoint of the original teletype system that telnet was designed to simulate, for that behaviour to happen.
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.

54,667 views.

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

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

Go to topic:           Search the forum

[Go to top] top

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

Home