On Fri, Feb 5, 2010 at 9:41 AM, George Locke
<george.locke.phys...@gmail.com> wrote:
>
> Hey,
>
> So I found workaround for what I'm now pretty sure is a bug.
>
> the reason I'm sure it's a bug is that i found that I found that
> linebreaks are handled in a wonky but regular way. There's a rule,
> and it's a bad rule, ie a bug.
If only this were true :P
In every programming language there are plenty of bad rules that will
never be changed because it would break a *very large* amount of
existing code that has been written to work under the rule. They
should never be referred to as bugs-- most people use the term
"feature" and add a healthy layer of sarcasm to emphasize their
contempt for the design decision that led to the rule.
>
> The wonky rule is as follows: text(x,y,expression(paste("thing1
> \n","thing2"))) results in printing thing1 at the requested x/y with
> the linebreak failing to cause a carriage return. That is, thing2
> appears directly below the "1" in thing1.
I think this has to do with your call to expression() wrapping the
paste() command. For example:
text( x, y, paste( "thing1\n", "thing2") )
Plots two lines of text quite nicely. Using expression() around your
paste indicates to R that the text to be plotted should be interpreted
as a mathematical expression. The help page for this behavior,
?plotmath, states:
"Control characters (e.g. \n) are not interpreted in character
strings in plotmath, unlike normal plotting."
So, "\n" is not supported inside an expression() -- trying to use it
produces weird results.
Hope this clarifies things!
-Charlie
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
