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


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  xTerm support...

xTerm support...

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


Pages: 1 2  3  4  

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Thu 05 Apr 2007 07:44 PM (UTC)
Message
We where so worried about other things, including MXP, that this slipped under the radar or something. Basically, an application called xTerm supports an extension to ANSI for using 256 colors. The codes work as described here:

http://frexx.de/xterm-256-notes/

Not sure, but I think the colors can be set to anything you want, but there are pre-built sets. In other words, you would need a second "xTerm" color dialog off the one for changing ansi settings, which would bring up the palette you can edit for them all, as well as possibly load a .vim file that has an existing table layout, like those linked to in the page I gave above.

It seems the latest version of TinTin++ now incorporates this feature, as they have combined the code for Putty and TinTin++ into one, and one of them has support for it. This appears to be something that lacks negotiation though. I.e., the client will either support it or not, but the server has no way to tell "if" that feature is supported through the negotiation sequences.

Note: This could probably be handled with the packet intercept and replacement (through simulate) trick, but we should imho limit that, since if everyone "fixes" problems that way, then you start running into "whose" intercept needs to work on the line first, to make sure everything happens as its supposed to, much like problems people are having with more than one plugin using the same line already.

Also, we might want to keep an eye on this:

http://firebolt.com/IMP-rfc.php

They seem to be reinventing MXP there. So far, most of it, except the ones like clearing the text display, which Mushclient can't even do using ANSI codes anyway, appear to be fairly similar to MXP's functions. That might change as they expand the feature set though.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #1 on Thu 05 Apr 2007 09:22 PM (UTC)
Message
What exactly are you suggesting be done about Xterm?

Note that it will be impossible to get full Xterm support without implementing cursor movement support.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date Reply #2 on Thu 05 Apr 2007 09:47 PM (UTC)
Message
The only reason I could see to add xterm support would be to have some sort of console version of MUSHclient. Tinyfugue is a console based mud client that I've used on occasion to mud through the ssh program on my cell phone using screen. I'm not even sure if xterm can be used in Windows environments, although someone has probably ported it by now.

If that's not the suggestion, then I believe that Shadowfyr is suggesting that MUSHClient should support 256 colours, which would be a step back from the 16 million it supports now.

Also, although the IMP looks kind of interesting, they have a whole two muds that support it there. Personally, I wouldn't worry about it unless it starts to get more popular, since it seems to be easy to implement as a variation of MXP which calls different functions. The thing that worries me about implementing this is the <AUDIO FILE=filename or URL> and <STOPAUDIO> tags. It just looks like it would take a bit of reworking how MC deals with audio.

It is much easier to fight for one's ideals than to live up to them.
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Thu 05 Apr 2007 11:43 PM (UTC)
Message
As far as I can see, the 256-colour support (which I had been thinking of) is much simpler than MXP. It basically just allows a wider range of colours to be displayed, without all the hassle of implementing MXP, escaping out ">" signs, and so on.

I've looked, but can't see on the page mentioned above, where the actual mapping is for the 256 codes and the corresponding RGB codes is - can anyone see it?

The problem I think you would have is, that without negotiation, it would be hard to know you could safely send the wider range of colours down to the client. Plus you would need everyone to have a supporting client.

It might be hard to design a colour scheme that supports the existing 16 colors, as well as nicely upgrading to 256 colours.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Fri 06 Apr 2007 12:10 AM (UTC)
Message
There seems to be a chart here:

http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #5 on Fri 06 Apr 2007 01:14 AM (UTC)
Message
If I remember correctly, xterm-256 is actually not all that well supported. A lot of xterm emulators -- gnome-terminal being the most salient in my mind -- do not support the 256 color mode. And a lot of them have it but as a beta feature, such as SecureCRT for Windows. Anyhow, it would be nice to support the extended color codes, I suppose, but it should be kept in mind that that support is meaningless unless the MUD server knows about it too.



As for a console version of MUSHclient, well, that's a great idea in principle, but the complexity of doing such a thing is mind-boggling to me...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Fri 06 Apr 2007 03:18 AM (UTC)
Message
A question then ...

According to that page, and other resources I found, the 256 colours are introduced with this sequence:


