Implement _buffer_cleared handler #577
Comments
oakkitten
added a commit
that referenced
this issue
Feb 23, 2024
When buffer is cleared using `/buffer clear` and more lines are added, line pointers may be reused. Before, if the app was disconnected during these events, after reconnection lines may visually appear out of order. This happened because normally we calculate diff using pointers only, and if we had an older line with the same pointer as the newer one, the adapter would reuse the old view holder, which might've been displaying the wrong line. This fixes the issue by also looking at line contents while diffing. This solution is not ideal: * While we can reliably tell whether the contents of two lines are the same, during the diffing we also want to know whether two lines represent the same thing, even if the contents have changed. As the pointer can be reused, sometimes `areItemsTheSame` will return a false positive. However, with this change the negative effect of this shouldn't go beyond wrong animation being applied. * Read marker may appear in a wrong place. We save the pointer to the last read line locally, and if the pointer is reused, there's no way for us to tell that the line is wrong. Fixes #577
oakkitten
added a commit
that referenced
this issue
Feb 23, 2024
When buffer is cleared using `/buffer clear` and more lines are added, line pointers may be reused. Before, if the app was disconnected during these events, after reconnection it was possible for the lines to appear out of order. This happened because normally we calculate diff using pointers only, and if we had an older line with the same pointer as the newer one, the adapter would reuse the old view holder, which might've been displaying the wrong line. This fixes the issue by also looking at line contents while diffing. This solution is not ideal: * While we can reliably tell whether the contents of two lines are the same, during the diffing we also want to know whether two lines represent the same thing, even if the contents have changed. As the pointer can be reused, sometimes `areItemsTheSame` will return a false positive. However, with this change the negative effect of this shouldn't go beyond wrong animation being applied. * Read marker may appear in a wrong place. We save the pointer to the last read line locally, and if the pointer is reused, there's no way for us to tell that the line is wrong. Fixes #577
oakkitten
added a commit
that referenced
this issue
Feb 23, 2024
When buffer is cleared using `/buffer clear` and more lines are added, line pointers may be reused. Before, if the app was disconnected during these events, after reconnection it was possible for the lines to appear out of order. This happened because normally we calculate diff using pointers only, and if we had an older line with the same pointer as the newer one, the adapter would reuse the old view holder, which might've been displaying the wrong line. This fixes the issue by also looking at line contents while diffing. This solution is not ideal: * While we can reliably tell whether the contents of two lines are the same, during the diffing we also want to know whether two lines represent the same thing, even if the contents have changed. As the pointer can be reused, sometimes `areItemsTheSame` will return a false positive. However, with this change the negative effect of this shouldn't go beyond wrong animation being applied. * Read marker may appear in a wrong place. We save the pointer to the last read line locally, and if the pointer is reused, there's no way for us to tell that the line is wrong. Fixes #577
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When the relay sends _buffer_cleared, we need to clear the buffer in weechat-android. This happens with some regularity with wee-slack, which will re-paint a buffer on reconnect or loading backlog from the server in a newly (re)-opened buffer. Currently this can result in duplicated or out of order messages in the buffer when the backlog is loaded.
See mhoran/weechatRN@4974981.
The text was updated successfully, but these errors were encountered: