Agreed, but multiple lines without indentation is even worse, and every implementation of tab indentation I've seen in WoW has been buggy to the point of being unusably annoying.
If FAIAP's on-the-fly indenting doesn't work well enough, consider an applescript-like reindent on 'compile'.
FAIAP, when I tried it some months back, periodically inserted spaces as I was typing, and didn't indent by any consistent amount.
Anyway, if real on-the-fly indenation isn't possible in-game, then there's not really any purpose to having a multi-line input for DogTags, especially with a verbose syntax. For example...
if X then
if A then
B
end
elseif Q and R then
if Z then
Y
else
F
end
else
M
end
...isn't particularly readable. It would be much easier to read (not to mention shorter) as:
Your propoasl:
if IsDeadOrGhost then return Color(Status, "aaaaaa") else if SureHP then if IsFriend then if MissingHP ~= 0 then return Short(CurHP) .. " " .. Color("- " .. Short(MissingHP), "ffaaaa") else return Short(CurHP) end else return Short(CurHP) .. " (" .. Floor(PercentHP) .. "%)" end else if PercentHP ~= 100 then return Floor(PercentHP) .. "%" end end end
Which one is easier to read and understand on one line?
The "if then else end" thing is ugly as sin, but still easier to read and understand (for me) than the current way. If it has to be in one line, I would not remove the brackets, tho. If indentation is possible, then no need for brackets, if it is not, then brackets help with readability.
The times I used Dog Tags I have managed to get te result I wanted looking at the Wiki. Butfor me the ultimate solution would be some kind of GUI wrapper or GUI DogTag builder.
From such a thing you would be able to select all current Dog Tags options, parameters and color etc. When you hit submit if will spit out the formatting in a window below. You can repeat the selection steps of elements until you have the whole formatting you want and just copy it into the other ace programs that supports them.
I would love to see this as a standalone addon. But even nicer would be some sort of icon you can click beside the place you can type the code. Dog Tags builder window would pop up. And with every submit or final submit it would place/fill in the code into the ace program just like you did it by hand.
Benefits:
-You don't have to worry about anyone else idea of formatting you own code/syntax.
-No one else needs to worry about the code/syntax because the program spits it out correctly
But ofc I know nothing about lua. And don't know if this is even possible.
The times I used Dog Tags I have managed to get te result I wanted looking at the Wiki. Butfor me the ultimate solution would be some kind of GUI wrapper or GUI DogTag builder.
From such a thing you would be able to select all current Dog Tags options, parameters and color etc. When you hit submit if will spit out the formatting in a window below. You can repeat the selection steps of elements until you have the whole formatting you want and just copy it into the other ace programs that supports them.
I would love to see this as a standalone addon. But even nicer would be some sort of icon you can click beside the place you can type the code. Dog Tags builder window would pop up. And with every submit or final submit it would place/fill in the code into the ace program just like you did it by hand.
Benefits:
-You don't have to worry about anyone else idea of formatting you own code/syntax.
-No one else needs to worry about the code/syntax because the program spits it out correctly
But ofc I know nothing about lua. And don't know if this is even possible.
GL and thx :)
If you use LibDogTag-2.0 as an external (Like a normal addon inside your Addons folder) you can type /dogtag and there's a similar system to the one you described =)
Not really... the /dogtag window just includes descriptions for all tags/modifiers, and a "sandbox" where you can type in a tag and see the effect. What iluran is describing is more along the lines of a WYSIWYG editor, like the forum post editor, where instead of typing the [b] tags for bold text, you just click a button and it's inserted for you. For DogTag, I'd guess this would work by having all the health-related tags in a dropdown, and when you clicked, say, "Missing Health" in the menu, the [MissingHP] tag would appear. You could then click on the tag to add modifiers ("Show if not zero" -> :HideZero and "Color by class" -> :ClassColor). Something like that would probably be okay for simple sequences, but for complex sequences with nested conditionals, it would probably not be very helpful. Thus I don't think an editor like this would be very helpful, since the kind of sequences it would work best with are the kind that are already included as default choices in addons like PitBull (under Health Text there are, for example, "Short", "Informational", "Missing", and many others). If users want to edit such a simple sequence -- let's say you want to recolor the missing health by class -- it doesn't really make sense to load such a monstrosity of code as such an editor would surely be, when the user could simply spend a few seconds using his/her brain to read the help text and go "okay, I need to change :Red to :ClassColor" and do it.
...imo, a WYSIWYG editor would be nice.. but as Phanx points out would be a bitch of an addon to load.. so make it LoD. only use it once or 2wice and then leave it disabled... Maybe even a web form that could do that would be awesome.
use english for the syntax, tags are generally fine. The biggest change you could make that would help me is some in game way to view the different commands... my biggest problem with the systemare twofold.
1. Finding correct syntax for if/then/else/and/or type statements.
2. Having to go to the wiki to find the tag that i'm looking for.
use english for the syntax, tags are generally fine. The biggest change you could make that would help me is some in game way to view the different commands... my biggest problem with the systemare twofold.
1. Finding correct syntax for if/then/else/and/or type statements.
2. Having to go to the wiki to find the tag that i'm looking for.
Maybe dropdowns or something?
For probably the tenth time this thread, in-game documentation already exists. Type /dog or hit any of the "DogTag help" buttons you'll find in PitBull or CowTip wherever you can configure DogTags.
What i still find confusing are these very very very long sequences
of dogtags. Like said more than once in this thread:
allow multiline input
allow indenting
more verbose statements and propper syntax for decision trees,
namely a more shell script like syntax
if ( boolean true / false ) then
do stuff in case above was boolean true
else
do stuff in case above was boolean false
fi
Also, since i understand dogtags to be a way for: a) getting information (hp, race, class) and b) formating this info (in class color, red)
i'm missing a clear distinction between these two things in
the syntax.
Also, please do away with multiple syntax for doing the same,
i'm all for using only function like stuff to format output, no
piping like used in unix systems, mixing both make reading and
writing difficult.
1. How would you propose that "data" and "formatting" tags be distinguished? And why do they need to be distinguished? If you can't figure out that [MaxHP] provides information and [Red] provides formatting, I don't know what to tell you.
2. What "mixing" are you talking about? And maybe [Color(Short(Hide([CurMP], [MaxMP])), [HPColor])] is easier for you to read, but I find [CurMP:Hide([MaxMP]:Short:HPColor] much easier, and I'm guessing the majority of non-programming users probably do too. There's no reason they can't work both ways. Then if you want to use modifier(tag) instead of tag:modifier, you're welcome to do so, and those that find piping easier can use piping.
I'm still against the verbose "if" "then" "else" "end" syntax for DogTag, though, unless you guys can figure out a way to support actual indentation in-game without resorting to inconsistent and spastic space insertion. :(
Maybe i'm using the wrong words since i'm not an native speaker, sorry.
[MaxHP] - The maximum health for the unit
This is - in my small world - purely data, an integer and nothing formated. Formating for me is (in example) coloring stuff or adding '%' and hiding '0'(Zero).
And yes, i find the version with functions easier to read, piping is
a concept in the unix world and it's very powerfull. Problem is, what
would the user find easier? Maybe it's just me and maybe it's because
of what i do at work. The concept of piping inside pseudocode
and mixing this with function calls, this is what i find hard to read.
Since ckknight has started coding LibDogTag-3.0 and things are (somewhat) finalized, here are the decisions that have been made. They are still open to discussion if anyone has any objections, but I think that these solutions should work for pretty much everyone.
Multi-line support has been implemented in the parser. Multi-line config implementations have not been written yet, but are planned.
Concatenation is done by juxtaposition, and does not automatically add a space (since [Tag " " OtherTag] can be used for that). Note that there is now a difference between [Alpha(Bravo)] and [Alpha (Bravo)] - the extra space in between will cause the parser to concatenate the returns of Alpha and Bravo, rather than evaluating Alpha with Bravo as an argument.
Literal strings must be in quotes (either ' or " may be used). No DogTag parsing occurs within these strings, so it's safe to do things like [(HasSoulstone ? "[SS] ") Name] that were not possible with [Text()] - which, by the way, will be removed.
Conditionals will support if/then/else syntax as well as ?/!. That way everyone can use the syntax they prefer.
Order of operations can be controlled using (), [], or {}. Because of this, there is no "end" keyword; by default, else blocks will be parsed as belonging to the last preceding if without an else block.
Logic operators and, or, and their symbol equivalents & and | will be implemented. Negation can be accomplished with not as well as the current ~.
Tags can now have multiple arguments - new tags may take advantage of this in the future. Modifiers will support both the current modifier syntax, i.e. [Tag:Modifier(optionalArg)], and a tag syntax i.e. Modifier(Tag, optionalArg).
Some basic example tags using different syntax styles:
[Visible & ~Status ? MinRange "-" MaxRange] could also be written as [if Visible and not Status then MinRange "-" MaxRange]
[CurHP < 2000 ? CurHP:Color(ff0000) ! PercentHP:Percent] could also be written as [if IsLess(CurHP, 5000) then Color(CurHP, ff0000) else Percent(PercentHP)]
Literal strings must be in quotes (either ' or " may be used). No DogTag parsing occurs within these strings, so it's safe to do things like [(HasSoulstone ? "[SS] ") Name] that were not possible with [Text()] - which, by the way, will be removed.
Not a huge deal, but can [Text("blabla") remain as an alternative to just "blabla"? Personally I think it's be much cleaner and make it easier to distinguish literal text from tags.
Quote from Ellipsis »
Order of operations can be controlled using (), [], or {}. Because of this, there is no "end" keyword; by default, else blocks will be parsed as belonging to the last preceding if without an else block.
Will I be required to use [ ( { } ) ] or can I still use [ [ [ ] ] ] ?
Literal strings must be in quotes (either ' or " may be used). No DogTag parsing occurs within these strings, so it's safe to do things like [(HasSoulstone ? "[SS] ") Name] that were not possible with [Text()] - which, by the way, will be removed.
How will modifiers be used with literal strings? Would "myText":Red work?
Not a huge deal, but can [Text("blabla") remain as an alternative to just "blabla"? Personally I think it's be much cleaner and make it easier to distinguish literal text from tags.
Well, there's not much point to it, but why not, I guess. :) I'll see if I can get that included.
Quote from Phanx »
Will I be required to use [ ( { } ) ] or can I still use [ [ [ ] ] ] ?
You can use whatever you want, wherever you want, when it comes to order of operations (as long as the opening and closing brackets match, of course). [] will still be used for tags and () for arguments.
You can certainly use the current nested [] if you like. Someone addicted to C might prefer {}, and more mathy types might like (). Some may even want to mix and match (to [make {nesting} clearer]). We aim to please as many people as possible.
Quote from pqee »
How will modifiers be used with literal strings? Would "myText":Red work?
Indeed, that should work exactly as you'd expect it to. Quoted strings are nice, huh? :)
Just a thought about the UI : maybe some option to reformat a tag in short form could be useful, and the same thing apply to reformat in verbose form. (Given that the parser is already written, it shouldn't be too hard.)
Umm...ever looked at the in-game documentation (/dog)? Is there anything that you think could be improved there?
PS@Phanx: great points/suggestions all around. My babies, will you have them?
The wall-of-color in the documentation actually makes it more difficult for me to read and find what I need. Syntax highlighting is great for the examples, but it makes the preceding explanation more difficult to follow. Restricting highlighting to just the examples (or to just the initial definition) might be something to consider.
Also, there are no labels for the "sandbox" controls at the bottom. It's not immediately obvious what they are or how to use them.
Another design change that might make the documentation easier to browse would be moving the categories (Syntax, Tags, Modifiers) to the left side of the window, with a subcategory for every tag or modifier. This would serve as a kind of index, making them easier to browse, and would provide more room for examples for each tag or modifier in the definition frame.
For Color(CurHP, ff0000) would the "ff0000" need to be in quotes?
Oops, yeah, it would.
Quote from Adirelle »
Just a thought about the UI : maybe some option to reformat a tag in short form could be useful, and the same thing apply to reformat in verbose form. (Given that the parser is already written, it shouldn't be too hard.)
The parser will simplify tags a bit when doing its thing - it won't figure out huge things like [Alpha ? Bravo][~Alpha ? Charlie] being equivalent to [Alpha ? Bravo ! Charlie], but things like [Alpha][Bravo][Charlie] will turn into [Alpha Bravo Charlie], since that's how the parser understands them anyway.
Quote from Nandini »
The wall-of-color in the documentation actually makes it more difficult for me to read and find what I need. Syntax highlighting is great for the examples, but it makes the preceding explanation more difficult to follow. Restricting highlighting to just the examples (or to just the initial definition) might be something to consider.
Also, there are no labels for the "sandbox" controls at the bottom. It's not immediately obvious what they are or how to use them.
Another design change that might make the documentation easier to browse would be moving the categories (Syntax, Tags, Modifiers) to the left side of the window, with a subcategory for every tag or modifier. This would serve as a kind of index, making them easier to browse, and would provide more room for examples for each tag or modifier in the definition frame.
Good suggestions, and an interesting perspective on the color issue. I'll see if I can come up with a more intuitive design for the help frame; the sandbox may be split off into a separate frame if it goes multi-line. I'll make sure it gets clearly labeled, though. :)
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf FAIAP's on-the-fly indenting doesn't work well enough, consider an applescript-like reindent on 'compile'.
Anyway, if real on-the-fly indenation isn't possible in-game, then there's not really any purpose to having a multi-line input for DogTags, especially with a verbose syntax. For example...
if X then
if A then
B
end
elseif Q and R then
if Z then
Y
else
F
end
else
M
end
...isn't particularly readable. It would be much easier to read (not to mention shorter) as:
[X ? [A ? B] ! Q & R ? [Z ? Y ! F] ! M ]
The times I used Dog Tags I have managed to get te result I wanted looking at the Wiki. Butfor me the ultimate solution would be some kind of GUI wrapper or GUI DogTag builder.
From such a thing you would be able to select all current Dog Tags options, parameters and color etc. When you hit submit if will spit out the formatting in a window below. You can repeat the selection steps of elements until you have the whole formatting you want and just copy it into the other ace programs that supports them.
I would love to see this as a standalone addon. But even nicer would be some sort of icon you can click beside the place you can type the code. Dog Tags builder window would pop up. And with every submit or final submit it would place/fill in the code into the ace program just like you did it by hand.
Benefits:
-You don't have to worry about anyone else idea of formatting you own code/syntax.
-No one else needs to worry about the code/syntax because the program spits it out correctly
But ofc I know nothing about lua. And don't know if this is even possible.
GL and thx :)
If you use LibDogTag-2.0 as an external (Like a normal addon inside your Addons folder) you can type /dogtag and there's a similar system to the one you described =)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1. Finding correct syntax for if/then/else/and/or type statements.
2. Having to go to the wiki to find the tag that i'm looking for.
Maybe dropdowns or something?
For probably the tenth time this thread, in-game documentation already exists. Type /dog or hit any of the "DogTag help" buttons you'll find in PitBull or CowTip wherever you can configure DogTags.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumof dogtags. Like said more than once in this thread:
Also, since i understand dogtags to be a way for:
a) getting information (hp, race, class) and
b) formating this info (in class color, red)
i'm missing a clear distinction between these two things in
the syntax.
Also, please do away with multiple syntax for doing the same,
i'm all for using only function like stuff to format output, no
piping like used in unix systems, mixing both make reading and
writing difficult.
just my 2 cent
1. How would you propose that "data" and "formatting" tags be distinguished? And why do they need to be distinguished? If you can't figure out that [MaxHP] provides information and [Red] provides formatting, I don't know what to tell you.
2. What "mixing" are you talking about? And maybe [Color(Short(Hide([CurMP], [MaxMP])), [HPColor])] is easier for you to read, but I find [CurMP:Hide([MaxMP]:Short:HPColor] much easier, and I'm guessing the majority of non-programming users probably do too. There's no reason they can't work both ways. Then if you want to use modifier(tag) instead of tag:modifier, you're welcome to do so, and those that find piping easier can use piping.
I'm still against the verbose "if" "then" "else" "end" syntax for DogTag, though, unless you guys can figure out a way to support actual indentation in-game without resorting to inconsistent and spastic space insertion. :(
-
View User Profile
-
View Posts
-
Send Message
Curse Premium[MaxHP] - The maximum health for the unit
This is - in my small world - purely data, an integer and nothing formated.
Formating for me is (in example) coloring stuff or adding '%' and hiding '0'(Zero).
And yes, i find the version with functions easier to read, piping is
a concept in the unix world and it's very powerfull. Problem is, what
would the user find easier? Maybe it's just me and maybe it's because
of what i do at work. The concept of piping inside pseudocode
and mixing this with function calls, this is what i find hard to read.
Some basic example tags using different syntax styles:
[Visible & ~Status ? MinRange "-" MaxRange] could also be written as [if Visible and not Status then MinRange "-" MaxRange]
[CurHP < 2000 ? CurHP:Color(ff0000) ! PercentHP:Percent] could also be written as [if IsLess(CurHP, 5000) then Color(CurHP, ff0000) else Percent(PercentHP)]
Not a huge deal, but can [Text("blabla") remain as an alternative to just "blabla"? Personally I think it's be much cleaner and make it easier to distinguish literal text from tags.
Will I be required to use [ ( { } ) ] or can I still use [ [ [ ] ] ] ?
How will modifiers be used with literal strings? Would "myText":Red work?
Well, there's not much point to it, but why not, I guess. :) I'll see if I can get that included.
You can use whatever you want, wherever you want, when it comes to order of operations (as long as the opening and closing brackets match, of course). [] will still be used for tags and () for arguments.
You can certainly use the current nested [] if you like. Someone addicted to C might prefer {}, and more mathy types might like (). Some may even want to mix and match (to [make {nesting} clearer]). We aim to please as many people as possible.
Indeed, that should work exactly as you'd expect it to. Quoted strings are nice, huh? :)
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe wall-of-color in the documentation actually makes it more difficult for me to read and find what I need. Syntax highlighting is great for the examples, but it makes the preceding explanation more difficult to follow. Restricting highlighting to just the examples (or to just the initial definition) might be something to consider.
Also, there are no labels for the "sandbox" controls at the bottom. It's not immediately obvious what they are or how to use them.
Another design change that might make the documentation easier to browse would be moving the categories (Syntax, Tags, Modifiers) to the left side of the window, with a subcategory for every tag or modifier. This would serve as a kind of index, making them easier to browse, and would provide more room for examples for each tag or modifier in the definition frame.
Oops, yeah, it would.
The parser will simplify tags a bit when doing its thing - it won't figure out huge things like [Alpha ? Bravo][~Alpha ? Charlie] being equivalent to [Alpha ? Bravo ! Charlie], but things like [Alpha][Bravo][Charlie] will turn into [Alpha Bravo Charlie], since that's how the parser understands them anyway.
Good suggestions, and an interesting perspective on the color issue. I'll see if I can come up with a more intuitive design for the help frame; the sandbox may be split off into a separate frame if it goes multi-line. I'll make sure it gets clearly labeled, though. :)