(If one look closely at the IDs in https://github.com/SNH48Live/KVM48/issues/11#issuecomment-485266362, it's not too hard to realize what went wrong in their schema.)
Bonus: sure enough, the app itself has fucking duplicates. A scrollshot says it all:
A brief status update: I started working on the 6.0.0 update about two hours ago, hoping to get a working version (sans possible refinements) in about an hour. Boy was I wrong.
I did get std mode to work, but now it has the much dreaded N+1 problem. Way to go. Oh, and if you compare properties returned in the list request to properties returned in a single resource request, the sheer discrepancy will leave you speechless. There must be an API design genius behind this work.
Perf mode will never be the same again. There's no more subtitle, so you don't know who's in a 星梦Mini Live VOD without checking the thumbnail, and you can't even tell birthday stages from regular ones, let alone whose. Thanks for screwing with automators. What's more, they can't even do pagination any more. You heard it right. With a proper database it's actually very hard to screw up pagination, but they somehow managed it. Compare these two subsequent pages:
```console
$ curl -sS -H 'Content-Type: application/json' 'https://pocketapi.48.cn/live/api/v1/live/getOpenLiveList' --data "{'groupId': 10, 'record': true, 'next': 324479006174679040}" | jq -r '.content.liveList[].liveId'
324479006145318913
324479006145318914
324479006149513216
324479006149513217
324479006149513218
324479006128541696
324479006145318912
324479006128541697
324479006128541698
324479006132736000
324479006132736001
324479006170484738
324479006132736002
324479006136930304
324479006086598657 x
324479006136930306
324479006086598658 x
324479006090792960 x
324479006124347394
324479006090792961
```
```console
$ curl -sS -H 'Content-Type: application/json' 'https://pocketapi.48.cn/live/api/v1/live/getOpenLiveList' --data "{'groupId': 10, 'record': true, 'next': 324479006090792961}" | jq -r '.content.liveList[].liveId'
324479006086598657 x
324479006086598658 x
324479006090792960 x
324479006069821440
324479006069821441
324479006069821442
324479006069821443
324479006074015744
324479006074015745
324479006032072705
324479006074015746
324479006032072706
324479006036267008
324479006036267009
324479006036267010
324479006040461312
324479006040461313
324479006011101186
324479006015295488
324479006040461314
```
I marked the duplicate IDs with crosses. Bravo.
To sum it up:
- New version of the API is utter garbage.
- Patch will be released some time on Monday, April 22 (CST).
A couple of counter arguments, loosely ordered from most to least important.
1. > I don't know anyone who doesn't set the regular size of his/her terminal carefully
I unapologetically don't, for good reason. My daily driver is a 15'' MacBook Pro, set at 1920x1200 resolution. My terminals by default are 82x158, or when I full screen, two 85x158 side-by-side. However, I vertically split a lot. 82 lines are usually split into two 41 lines, but I don't stop at that; three or four vertical panes are regular sights too. So I could have really short panes. And I'm not that sort of person who always has a fixed set of pane arrangements and always runs a certain command in a certain pane.
2. > where's the problem in using a namesake alias to limit the number of results shown per page
i) Number of lines taken by a fixed number of results isn't fixed. Depending on your terminal width and length of abstracts, 6 results could be 24 lines, or 42 lines. You could set a conservative number which could (a) be very small (b) regularly leave you with a lot of unutilized vertical space; or you could set an aggressive number and regularly have to scroll.
ii) Fewer number of results per page means more requests — more remote paging than local paging. That also uses even more vertical space for the same amount of information due to prompts being printed, and prompts interrupt the flow of information. Paging with `n` and `p` probably takes more mental effort too.
3. Even if scrolling back is easy, what's so bad about it?
Well, **a search engine should emphasize the most relevant results.** When you're **presented with less relevant results and need to scroll back to access the more relevant ones**, that's a UX failure.
Which naturally brings us to, **what's great about `less -EFX`**?
- When the output fits in one screenful, **it does nothing**. You read however you like.
- When the output is more than one screenful, **you're presented with the most relevant results first**, and you **scroll forward instead of backward**. Some nicer details:
+ **Scrolling within `less` is very versatile.** You can (roughly) continuously scroll with j/k/arrow keys/etc., do page jumps with space/f/b/z/w, or even scroll with mouse wheel or touchpad gesture. Few if any terminal emulator's scrollback buffer is that accessible or versatile; in the off chance that some terminal emulator can do all those things, first it's hard to discover (try to consult a terminal emulator manual or check all its keybindings, compared to run `less --help`), secondly since less is modal, you don't need modifier keys for anything (vim users always use that against us Emacs users).
+ **You can even quit early if you find relevant results early.** Compared to scrolling back, where you basically have to scroll back however many pages there are.
- Oh, and with `-E` and `-X`, when you scroll to the end, less quits automatically, and you're left in a state as if nothing ever happened.
4. **The ability to scroll back isn't even a given.**
A notable example is [mosh](https://mosh.org/). It's an awesome ssh alternative for slow connections or roaming. I've used it sparingly for at least five years, and really ramped up usage in the last couple of months to access some high ping / high packet loss servers. Mosh handles the terminal emulation (which is essential for some of its main differentiators), like a terminal emulator inside your regular terminal emulator; an unfortunate side effect is that you lose access to a scroll buffer (unlike tmux where you can scroll back if you want to, although extremely unpleasant without native control mode integration).
Meanwhile, a pager like less could navigate the lowest common denominator of terminal emulation (it even works in dumb terminals — try Emacs shell mode — albeit not fully functional).
Obviously, one don't have to support the "harsh conditions". However, googler is interactive by default, so in the aforementioned "harsh condition" users can't really pipe output to less and call it a day, so native integration for them would be great.
(As I pointed out above, such users aren't fictional, since I happen to be one from time to time.)
5. > Shift+PgUp/PgDn handles that.
**That statement packs a lot of assumptions and personal preferences.**
- I assume you're talking about Gnome terminal. Keybindings are not universal across terminal emulators.
- You're assuming a keyboard with PgUp/PgDn. Many laptop keyboard don't have those. Some compact desktop keyboards don't have those.
- Even when PgUp/PgDn are available, they're way off home row, even Mozart probably needs to leave the home row to hit them. I as well as many people don't want to leave the home row at all. See point above on "scrolling within `less` is very versatile".
Ultimately, this is about giving a subset of users, some of whom have been vocal, a **non-default option** to rather **subtly tweak** (options to less have been carefully chosen to preserve as much of existing behavior as possible) **existing behavior for the better** (IMO). One can of course tell those users "you're using it wrong", but I can totally see where they're coming from (and hopefully I've presented the case), and I believe I can give them a better UX.
Unrelated: I haven't forgot about the installer script I talked about the other day. I already wrote it a few days ago, but haven't found time to satisfactorily test it yet.
Always need to scroll back on short terminals
=============================================
This is a somewhat frequent complaint (#207, #218, and scattered on hijacked threads).
There's a fairly obvious solution for this — a goddamn pager! (For some reason I haven't thought of this until now, maybe because of the XY problem — users were always suggesting a dynamic number of results, which is both unnecessarily hard to implement and a poor fit for our paging model, and I was caught up in why that's a bad idea instead of tackling the root cause.)
More concretely, we just need to pipe output into `less -EFX` (`-E` — `--QUIT-AT-EOF`; `-F` — `--quit-if-one-screen`; `-X` — `--no-init`). A tried and true paging technique.
There are two problems with `less -EFX` that are worth mentioning:
1. If user quits early, the rest of the output is lost. We can of course implement a "repeat" command (`r` is conveniently still available) to repeat the current page's results, which largely mitigates the problem. This does mean we can't make paging the default, though. It has to be behind an option (`-P`, `--pager` should be good enough), and discoverability would suffer.
Discoverability is a really hairy problem for a program that pledges to leave no trace on user's disk. I guess we could suggest the option *once* in each interactive session where the output is ~longer~ way longer than a screenful. That shouldn't be too annoying for people who don't want it, right?
2. `less` is universal enough, with one catch: BusyBox's `less` doesn't have `-F` or `-X` [1] (I'm not even sure if it supports ANSI escapes, haven't tried). A simple preflight with `--help` should shake that out though. I'm not aware of any other `less` implementation except the most common one found in both Linux and BSD.
@jarun Let me know your thoughts.
[1] https://busybox.net/downloads/BusyBox.html#less