Make </> close latest open tag in the tree

[imDaniX]

I've been using a similar to MM format recently, and it had syntax like this <first>First <second>first+second</> still first</> plain, which was actually pretty handy to use.
While it might sometimes be confusing when used in a very nested scenario, it removes a burrow to type long tags multiple times just to close them, doesn't hurt in linear cases, and is easier to look at when multiple hex colors are used.

A simple use-case

<aqua><click:open_url:'https://youtu.be/dQw4w9WgXcQ'><bold>Click the message</bold> to get a <#f4ff2>bonus</#f4ff2>!</click></aqua>
<aqua><click:open_url:'https://youtu.be/dQw4w9WgXcQ'><bold>Click the message</> to get a <#f4ff2>bonus</>!</></>

Another

<#d0d0d0><#f0f0a0>ⓘ</#f0f0a0> <underlined>You've got a <#a0a0f0>new hat</#a0a0f0>!</underlined><newline>Now, head into <#a0f0a0>a wardrobe</#a0f0a0> to wear it.
<#d0d0d0><#f0f0a0>ⓘ</> <underlined>You've got a <#a0a0f0>new hat</>!</><newline>Now, head into <#a0f0a0>a wardrobe</> to wear it.

Russian proverb for remembering the colors of the rainbow (yeah, our rainbow is a bit different lol)

<red>Каждый</red> <gold>охотник</gold> <yellow>желает</yellow> <green>знать</green>, <aqua>где</aqua> <blue>сидит</blue> <dark_purple>фазан</dark_purple>
<red>Каждый</> <gold>охотник</> <yellow>желает</> <green>знать</>, <aqua>где</> <blue>сидит</> <dark_purple>фазан</>

[kezz]

I'm actually not really a fan of this. I think it makes the format look messy and introduces a kinda lack of clarity. Would be interested to hear what others think.

[CubBossa]

I am working on an Intellij plugin and already ran into issues with the syntax, since xml uses ':' for namespaces while MiniMessage uses it to separate args. When defining xml based languages there are a lot of features like tag matching and synchronization and highlighting that work based on the tag name, which would not be found in </>. A lot would need to be rewritten just to support that closing tag while moving MiniMessage further away from well formed xml.

And also if you don't like the </red>, for your example you could leave it and it'd still look the same

[imDaniX]

I'm actually not really a fan of this. I think it makes the format look messy and introduces a kinda lack of clarity. Would be interested to hear what others think.

The problem is that sometimes MiniMessage requires you to write like 2x the text you wrote, which is kinda frustrating without using the WebUI. And even with WebUI it becomes quite a routine to copy-paste text over and over.
As for readability, for me it's harder to look at the second example in vanilla MiniMessage format.

The examples in the initial post aren't perfect - I just wanted to show it for better understanding of a concept. I'd say the best use of </> would be to close tags with small portions of text, while leaving nested or long text blocks as-is. Something like

<aqua><click:open_url:'https://youtu.be/dQw4w9WgXcQ'><bold>Click the message</> to get a <#f4ff2>bonus</>!</click></aqua>

seems quite good-looking, but that's just an imho.

[imDaniX]

I am working on an Intellij plugin and already ran into issues with the syntax, since xml uses ':' for namespaces while MiniMessage uses it to separate args. When defining xml based languages there are a lot of features like tag matching and synchronization and highlighting that work based on the tag name, which would not be found in </>. A lot would need to be rewritten just to support that closing tag while moving MiniMessage further away from well formed xml.

I mean, as you've already mentioned, MiniMessage is already not XML compatible. I don't see it as an issue with MiniMessage.

And also if you don't like the </red>, for your example you could leave it and it'd still look the same

That's just one case out. But it will colorize the comma in the middle of the sentence (which is obviously fixable, but will look quite weird).

[zml2008]

Whatever the decision here, I don't think "ease of writing an intellij language plugin" should be a deciding factor.

I do like giving options to shorten the language, but I feel like it could get confusing which tag is being closed, and i'm not sure if adding more options helps or hurts overall.

[CubBossa]

I did not mean to bring the "ease of writing an intellij language plugin" as an argument but wanted to emphasize that it has advantages to stay close to XML. XML is an absolute standard thats used for so many things but i don't know of any dialect that includes </> tags.

HTML is a dialect thats pretty close to MiniMessage, since it serves the same purpose of formatting raw text. Still, they explicitly close tags and don't use </>. And with that being standard in software development and software like intellij being designed for explicitly closed tags I would not add this feature.

A pretty easy way to shorten the language and that I use within my code is a table with rules like
a = <red><hover:...><click:...><slot/></click></hover></red>
to introduce <a> as a shorter tag.

MiniMessage is the language definition and parser while further software could add things like that.

[kezz]

A pretty easy way to shorten the language and that I use within my code is a table with rules like
a = <red><hover:...><click:...><slot/></click></hover></red>
to introduce <a> as a shorter tag.

Yes, I think this is the reason why I'm mostly against </> tags. They generally stink of bad design (you should probably most often be abstracting big chunks of text out into other tags or language strings anyway).

[imDaniX]

A pretty easy way to shorten the language and that I use within my code is a table with rules like
a = <red><hover:...><click:...><slot/></click></hover></red>
to introduce <a> as a shorter tag.

But that's the developer side of things, not the user one. Custom tags are cool and stuff, but are not doable without some configurable implementation of those by a developer. And while configurable tag-placeholders are easy to implement, I can't say so for styling ones without some weird workarounds.

you should probably most often be abstracting big chunks of text out into other tags or language strings anyway

That's the thing - </> will help in short chunks of texts, not the big ones.

[CubBossa]

Okay maybe this one will convince you: using <red></red> makes it readable from both directions. Since MiniMessage is mostly used for oneliners thats great because you can be e.g. somewhere at the end of message with cursor. You then see </click> and can make the connection to the earlier opened click section that frames the whole command suggestion part within your line. If instead reading a </> you gotta jump to the first part of content that is identifiable as some specific part of the message. So the closing tags actually help a lot in readability but are a bit more verbose on the downside

[MiniDigger]

this is the typical easier to write vs easier to read kinda stuff, you read stuff way more often than you are writing it, so I don't see a reason to sacrifice the readability here.
I do see it being dum with hex colors however, since you have to repeat the color code, so you have to change it in two locations if you change it, so maybe those tags could be closed with (since <#ff0000> is a short hand for color:#ff0000) or maybe </#>?

[CubBossa]

I thought about it because I made a translation file framework based on MiniMessage. What I chose instead was having more "functional" tags, like <text>, <url> or <primary> for the brand color e.g.. All based on the table I mentioned earlier. With that approach I don't see a reason to shorten hex tags at all, since you almost never use them, only once in your style sheet.
I think its kinda where the whole styling of minecraft plugins should develop to. Just like how markup usually works. Plugin declares text as a list entry or a list header or a heading or url and server owner decides in style sheet how his or her server is supposed to render these. Without replacing hundreds of tags in various message.yml or message.properties files.

primary = "<#ffaaaa><slot/>"
url = "<blue><ul><hover:...><click:...><slot/>"

my.message =" <url>https://my.server.url/<url>"