Alicornutopia

On the other hand, if you're in the habit of bribing the librarian's assistant to get out the fancy special cart they're not supposed to use and bring you extra-large special selections of books according to complicated criteria that they have to do extra work to locate, and the librarian gets a new assistant who responds to "fourth set of five, please, wink wink" with "right, fourth set of two, and I didn't see that $20 bill", you're hardly in a position to complain.

Or in other words, if you use URL hacking to ask for things that the site isn't equipped to give you, it is reasonable for the site to not give you those things.

I think I'd agree with Kappa here – if you ask for something the site has decided it won't give you, and you want it to instead give you… a version that ignores you less… I'm not sure it's really a bug so much as a separate feature request.

We already have page=last support, but probably not in the way you mean? It will literally take you to the last page for whatever per_page it interprets you as giving it (i.e. your value, adjusted to be between 1 and 500), instead of fetching the last X replies.

Edit: also since you said "put me 87 replies down on page 24" – if you had 11587 replies read already, you could just use per_page=500&page=unread#unread? That should put you 87 replies down page 24. Doesn't work if you haven't read to the point you want to go to, but I'm not sure why you'd care to go to a specific way through the thread otherwise? (Permalinks or unread are the main or really only use cases I can see for that, if you have a specific distance through instead of a fuzzy 'area I should look at'.)

There’s no URL redirection; the assistant gets me the fourth set of two and says “here’s the fourth set of five”. A 302 redirection would at least acknowledge the difference between the request and the response. It’s the silence combined with not giving me any part of what I ask for that I consider the bug.

To overextend the analogy, the librarian herself said that what I was trying was fine because even though I said I wanted a large group the number of books actually requested was small enough to carry. If there were 27 books and I wanted the last two (Z add &), asking for the sixth set of five would not require the special cart. Marri said using that was fine. This makes this, if not exactly a bug, at least a regression even when memory would not be a problem. I mentioned this as a request and not a bug because I realize this check is harder to do, and I don’t want to hold her to that, but I did want to report it because she’s trying to be careful not to break people’s usage of the site.

To give up on the analogy, using URL hacking is still the only way to load a page with more replies other than going through account settings, so I kind of forgot it wasn't a regular feature and the official method is to use the dropdowns on the desktop version.

Throne, I guess I will start using the unread link more often. I didn’t know about page=last[/url].

There’s no URL redirection; the assistant gets me the fourth set of two and says “here’s the fourth set of five”. A 302 redirection would at least acknowledge the difference between the request and the response.

While I agree that this is a good principle to follow, I've never seen an actually existant server do such a redirect in the particular case of ?...=... parameters.

The site does now require per_page < 500. The goal had been to have an option to jump to the flat page version, but you said that you can't use flat view, so I might have to do an Actual Thing. The Actual Thing will still not load >500 though, fair warning, if you want more than that you'll have to use flat view :)

Yeah, I know you can’t send too many at once; I’m not trying to eat up all the RAM. I’m just trying to load the replies I haven’t read so I can read them on the train without using lots of data or overloading my phone.

I'm too deeply anti-design to figure out how to represent this on a page, but you can now use /posts/id?at_id=unread#unread to do the thing. The UI might be wonky as all get out, in particularly the pagination bar will almost certainly be displaying incorrectly, but I did try to at least get the click-forward page links to work.

Thank you; I’ll try it out tomorrow and see how it goes. I’m sorry for being difficult, although I am a bit surprised nobody else seems to have the same issues of wanting to load all the unread posts and them not all fitting the normal pagination boundaries.

It worked perfectly with how I tested it, although as expected it behaved weirdly.

Details:

1. It still shows the original post unhidden, which confused me when I wasn’t expecting that.
2. Because of the confusion, I tried at_id=unread twice in a row, and got a 500-level error the second time, probably because there was no unread.
3. When I manually found the reply I wanted, at_id=388151&per_page=100 showed me what I wanted. It had the original post visible, and nothing was in the (mobile) pagination bar, making it look like a one-page thread with everything showing. This is fine since there was nothing after the end of the page shown.
4. Further testing (mobile view only) shows that pagination, both backwards and forwards, seems to work consistently if you start farther back than the last page, and works exactly as though the at_id were the first reply in the thread. Not ideal, but fixes my issues and good enough for a feature which isn’t exposed in the UI at all.

If you want to turn this into a proper feature instead of a quick hack to help a difficult user, I think you should hide the original post unless the first reply displayed is actually the first in the thread, and allow navigation before the at_id reply. This of course could cause problems when you get near the beginning of the thread if the at_id thread isn’t at a multiple of the page size; I think there are four reasonable ways to handle that. The first three have page 1 start at the first reply and page 2 start at at_id minus some multiple of the page size.

• Page 1 shows all replies from the first reply to the start of page 2, even if this is fewer than the page size. This has the advantage of each reply being on one page, but the disadvantage of never getting back in phase with the standard pagination.
• Page 1 shows the first per_page replies, even if this overlaps with page 2, and hitting next gets you that same page 2 compete with overlap. This has the advantage of using the full page size but has overlap and it’s impossible to get in phase with the standard pagination.
• Page 1 works just like with no at_id; going to page 1 and then page 2 takes you to the standard page 2. This makes pagination change in a potentially weird way, but does allow getting back in phase.
• Any backwards navigation takes you to a standard page, not just page 1. I think this is a bad option but maybe there’s something to be said for front-loading the weird behavior.

I go back and forth between preferring the first and third options. For any option, I’d implement this by making pagination links change the at_id value instead of combining at_id and page, although your pagination library might not like that.

Alternately, you can leave it as-is and not turn the quick hack into a proper feature, unless other people want it. It works fine for me as-is.

Thanks again.

I'd prefer option three if anything, as it seems more like expected behavior to me. (If the start of my page is 5 replies from the start, then I press back, it should shunt me to the first page of the thread. If the end of my page is 5 replies from the end… it should probably shunt me to the last page of the thread? Otherwise it'd seem inconsistent.)

Also the "page" thing should definitely show something to indicate you're offset from the regular pagination. Maybe a tilde before the number, or equivalent. I expect the weird behavior in the pagination is due to Marri trying to get it out for the use case rather than polishing it to be… more end-user friendly.