Apply edits from #46

[zzak]

No description provided.

[zenspider]

You and @ocha- make a damn fine team.

[ocha-]

This is not "unary and minus" but "unary minus."
I think that the "++" operator particularly belongs to the C language in this sentence but "unary minus" is used in a general sense.

Could you fix this?
Or, should I create another pull request for this?

[zzak]

@ocha- Please feel free to submit a patch. Thanks!

[ocha-]

@zzak Then I'll take care of this. Probably I'll also edit the "Options" section to be more precise.

I have one thing I'd like to ask your advice.

"Note:" looks like different from my intention,
so if you don't mind I'd like to remove this.

But if something is needed to be natural as English,
I'd like to use "For instance," instead.

How do you think?

I'm sorry that I'm asking this just to improve my English skill.

[zzak]

@ocha- Let me say, you’ve done a great job translating this documentation!

“For instance,” sounds good.

Feel free to submit any more patches and ping me when you’d like a review :)

On Mar 11, 2014, at 9:27 AM, ocha- notifications@github.com wrote:

In rdoc/en/grammar.en.rdoc:

--
a - (b - c)

When an operator is not allowed to be written in succession like this in the
first place, it is nonassoc.
-++ in C language and unary minus are nonassoc.
+Note: in the C language "++", "unary" and "minus" are nonassoc.
@zzak Then I'll take care of this. Probably I'll also edit the "Options" section to be more precise.

I have one thing I'd like to ask your advice.

"Note:" looks like different from my intention,
so if you don't mind I'd like to remove this.

But if something is needed to be natural as English,
I'd like to use "For instance," instead.

How do you think?

I'm sorry that I'm asking this just to improve my English skill.

—
Reply to this email directly or view it on GitHub.

[ocha-]

@zzak You really helped me a lot :) Thanks in advance for the next time.

[zenspider]

Is there more coming? I want to make sure I keep on top of this.

[ocha-]

I'd like to rewrite the "Options" section just a little.
It is partially because "allow" is probably not the right word,
and also because only that section was a little ambiguous even in the grammer.ja.rdoc.
For instance, it is written as if result_var option can also be overwritten by command-line but I don't think it's possible.

I actually also want to add some sample grammar files for "no_result_var" and "convert".
But of course, it's up to you whether or not to merge the request.

I'd like to do this one by one and I need to take a little more time to create the next patch.
Sorry for my slow pace.

[zenspider]

On Mar 12, 2014, at 13:04, ocha- notifications@github.com wrote:

I'd like to rewrite the "Options" section just a little.
It is partially because "allow" is probably not the right word,
and also because only that section was a little ambiguous even in the grammer.ja.rdoc.
For instance, it is written as if result_var option can also be overwritten by command-line but I don't think it's possible.

I actually also want to add some sample grammar files for "no_result_var" and "convert".
But of course, it's up to you whether or not to merge the request.

I'd like to do this one by one and I need to take a little more time to create the next patch.
Sorry for my slow pace.

No apologies necessary. You're doing us a service, not the other way around. Take your time, and thank you for your help.