Stuart Lee

I like that, I think the code would look more like dplyr if you set width outside the call to `anchor_*` and there's no confusion for how update columns using...

I have renamed ojoin to be `join_overlap_*` so it's consistent with the `join_nearest/follow/precede` family and is differentiated from regular SQL join syntax. Most of these have now been implemented except...

An update on these - I still need to implement the *_includes and *_directed versions of these functions. Should the joins act differently on GroupedRanges?

Just to clarify: - Should all `join` methods return auxilliary granges columns when appropriate? Currently this is how `nearest/precedes/follow` methods works. - I had thought of `join_overlap_inner` as the equivalent...

I've had a go of updating this now. See the latest [intro vignette](http://stuartlee.org/plyranges/articles/01-introduction-plyranges.html#joins-or-another-way-at-looking-at-overlaps-between-ranges).

To summarise our chat today: 1. All joins should just return the metadata from the right hand side ranges, no ranges column. 2. `pair` method should return a left and...

Yep that's a typo on my part

These are finished now, I've implemented the basic `pair_` methods. I just need to write some tests for the joins, especially the outer join method.

Re pairing up it would be useful to have methods to allow for the following: - pairing up ranges for paired end alignments ala the `chop_` methods - unpaing -...

just a note to myself to add in within_directed methods