fix(ui): keep messages visible after scrolling in non-chat windows #123
Reference in New Issue
Block a user
No description provided.
Delete Branch "fix/scroll-non-chat-windows"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Two small fixes around
pagedscroll state on non-WIN_CHATwindows (MUC, private, AI, console)._win_printf: while the user is scrolled, always bumpunread_msgbut only skip the buffer append / pad render forWIN_CHAT— it can recover dropped messages viachatwin_db_historyon scroll-down. Other window types have no DB fallback, so messages now land in the buffer instead of being silently lost.win_page_down: when a non-chat window reaches the buffer bottom, clearpagedandunread_msg.WIN_SCROLL_REACHED_BOTTOMis only set on theis_chatDB branch, so without this the[SCROLLED]/[NEW MESSAGES]indicator would never go off on non-chat windows.Also removes a local workaround in
cl_ev_send_ai_msgthat manually resetpagedbefore printing the user prompt —_win_printfnow handles this for AI as well.Test plan
[SCROLLED, NEW MESSAGES]clears on return to bottom.[SCROLLED]clears on scroll-down.New concern: what happens if history is disabled for the user in a normal chat window?
LGTM
Please address these findings.
@@ -816,1 +816,3 @@if (db_response == DB_RESPONSE_EMPTY)// Treat transient DB error (e.g. no active backend) the same// as EMPTY: no rows can be fetched, so stop indicating [SCROLLED].if (db_response == DB_RESPONSE_EMPTY || db_response == DB_RESPONSE_ERROR)If DB returns error, it might be a temporary problem, but it can get user stuck in the middle of the conversation if we change
scroll_state. I do not think that DB_RESPONSE_ERROR is a valid reason to switch state.@@ -1805,0 +1815,4 @@* skips the buffer/render only when the DB will preserve the message* verbatim — chatwin_db_history on scroll-down will replay it. When* the DB is off/redact/dead we cannot recover, so fall through and* append to the buffer just like non-chat windows. */it describes the behavior, which can be read from the code itself. It would only make sense to either add a concise explanation on WHY we do it, or to keep this stuff inside of the commit.