Incorrect parsing of "+" in labels, titles and possiblely elsewhere

[seisman]

The trailing "+" in labels and title are missing.

gmt basemap -R0/10/0/5 -Jx1c -Bxaf+l"X+" -Byaf+l"Y+" -BWSen+t"Title+" -pdf map

[PaulWessel]

We can do a better job I think. But inside the code there are no quotes - that is only in the shell - so what GMT sees is WSen+tTitle+ and (except for this case) it can be hard to tell what is a modifier and what is part of the text. My usual solution is to scan the entire argument before parsing and if I find sequences of + that are not among the possible modifiers to that option then replace the + with an unprintable character and then replace those back to + after the parsing. Of course, to catch +tTitle+testing we need to remember that +t was already found and allow that second +t as part of the text, but +tTitle+gravity is harder since +g is a valid option. It is getting pretty messy then to check that ravity is not a color, etc.

[PaulWessel]

The other way to handle this is to escape plus symbols in text: +tTitle+testing which is probably preferable to making people use the octal code for plus: +tTitle\053testing.

[seisman]

It seems there is no easy way to parse "+" correctly. I'm OK with the octal code. Feel free to close this issue.

[PaulWessel]

I am improving it a bit. The missing + in your example is a bug and is being fixed. Also, I am implementing that any repeat + in a string is not a modifier since you cannot repeat a modifier. So that fixes +tTitle+testing for instance. The +tTitle+gravity actually gives

psbasemap [ERROR]: Colorname ravity not recognized!
psbasemap [ERROR]: Bad +g modifier A