quote:
Originally posted by Itsme-HcK
Though, the $group$ variabele was added for my first syntax, where the users could add multiple groups; could be usefull.
You can already do that without the $group$ variable if you simplify your whole syntax and the logic of the plugin. You make it far too complex then actually needed for what you want.
quote:
Originally posted by Itsme-HcK
However, yours doesn't give enough freedom, imho.
It is only the result of leaving all the complex stuff out of your syntax by simplifying the use of it and the logic behind it. The result has even more freedom than the first complex syntax of yours...
That was the whole point of my previous post: that you can greatly simplify stuff without reducing any of the possebilities.
quote:
Originally posted by Itsme-HcK
It should be possible to give an own way of showing it; your way can only show OR the e-mail, OR the name, not both.
That's only a matter of how you design the preference dialog (what I gave was just a simple example). It hasn't got much todo in how you create the syntax or if you use a command or tag or whatever.
quote:
Originally posted by Itsme-HcK
And it should be possible to do that for only ONE statement, and different for the other.
Again, only a matter of how you design the preference screen and also why there are quicktexts. So the user can make his own commands and combinations.
Why making it so complex when there is already a perfect way for the user to make their own output using quicktexts. And quicktexts is what he is going to use anyways, so it would be kind of stupid for not using its capabilities.
quote:
Originally posted by Itsme-HcK
After reconsidering all this; maybe the next one is better:
/xwhois group:"groupname","another one","another two" status:brb,busy mask:online on group $group$: $name$ ($email$) (And maybe more groups or statuses.)
The quotes in the groupname could then just be escaped using the backslash.
The tag would be something like this:
(!XWHOIS_statuses_return value_groupname) (return value being $email$ or $name$ or such.)
Make your parameters consistent. Why using quotes in one parameter, but not in the other one? If a program uses parameters, it is supposed to be done in a consistant way; each parameter should have the exact same set of 'syntax rules'.
And if you make it consistent (and fixed), you'll also will find that you don't need the prefixes anymore either, since each parameter is delimited by a space (as it is standard thruout windows).
But forgot about the command, you only need a tag. As I said in my previous post, you don't need a command at all! The user can create there own commands. And this also means you do not need a $group$, $email$ or $name$ thingie at all.
------------
I only want you to give some advise which prevents making something which possible contains limits, bugs, inconsistancies and a too complex syntax from the start. You are going to experience a lot of coding problems otherwise
(also seeing your other programming question).