Set the foreground color to index N:   ESC[38;5;Nm
Set the background color to index M:   ESC[48;5;Mm



... where N and M are in the range 0 to 255, and ESC is hex 0x1b.

Now since this is implemented as a state machine, we are taking it one character at a time.

What do we do if we get: ESC[38;6;Nm

That is, something other than 5 after the [38 or [48 ?


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #7 on Fri 06 Apr 2007 03:30 AM (UTC)

Amended on Fri 06 Apr 2007 03:31 AM (UTC) by David Haley

Message
I'm not sure why this is a problem: if the sequence is one in your list of sequences, you process it, and otherwise you throw it away. (Or, rather, you output it as normal.)

I guess this would require some amount of buffering, and having enough characters of look-ahead before deciding what to print to the screen. Still, this doesn't seem like a big problem to me.

More formally, if you will, if you receive a character that is not part of an expected control sequence, you change to the "normal" state and output the characters. If you are in the normal state and receive a prefix of a control sequence, you keep on trying to parse the control sequence until you reach the end (or fail to), and if you reach the end you do whatever that control sequence calls for.




EDIT:
I imagine the spec should clarify this kind of thing. It's also possible that everything between an ESC and a "m" is ignored if it's not a control sequence, with some kind of limit. I'm sure they say something about this, but I haven't gone to look.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Fri 06 Apr 2007 03:44 AM (UTC)
Message
Quote:

I imagine the spec should clarify this kind of thing.


I haven't seen a spec that specifies the 256-colour stuff, I am working from examples.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #9 on Fri 06 Apr 2007 04:15 AM (UTC)
Message
Apparently it doesn't matter if it's 256 or not. The Xterm control codes are apparently of the format specified by ISO 6429, which is "the same" as ECMA 48, according to http://mail.nl.linux.org/linux-utf8/1999-11/msg00173.html.

ECMA 48 may be found here:
http://www.ecma-international.org/publications/standards/Ecma-048.htm

I did not read the whole thing (it's 108 pages and a pretty boring read...), but it would appear that a control sequence is defined precisely as a set of things, and anything you weren't expecting is not a control sequence and therefore meant to be processed as normal data. Therefore as soon as you see something that might be a control sequence, you have to start buffering it until you determine either (a) it is in fact a control sequence or (b) it was not a control sequence (i.e. you saw a number you didn't expect).

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Fri 06 Apr 2007 04:47 AM (UTC)

Amended on Fri 06 Apr 2007 04:48 AM (UTC) by Nick Gammon

Message
Hmmm.

What I have done in the past is assume that something like:

ESC[xxxm

... is a control sequence, and then if 'xxx' is a recognised number (eg. 41 for red background) switch to that colour, otherwise ignore it.

This, I think, allows for graceful degradation in the event that an unrecognised code appears.

I have got a trial going which seems to work OK, my only query is what do you do if you don't get the final 'm', but instead a semicolon? What part of the sequence do you back track to?

For example, if you wanted colour 124 text on colour 165 background, would it be:


ESC[38;5;124m ESC[48;5;165m   --> presumably that is ok

or:

ESC[38;5;124;48;5;165m   --> backtrack to getting another ANSI code


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #11 on Fri 06 Apr 2007 04:52 AM (UTC)
Message
I think the standard defines this. Doesn't it allow for lists of command-parameter pairs inside an ESC[ ... m sequence?

Of course, a malicious server could give you an "endless" sequence of correct codes, setting the foreground over and over again, but I'm not sure this is really an issue. At worse, the client can define some arbitrary maximum number of allowed commands in a single sequence in order to not have to keep buffering it all in memory.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #12 on Fri 06 Apr 2007 04:56 AM (UTC)
Message
Oh well, my version will accept both of my examples. I personally don't buffer them, the state machine consumes them as it goes.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #13 on Fri 06 Apr 2007 05:04 AM (UTC)
Message
I think both are fine according to the standard. The only reason I see to buffer them is to avoid incorrectly processing an incorrect escape sequence. For instance, if I send ESC[38;5;124;48;5;165j (note terminating j) then the program should not set any colors.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] bio   Forum Administrator
Date Reply #14 on Fri 06 Apr 2007 05:38 AM (UTC)
Message
It looks like you are right, and I am not doing that. Conceivably you could buffer up an indefinite sequence using an STL vector or similar, and then run through it and process everything when you get the 'm', if you ever do.

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


134,268 views.

This is page 1, subject is 4 pages long: 1 2  3  4  [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 HostDash]