Ellipises (...) in functions are improperly passing arguments about pathviewr HOT 3 CLOSED

from pathviewr.

Oh, interesting! That makes me wonder if it's caused by some of the more recent changes I made to pathviewR functions -- hopefully contrasting them with the versions you pushed to ZFVG will help us figure out what's causing this

from pathviewr.

Ok, as of 1768232, the all-in-one function seems to be handling arguments nicely again.

I think the root cause was when I opted to add ellipses to the read_motive_csv() function to give the user the ability to pass additional (optional) arguments to data.table::fread(). In reading up about ellipses today, this page reminded me that:

R passes the extra arguments to each function and complains about the resulting mess afterwards.

By removing it (and basically reverting to how our read_ function had been working all this time), we will no longer be able to easily pass additional arguments to data.table::fread(). That said, we weren't doing this anyway. It would perhaps be nice to build this in at some point, but I definitely don't think it should be a priority.

Melissa, as far as I can tell this should not really affect anything you've been doing in ZFVG. I scanned through that repo, and it seems that you haven't been using import_and_clean_viewr() in your scripts, right? I'm pretty sure this all-in-one function would be the only one affected by this ellipsis problem. Explicitly piping through each step e.g., read_motive_csv() %>% relabel_viewr_axes() %>% gather_tunnel_data() etc etc should be robust, since you have been supplying non-default values for arguments only to the corresponding arguments themselves.

from pathviewr.