Macro expansion goes wrong depending on argument content

0 votes
asked Aug 28, 2015 in Bug by peter.loborg (360 points)

Hi,

When I try to make a macro to simplify the creation of messages and BES-boxes (to hide and unify the usage of web links and context specific coloring) I stumble on two problems.

Macro arguments cant contain embedded parantesises or comma characters - even if inside paranthesises. Also, if attempting to hide them by submitting a string (using " delimiters) the delimters show up in the expanded result.

Definition:

!define DOCUMENTATION_SERVER //my.server.com/path/
!define DOC_EXTENSION pdf

!definelong SEND(from,to,protocol,message)
from -\ to : [[ http:DOCUMENTATION_SERVER/public_protocols/protocol.DOC_EXTENSION ]] protocol<b>:</b>message
!enddefinelong

When I now write the following all works as expected...

SEND(Alice,Bob,LDAP,lookup)

...I do get the expected message on the form LDAP:lookup.

However, when I add parameters to the message (separating them using ; not to conflict with the , used by the macro) the macro expansion fails to include the right hand parnthesis;

SEND(Alice,Bob,LDAP,lookup(a;b))

...results in a message with the text LDAP:lookup(a;b without the trailing ).

2) Newline in macro argument handled differently in different cases?

If we have a long list of argument to a message we can (using the macro definition above) it is possible to style the arguments using html and even insert a newline:

END(Alice,Bob,LDAP,lookup(<b>aaaaaa</b>=3567;\n  bbbbb=42))

...works as expected, even with the newline in the middle.

But if I do the same using an rnote instead as follows:

!definelong RAISE_ALARM(part,alarmname,message)
rnote over part DIFF_COLOR
  <b>ALARM:</b> <&flag> alarmname
  MSG = message
end note
!enddefinelong

RAISE_ALARM(Bob,ShoudNotHappenError,What is <b>this</b>?\nNewlines are treated differently!)

 

...then the html styling still works but the escaped newline does not work. Is this macro related or related to notes?

Br, Peter      ...and thanks for all good work!

1 Answer

0 votes
answered Aug 29, 2015 by plantuml (295,000 points)
selected Aug 29, 2015 by peter.loborg
 
Best answer

Point 1 has been fixed in last beta https://dl.dropboxusercontent.com/u/13064071/plantuml.jar
You can now have:

@startuml
!define DOCUMENTATION_SERVER //my.server.com/path/
!define DOC_EXTENSION pdf

!definelong SEND(from,to,protocol,message)
from -\ to : [[ http:DOCUMENTATION_SERVER/public_protocols/protocol.DOC_EXTENSION ]] protocol<b>:</b>message
!enddefinelong

SEND(AliceA,Bob,"LDAP",'lookup(a,b)')

@enduml



About point 2, this is not related to macro. There are two kinds of syntaxes in PlantUML:
- monoline syntax : in that case, \n is interpreted as a newline
- multi line syntax : in that case, \n is printed as \n. The idea is that is the user wants a newline, he would use a real carriage return instead of \n

Let's have a concrete example:


@startuml

!definelong RAISE_ALARM(part,alarmname,message)
rnote over part
  <b>ALARM:</b> <&flag> alarmname
  MSG = message
end note
!enddefinelong

!definelong RAISE_ALARM2(part,alarmname,message)
rnote over part : <b>ALARM:</b> <&flag> alarmname\nMSG = message
!enddefinelong

Bob->Alice : hello
RAISE_ALARM(Bob,ShoudNotHappenError,What is <b>this</b>?\nNewlines are treated differently!)
rnote over Bob : example1
rnote over Bob : example2\nline2
rnote over Bob
example3\nline3
end note
RAISE_ALARM2(Bob,ShoudNotHappenError,What is <b>this</b>?\nNewlines are treated differently!)

@enduml


example2 is printed on two lines.
example3 is printed on a single line (mainly because if the user want a real newline, he can use one here).

I agree that this may sound confusing...
You can turn arround this with macro RAISE_ALARM2.

Hope it helps!
 

commented Aug 29, 2015 by peter.loborg (360 points)
Makes perfect sense! Thanks alot for the fix!
The user guide could mention the strict requirements on not leaving any extra space between the string and the commas (intresting error message in this beta :-)). Or the parser could be made a tad more forgiving.

Still - great improvment!

When do we know what of all this will make it into the next release - and when do you plan one?

Br, Peter
...