RPTools
[Feature]: Sort Table display by Range Header (forward/reverse).
Describe the Problem
When adding new ranges/values to a table, it always appends to the end of the display and you can only get things properly sorted by rebuilding the table.
i.e. If I have the following ranges: 1-10 11-20 21-30
And I want to change 1-10 to 1-5 and add 6-10, the 6-10 entry is append to the end of the table so it looks like this: 1-5 11-20 21-30 6-10
The table display can become quite chaotic with such edits.
The Solution you'd like
Click the Range header to sort the table by the range values (forward/reverse toggle).
Alternatives that you've considered.
Clunkier... but getting some "Add/Delete/Move Up/Move Down" buttons like what we have in Properties would help with doing manual repositioning of rows.
Additional Context
Sorting by other columns might be nice to help find and visualize things... but the range column is the most pressing, imo.
Just want to float some ideas out there:
- If we could easily add rows in the middle of the table, how much would you still want sorting?
- How about marking a table as needing to always be a sorted table? That way you wouldn't have to hit a button just to reorder things.
- How would we deal with ambiguous cases? Ranges can overlap in arbitrary ways. I propose just sorting based on the range's lower bound, using the upper bound only for tie breaks.
I have an ulterior motive with asking (2). In the context of #4769, an idea was floated to automatically sort tables as it would allow for faster lookups on very large tables. But since ranges can overlap, and table lookup needs to find the first matching entry, sorting can change the behaviour of existing tables. But if the user told us they want the table to stay sorted, then this would be a viable option for those tables.
Just want to float some ideas out there:
1. If we could easily add rows in the middle of the table, how much would you still want sorting?
Certainly better than current limitations. I think I'd still like to be able to move rows up and down (in the case of misplacement or future modifications). I don't suppose that getting any drag capability in that window would be doable?
2. How about marking a table as needing to always be a sorted table? That way you wouldn't have to hit a button just to reorder things.
Again, an improvement. A little limiting if you wanted to extended the ability to sort by other headers though (like pick, value, or other future columns.)
3. How would we deal with ambiguous cases? Ranges can overlap in arbitrary ways. I propose just sorting based on the range's lower bound, using the upper bound only for tie breaks.
I agree. Though I'd say that tables with overlapping ranges are actually "broken"... and handling in those cases should be better (I suppose a different freq though).
I wasn't even sure how MT handled that but just made a quick table to test: 1-5 | one five | 2-6 | two six | 3-4 | three four | 2-5 | two five |
[r: table("test", 3)] always returns the last entry ("two five").
I have an ulterior motive with asking (2). In the context of #4769, an idea was floated to automatically sort tables as it would allow for faster lookups on very large tables. But since ranges can overlap, and table lookup needs to find the first matching entry, sorting can change the behaviour of existing tables. But if the user told us they want the table to stay sorted, then this would be a viable option for those tables.
As noted above... the "first matching entry" isn't how it currently works in my test... it takes the last. If the table returned all values that the range fulfilled that might seem intentional... but returning only the first or last match is arbitrary and error prone.
That said, I'll take being able to select "Always sort" per 2 using the rule in 3 to be a worthwhile improvement even if nothing else is done.
I wasn't even sure how MT handled that but just made a quick table to test: 1-5 | one five | 2-6 | two six | 3-4 | three four | 2-5 | two five |
[r: table("test", 3)]always returns the last entry ("two five").
👀 I think I have a bug to fix on latest developement builds ...
Ah, I see what I messed up. The search is done front to back like I said, but it's the last match the gets returned. And, yeah, I messed this up with the recent perf improvement for tables.
I did my testing in 1.18.6 ... so I think it pre-dates your recent updates?
At any rate, I still think it should return every value that applies to the roll... or throw an error proclaiming that there are multiple results. What's the point of allowing overlapping values if it only returns the first (or last)?
Edit: Ah... I see... returning first is the "bug".
I did my testing in 1.18.6 ... so I think it pre-dates your recent updates?
At any rate, I still think it should return every value that applies to the roll... or throw an error proclaiming that there are multiple results. What's the point of allowing overlapping values if it only returns the first (or last)?
Edit: Ah... I see... returning first is the "bug".
I wish ranges had to be exclusive from the start to avoid this. But changing anything in this regard after all this time is not going to be practical.
A possible use (who knows if anyone actually does this) is to have a wide range as a sort of fallback for a few narrower ranges:
| Range | Value |
|---|---|
| 1 - 20 | Main result |
| 5 - 7 | Specific result |
| 12 - 14 | Another result |
If we changed table() to either return a list or throw an error, it would mess up any such tables in the wild.
Yeah, we'd need some kind of new table preferences: "Last Match" (current Legacy) "First Match" "All Match" "Strict Table Ranges" (throw error if more than one match)
Anyway, for the purpose of this FREQ your suggestion above (2) would be an improvement. I'm assuming that would be something like a "Sort by Range" checkbox?