Add label_functions for scale_x/y_continuous

[cnrrobertson]

Addresses #69.

Generally, it implements label_number which accepts a variety of basic kwargs about prefix, suffix, decimal and comma marks etc. It also accepts kwargs that are passed directly on to format from Format.jl. It would actually possibly be a good move to upstream some of the new options in label_number into format.

Most of the other label functions make use of label_number and accept kwargs that can be passed through to format. (exceptions to this are label_date which uses Dates.format and label_wrap which doesn't format).

There are a few outstanding TODO comments still listed in the source to try to bring this closer to feature parity with the scales R package (such as supporting timezones in label_date and some other miscellaneous options). Should I leave them there or put them into issues?

I also don't have any examples setup in the docs as I wasn't sure whether to include them in the API like the geom_* functions or in the user guide like scale_x_*.

P.S. Really love what you guys are doing with the Tidier ecosystem and wanted to join the effort. #69 was labelled as a good starting point, so I'm here!

[rdboyes]

Thanks so much for working on this!

For examples/documentation, I would suggest that as a starting point, any "public" functions should have a docstring (like the geoms). This will go into the API page in the docs, and we can eventually add (or you can add, if you want!) a single page that explains the overall set of functions you have added here. @adknudson and @drizk1 have done a lot more than I have to build the docs so if they want to weigh in I'll defer to them though!

I've been trying my best to collect everything that I know of that needs to be done on the package to issues, so if you want to bring all the TODOs into a single issue with a task list, that would be great.

One final thing - can you update your .gitignore to not commit the Manifest.toml file? We just don't need to track it since it's autogenerated by julia and is specific to each person's computer

[rdboyes]

Oh and if you want to discuss anything about this, a good place is the #tidier channel on the julia slack

[drizk1]

I don't have much to add about docs, shoutout to you all for doing the heavy lifting.

My only thought about the docs is to include a couple examples in the getting started/user guide (or to add a new page) (and maybe in the api too) that would be familiar to R users but not directed towards them. I think having something that ppl unfamiliar with ggplot can easily digest and scaffold from is most important (since ggplotters will already have a strong base).

[adknudson]

As far as docs go, API section is just the place where doc strings get automatically added. If you have an example going into more depth of the feature, then it should go under Reference or Tutorials:

• Reference should be for quick usage examples
• Tutorials are for more in-depth explanations

You could add an entry in both, but I think one in Reference should be good enough and easy enough to get started.

As an aside, I generally like this video explaining the "four types of documentation"

• Tutorials
• Discussions
• How-to guides
• Reference