Arvind Satyanarayan

Thanks for filing this issue @joelostblom. It looks like we failed to update our docs when we merged the old `single`/`multi` selections into a single, unified `point` selection with Vega-Lite...

No updates yet, unfortunately. Sorry.

Yes, this is a limitation of Vega's event handling (see vega/vega-scenegraph#53). Marks that render on top of others capture events and do not propagate them down.

A couple of points: (1) I would be uncomfortable if implementation limitations impacted language level concerns. That strikes me as a case of the tail wagging the dog. (2) If...

> (Minor note) Given that the drag depends on window.mousemove, I'm not sure how is this a problem. I just tried moving the brush in the output layer in the...

@allenjlee: Here's the geo selection issue we discussed. I believe we support single/multi selections with geo projections already but a good first test would be to build out a few...

Sure. The selection states are stored in datasets named `selectionName_store` (e.g., if you had a selection named `brush`, the dataset would be named `brush_store`). Accessing the dataset via the view...

The brush mark is currently driven by signals within each unit. It's difficult to update these signals based on updates to the backing dataset (we need to identify the matching...

To make forward progress on this, I would like to decouple an API for writing to selections (which involves hairier design/implementation issues) from reading selections (which should hopefully be more...

Yeah, I went back and forth on adding Vega-Lite helper functions. I lean towards adding them (rather than relying on the Vega view API alone) to give users a forward-compatible...