The responsibility of marking changes as read is being moved from the service level to the changes application. It has already been removed from the change service. In this commit, it's being added to the changes application. Use the existing Options.Notifications field that provides a notification service and its MarkRead method for accomplishing this. In general, it's easier for the changes application to know (with higher certainty) when a change has been read by a user. For now, it continues to happen whenever the HTTP handler serves a page that displays a change. In the future, we can decide to mark a thread as read when the user scrolls down and sees the new content, instead of right away on page load. Also update cmd/changesdev for githubapi.NewService API change. Follows https://dmitri.shuralyov.com/service/change/githubapi$commit/09fc1cdc80ff92256db38ada7ae5bdecad9db138
In case the highlighting algorithm encounters an error on some diff, we don't want to abort entirely. Fall back to showing plain diff and log the error for investigation. This is an intermediate solution until the highlighting algorithm is improved to handle the problematic case (which may take longer). Helps https://dmitri.shuralyov.com/app/changes/...$issues/2.
This is a better location for setting the cursor. It fixes the problem where the cursor was a pointer even when hovering over the empty space where there's no reaction icon but blank space (when filter leaves fewer reactions than the entire space for showing them).
Regenerate. Follows https://dmitri.shuralyov.com/service/change/...$commit/5f99232c79a97ad039852df6993da46e9cff24d2.
It's needed because in some meta-services that unify multiple underlying services, the ThreadType changes depending on the RepoSpec. Improve local variable name. Similar to https://github.com/shurcooL/issuesapp/commit/60bf33177c6943f244f14f81f145bc8b6c63f6cc. Follows https://dmitri.shuralyov.com/service/change/...$commit/891fba5eb78bd1e1c421e6c7c422ccda350d246d.
This helps it render contextual information, e.g., that depends on the current ChangeID. Pass it directly rather than via a context value because this is simpler and can be easily done since this is an unfrozen API. Related to https://github.com/shurcooL/issuesapp/commit/e746af07544c3c630e745be0872f267cb1cec21e.
There's no longer a clean distinction between comments and events. There are other timeline item types that don't fit into either category cleanly. Also, underlying implementations for various APIs are very similar and have overlap. As a result, it makes sense to merge these two methods into one.
Remove ListCommitsOptions from ListCommits. Expected usage is to always get all commits, then find the one you're interested in. This is what's needed to implement prev/next commit buttons, and more closely matches what's returned by 3rd party APIs. The button styling can be improved; to be done later.