CG Tags

Statement

Goal

The goal is to implement the tags' logic used by CG in their puzzles' html rendering. Here we only consider two type of tags:
(1) bold, where the opening tag is two <, and the closing one is two >.
(2) variable, where the opening tag is two [, and the closing one is two ].

Since obviously we can't color the output, make the bold tags uppercase and the variable tags lowercase. The remaining text should be unaffected.

Finally, after applying the tags, trim all the consecutive spaces back to one, and strip left and right spaces.

RULES:
(1) Tags can be nested.
(1.1) If two tags are nested, one contains the other (i.e. no partial intersection).
(1.2) The formatting of the nester comes before the formatting of the nested: [\[aA<\<bB>\>cC]\] should yield aaBBcc and not aabbcc. (*)
(2) Tags are grouped lazily: <\<a>\>b>\>c should yield Ab>\>c, and not ABc. (*)
(2.1) As a consequence a tag type can't nest itself and nesting has a maximum depth (of 2 here).

TESTS:
- Tests 1-4 only contain bold formatting.
- Tests 5 is for the trimming of spaces.
- Tests 6-7 introduce nesting and variables
- Tests 8+ can be anything.

NOTE:
(*) Escape characters have been intercalated in the examples to not interfere with the original rendering. They do NOT appear in the tests.

Input

Line 1: An integer n for the number of lines.
Next n lines: A line to apply the tags on.

NOTE: Although tags can span over multiple lines in CG, we will only consider separate lines to not interfere with the multitest approach, i.e. tags DO NOT carry over different lines.

Output

n lines: A line where the tags have being formatted and the spaces trimmed.

Constraints

0 < n < 10
The length of each line is < 256
A line only contains ascii characters.

Example

Input

7
a
a<<b>>
a<<b>>c
a<<bc>>de
aA<<bB>>cC
<<b>>c
<<b>>

Output

a
aB
aBc
aBCde
aABBcC
Bc
B

Tags

String manipulation, Parsing

Difficulty

Medium

Test cases

1. Simple tags Test

Input

7 a a<> a<>c a<<bc>>de aA<<bB>>cC <>c <>

Output

a aB aBc aBCde aABBcC Bc B

1. Simple tags val Validator

Input

7 a a<> a<<bbb>>c a<<bcde>>fg aAa<<bBb>>cCc <>c <<bAb>>

Output

a aB aBBBc aBCDEfg aAaBBBcCc Bc BAB

2. Incomplete Test

Input

8 >> << a>>b a<>c>>d a<<b<<c>>d a>> <<a

Output

>> << a>>b a<>d aB<<Cd a>> <<a

2. Incomplete val Validator

Input

8 >> << aAa>>bBb a<<bbb a<>c>>ddd a<<bbb<<c>>d a>> <<aaa

Output

>> << aAa>>bBb a<<bbb aBc>>ddd aBBB<<Cd a>> <<aaa

3. Multiple Test

Input

5 <<a>>b<<c>> a<>c<<d>>e a<<b<<c>>d>>e a<<<>>>c a<<b<<c<<d>>e>>f>>g

Output

AbC aBcDe aB<<Cd>>e a<>c aB<<C<<De>>f>>g

3. Multiple val Validator

Input

5 <<a>>bBb<<c>> a<>cCc<<d>>e a<<b<<c>>d>>e a<<<<bBb>>>>c AAa<<b<<c<<d>>e>>f>>g

Output

AbBbC aBcCcDe aB<<Cd>>e a<<BBB>>c AAaB<<C<<De>>f>>g

4. Edge cases Test

Input

5 <> >< <<a> <<a>b>> <a>

Output

<> >< AB <a>

4. Edge cases val Validator

Input

5 <> >< <<a<bBb>> <<aAa>b>> <aAa>

Output

<> >< A<BBB AAA>B <aAa>

5. Trimming and stripping Test

Input

3 this IS soMe << teXt >>. This has <<spaces>> left and right. A n d t h e << l a s t >>.

Output

this IS soMe TEXT . This has SPACES left and right. A n d t h e L A S T .

5. Trimming and stripping val Validator

Input

3 this IS soMe MORE << Text>>. THIS has <<spaCes>> left and right. A n d t h e << l a s t >> v a l.

Output

this IS soMe MORE TEXT. THIS has SPACES left and right. A n d t h e L A S T v a l.

6. Nesting Test

Input

7 <<a[[B]]c>> <<a[[bBb]]c>> [[A<>C]] a<<b[[c]]d>>e a<<bBb[[CcC]]dDd>>e a[[B<<c>>D]]e <<Next [[n_lines]] lines:>> do weirD things

Output

AbC AbbbC aBc aBcDe aBBBcccDDDe abCde NEXT n_lines LINES: do weirD things

6. Nesting val Validator

Input

7 <<a[[Z]]c>> <<aa[[bBb]]cc>> [[A<>C]] aAa<<b[[c]]d>>e a<<bBb[[CcC]]dDd>>e a[[B<<cCc>>D]]eEe <<Next [[n_lines]] lines:>> do Normal things

Output

AzC AAbbbCC aBc aAaBcDe aBBBcccDDDe abCCCdeEe NEXT n_lines LINES: do Normal things

7. Edge cases 2 Test

Input

6 <<a[[B>> <<a]]B>> [[A<<b]] [[A>>b]] [<a>] <[a]>

Output

A[[B A]]B a<>b [<a>] <[a]>

7. Edge cases 2 val Validator

Input

6 <<aAa[[BbB>> <<a]]B>> [[A<<bBb]] [[A>>b]] [<aBc>] <[abC]>

Output

AAA[[BBB A]]B a<<bbb a>>b [<aBc>] <[abC]>

8. Inception Test

Input

2 <<Line 1:>> An integer [[n]] for the number of lines. <<Next [[n]] lines:>> A line to apply the tags on.

Output

LINE 1: An integer n for the number of lines. NEXT n LINES: A line to apply the tags on.

8. Inception val Validator

Input

2 <<Next [[n]] lines:>> A line to apply the tags on. <<Line 1:>> An integer [[n]] for the number of lines.

Output

NEXT n LINES: A line to apply the tags on. LINE 1: An integer n for the number of lines.

9. The Fall - Episode 3 Test

Input

9 << Line 1 :>> 2 space separated integers [[W]] [[H]] specifying the width and height of the grid. <<Next [[H]] lines:>> Each line represents a line in the grid and contains [[W]] space separated integers [[T]]. [[T]] specifies the type of the room. <<If [[T]] is negative, the room cannot be rotated>>. <<Last line:>> 1 integer [[EX]] specifying the coordinate along the X axis of the exit (always at the very bottom of the grid). Input for one game turn <<Line 1>> : [[XI YI POSI]] ([[XI, YI]]) two integers to indicate Indy's current position on the grid. [[POSI]] a single word indicating Indy's entrance point into the current room: TOP if Indy enters from above, LEFT if Indy enters from the left and RIGHT if Indy enters from the right. <<Next line:>> [[R]] an integer representing the number of rocks currently in the grid. <<Next [[R]] lines:>> each line represents the position of a rock on the grid: [[XR YR POSR]] (same rules as Indy's XI YI POSI).

Output

LINE 1 : 2 space separated integers w h specifying the width and height of the grid. NEXT h LINES: Each line represents a line in the grid and contains w space separated integers t. t specifies the type of the room. IF t IS NEGATIVE, THE ROOM CANNOT BE ROTATED. LAST LINE: 1 integer ex specifying the coordinate along the X axis of the exit (always at the very bottom of the grid). Input for one game turn LINE 1 : xi yi posi (xi, yi) two integers to indicate Indy's current position on the grid. posi a single word indicating Indy's entrance point into the current room: TOP if Indy enters from above, LEFT if Indy enters from the left and RIGHT if Indy enters from the right. NEXT LINE: r an integer representing the number of rocks currently in the grid. NEXT r LINES: each line represents the position of a rock on the grid: xr yr posr (same rules as Indy's XI YI POSI).

9. Haunted manor val Validator

Input

7 << Line 1>>: Three integers [[vampireCount]], [[zombieCount]], [[ghostCount]], the number of each type of monster in the grid. <<Line 2>>: One integer [[size]], the number of cells in each row/column of the grid. <<Line 3>>: [[size]] integers, each for the number of visible monsters from the top of the grid, from left to right. <<Line 4>>: [[size]] integers, each for the number of visible monsters from the bottom of the grid, from left to right. <<Line 5>>: [[size]] integers, each for the number of visible monsters from the left of the grid, from top to bottom. <<Line 6>>: [[size]] integers, each for the number of visible monsters from the right of the grid, from top to bottom. <<Next [[size]] lines:>> A string containing [[size]] characters. {{.}} containing one of the monsters. {{\}} or {{/}} for a mirror.

Output

LINE 1: Three integers vampirecount, zombiecount, ghostcount, the number of each type of monster in the grid. LINE 2: One integer size, the number of cells in each row/column of the grid. LINE 3: size integers, each for the number of visible monsters from the top of the grid, from left to right. LINE 4: size integers, each for the number of visible monsters from the bottom of the grid, from left to right. LINE 5: size integers, each for the number of visible monsters from the left of the grid, from top to bottom. LINE 6: size integers, each for the number of visible monsters from the right of the grid, from top to bottom. NEXT size LINES: A string containing size characters. {{.}} containing one of the monsters. {{\}} or {{/}} for a mirror.

Solution language

Solution

Stub generator input

Comments

8 Comments

CodinBot Unnamed CodinGamer

almost 3 years ago

I hope you received enough feedback from the community to improve your contribution. Once you have made the necessary updates, publish your contribution!

LaurentBouvier Unnamed CodinGamer

Great work!

5DN1L Unnamed CodinGamer

Goal * Apparently you can use <<<<bold>>>> to show the "<" and ">" 😂 * The variable one is trickier; the best I can do is [ [ [[variable]] ] ], with the extra space characters lying in between… 🤔 * I've also tried {{<<}}<<bold>>{{>>}} and {{[[}}[[variable]]{{]]}}, but the results are weird… 🤔 Also, if a variation of this is to be used, then please format other <, >, [ and ] as {{constants}} where appropriate (but I guess this is a rare instance where constant formatting is not suggested). * I haven't tried to reformat rule (1.2), but maybe you'll have an idea of what to try now? * Rule 1.2: The notions of "nester" and "nested" looks unclear… Maybe rewrite as follows? Inner tags have a higher priority of formatting than outer tags. Input * Suggest to add " Every line is an independent case." to the Line 1 description, and delete the note (the note is slightly confusing to me and I have to read it a few times to understand what you're trying to say). Cases * Suggest to add a pair of cases of trimming of spaces inside a variable tag (e.g. [[ H ]], [[XI YI POSI]]), similar to Pair 5. Cover picture * Suggest to upload a cover picture for the puzzle. Thanks.

Oh, I'm able to find a zero-width space character and use it here (copy and paste the whole thing): [[ [[variable]] ]] Source (at the end of the article): https://www.groovypost.com/... EDIT: I guess you can replace the visible space characters with zero-width ones too.

Rafarafa Unnamed CodinGamer

The statement is a bit awkward since I obviously can't use the proper << and >> tags for the descriptions. Not very happy with the statement, feedback appreciated. Probably needs more tests.

jddingemanse Unnamed CodinGamer

Already an upvote, because I like the idea and your implementation of it. As for the problem of wanting to explain the tag parameters in the statement while you cannot cancel that they are rendered: what if you pick other tag parameters, for example **bold** and ||variable||? For the rules, can you include a small example of 1.2?