Ability to reverse row order and column order

[Robert Leach]

Reverse the order of the rows or reverse the order of the columns.

[Robert Leach]

Clarified the issue by rewording.

[Robert Leach]

Removing milestone: Editing (automated comment)

[Anastasia Baryshnikova]

@hepcat72 -- I think this functionality will be covered in issues #22/#24 -- do you agree that it should be labeled as duplicate?

[Robert Leach]

I think it's still distinct. If there are separate options (e.g.) to sort by value ascending & sort by value descending, then the necessity of this issue is somewhat mitigated, but if the data order is not sorted by value or by label (but rather some other user-imposed ordering of the initial data) and they want to reverse it, there would be no way to do that by either of the sort methods (even with asc/desc options).

[Anastasia Baryshnikova]

But in what scenario would you want to reverse the order of rows/columns? What's the use case?

[Robert Leach]

I was only responding to the question about whether it's a duplicate. As a trivial priority level issue, I would argue that it's enough to say that a user may want to reverse the order, but for the sake of argument, let's say that they're trying to either compare an image in a published paper which has the order reversed given usage of a different tool which reads things in differently...

In evaluating this issue, you could make the same case for questioning our other editing features on the docket: transposing rows & columns, manual orderings, rotating trees, etc..

The general impetus here is to allow users the flexibility to arrange their data how they want. If we're doing other manipulations, such as sorting, reversing will likely be a method that will be encapsulated anyway and hence will be a functionality that would be present in the code anyway.

Probably the fact that we don't have a pressing use case is what has driven such a low priority setting for this issue.