TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

two more highlight options

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests
View previous topic :: View next topic  
Author Message
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Sat May 17, 2014 12:49 pm    Post subject: two more highlight options Reply with quote

The highlight option dim is a misnomer: it displays text with "normal" intensity, disabling the bold or faint attributes.

Anyway, I'd like to see two options similar to dim.
no-underscore (\e[24m) would turn off underscoring, leaving other attributes alone.
Likewise, we could have no-blink (\e[25m).
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat May 17, 2014 8:07 pm    Post subject: Reply with quote

I don't really see a practical use case for it. Trying to avoid bloat.

Will allow starting a highlight code with a \ so you can use:

#highlight {test} {\e[24m}
Back to top
View user's profile Send private message Send e-mail
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Sat May 17, 2014 9:22 pm    Post subject: Reply with quote

Practical use?? Isn't removing blink and underscore inherently practical?
A mud could output
Quote:
Clan SomeColorfulName has gained a level!

or
Quote:
Team BLUE has 30 seconds to capture the flag.

in blinking text. Removing the blink attribute would be nice without messing up the colors and other formatting.

Bloat- seriously? The code would be similar to dim, just with two more keywords for the parser and two more flags to keep track of whether or not text following the highlighted text should be blinking or underscored.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat May 17, 2014 10:02 pm    Post subject: Reply with quote

You can remove blink and underscore with a color substitution.

Bloat is generally added one tiny piece at a time, so if a feature is unlikely to be used by many, or can be solved in another manner, I generally don't add support for it.
Back to top
View user's profile Send private message Send e-mail
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Sun May 18, 2014 4:35 am    Post subject: Reply with quote

Scandum wrote:
You can remove blink and underscore with a color substitution.


How do you do that without resetting the other properties to default or manually including ansi escape code sequences in a substitution?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sun May 18, 2014 10:18 am    Post subject: Reply with quote

You can see color codes by using: #con {convert meta} on.

One example would be:

#sub {~\e[5m} {}

#sub {~\e[%*;5m} {\e[%1m}

#sub {~\e[5;%*m} {\e[%1m}

#sub {~\e[%*;5%*m} {\e[%1;%2m}

That should get rid of all blink.
Back to top
View user's profile Send private message Send e-mail
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Mon May 19, 2014 3:36 am    Post subject: Reply with quote

Scandum wrote:
That should get rid of all blink.


The key word is "all". What that doesn't do is allow someone to highlight text with desired blink/underscore formatting, preserving the formatting of subsequent text. ANSI escape codes include codes to turn off formatting- bold has its counterpart normal (which is an available as a highlight called dim), underline has underline: none, and blink has blink: off. Including the two ANSI codes to turn off underline and blink is simply a matter of logical consistency.

Here's an example that a script workaround wouldn't fix: Some muds display ANSI drawings of world maps. Some maps include text with underscores and blink. Suppose all map symbols that represented minerals in a mine map blinked; I could, for example, want to remove the blink from copper veins but not remove it from gold and silver veins.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Mon May 19, 2014 7:15 am    Post subject: Reply with quote

You can remove specific segments with substitutions as well.

As you're not messing with colors you can use:
[/code]
#sub {whatever} {\e[25mwhatever\e[5m}
[/code]

That's about as simple as a highlight.
Back to top
View user's profile Send private message Send e-mail
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Mon May 19, 2014 1:24 pm    Post subject: Reply with quote

I could be using colors and bold; I'm just keeping the examples simple.

Your last substitution doesn't work if the subsequent text isn't blinking; it forces blinking to be set. If I highlight something, text that isn't unhighlighted should be unaffected.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Mon May 19, 2014 6:59 pm    Post subject: Reply with quote

Alright, will have a look at it, might have to tweak the vt100 parser a little to support this.
Back to top
View user's profile Send private message Send e-mail
Slither



Joined: 17 May 2014
Posts: 22

PostPosted: Tue May 20, 2014 7:25 am    Post subject: Reply with quote

Scandum wrote:
Alright, will have a look at it, might have to tweak the vt100 parser a little to support this.


From the looks of the code, other problems could be solved if Tintin computed and kept track of the formatting values of every character before sending them out to a terminal/file. Tintin would have to know what ANSI parameters to restore after a highlight/substitute ended. Tintin would also be better at doing color matches for actions.

For example, suppose I want to perform an action/substitute on map symbols that look like :$:
The two colons and dollar sign are bold.

Creating patterns to match those symbols can be annoying because multiple permutations of ANSI code squences produce the same text. The mud could output the bold code before the string and only change color before each character. The mud could repeat the bold code before each character. Bold yellow could be produced by sending bold then yellow or yellow then bold. The mud could also add extraneous reset codes before each character. To make things worse, if the characters to the left of the first colon are red or bold, the ANSI codes may not immediately precede that colon. Yes, I do have a situation that has required 24 different actions to match identically-colored text because the ANSI code sequences aren't consistent.

It'd be nice if actions etc. could match a string like
<119>Red
to match bold red on default background or
<818>Red
to match any kind of red text on any background
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Tue May 20, 2014 7:04 pm    Post subject: Reply with quote

Could craft something like:

\e[{1;|}{31}{;1|}m which should match various variants of red.

\e[{1|31};{1|31}m would match 2 variants of bright red.

highlight restores the color state, substitute does not.

Not really interested in adding universal color match support, more so an area where regular expressions should come in handy.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group