zulip-terminal
zulip-terminal copied to clipboard
Improve dynamic message loading behavior
Currently we trigger loading more messages upon reaching the end of the current available list (top or bottom), with a failed up/down causing an exception and a message fetch.
Except for network issues, users typically expect a "cursor hitting bottom/top" to literally be at the respective end of the message list, so we should change the UI such that we don't rely upon "hitting the end" to fetch messages, but fetch messages in the background some time before reaching an end - unless actually reaching the end.
@dehnert FYI opening this partly in response to your feedback
@neiljp This seems interesting to work on. I had an idea here, could we have a MessageInfoBar which can be placed at the bottom of the list to create "empty space" indicating end of messages? This bar can be multi-functional as well by acting like the date bar in between messages similar to the webapp. (This could also help shortening the timestamp)
@Rohitth007 You've raised some interesting points which I don't think we've split into other issues yet, though I'd like to keep this issue to improve the loading experience itself.
For the other points:
- #278 was an early PR which adjusted the message box to notify something similar to your bar idea for no-messages; this would solve quite a few outstanding issues and could be a less message-box oriented version of #278
- the top/bottom bar is more of an enhancement, and would need more model support first (though there's a PR which aims to determine this, which may get part way there)
- I'm not entirely sure of a "date bar", simply since it takes up extra space, though
- independently of a date bar, there was discussion of simplifying the message dates to be relative/simplified, which we already do in some sense with years, but could be simplified much further. The same applies to extending the 'last online' status that we'll have with the user info popup, but which we're not including in the first iteration.
We could probably open issues for the last 3 points if we don't have them already; the first is covered by the existing PR and related bugs that it should fix if a similar simpler solution was made.
@neiljp We are loading new / old messages when the cursor hits the end. we can make sure that there are always a minimum amount of messages above and below the cursor.
Let's say,
If there are less than 6 messages above the cursor we'll call the function load_old_messages, and same for load_new_messages.